图分区

• JanusGraph集群包含多个存储后端，图被存储在所有机器上。
• JanusGraph以邻接表形式存储图数据，顶点的分配到机器上的方法就决定了图的分区。
• 不同场景采用不同的分区策略 。
  • 出现热点场景（一个顶点有大量的边，且该顶点会被经常访问）：采用VertexCut（又叫Edge-centric）策略，将边（及其依附的顶点）分配在不同的机器上。
  • 高频率查询的关联节点：应该将关联节点分配在一台机器上，从而减少通信消耗。

JanusGraph Data Layout

• JanusGraph中数据存储布局。

  image.png

随机分区策略（默认策略）

• 随机安排顶点到所有机器上。缺点：查询效率慢，因为存在大量的跨实例的通信。

精确分区

• 具有强关联性和经常访问的子图存储在相同的机器上，这样可以减少跨机器的通信成本。
• 配置参数

cluster.partition = true       //开启集群自定义分区策略
cluster.max-partitions = 32       //最大的虚拟分区数
ids.flush = false

• max-partitions：最大虚拟分区数，建议配置为存储数据个数的两倍。
• 精确分区只有支持key排序的存储后端
  • Hbase：支持图自定义分区
  • Cassandra：需要配置ByteOrderedPartitioner来致辞图分区
• 在图分区下有edge cut和vertex cut两方面可以单独控制。

Edge Cut(默认)

• Edge cut:一条边的两个顶点分别在不同的机器上，那么这条边叫做cut edge。包含对这条边的遍历的图查询会慢因为需要在两台设备间通信。

• 目的：对于频繁遍历的边，应该减少cut edge的存在，从而减少跨设备间的通信，提高查询效率。即把进行遍历的相邻顶点放在相同的分区，减少通信消耗。

• 顶点的id分配：一个分区就是一个有序的id区间，顶点被分配到一个分区就会为该顶点分配一个id，也就是顶点的id决定了该顶点属于哪一个分区。给一个顶点分配id：JanusGraph就会从顶点所属分区的id范围中选一个id值分配给该顶点。(先定分区，在分配id)

• 为顶点确定分区：JanusGraph通过配置好的 placement strategy来控制vertex-to-partition的分配。

  • 默认策略：在相同事务中创建的顶点分配在相同分区上。
    • 缺点：如果在一个事务中加载大量数据，会导致分配不平衡。
  • 定制分配策略：实现IDPlacementStragegy接口，并在通过配置文件的ids.placement项进行注册。

Vertex Cut

• Vertex Cut：顶点切割，即把一个顶点进行切割，把一个顶点的邻接表分成多个子邻接表存储在图中各个分区上。
• 目的：一个拥有大量边的顶点，在加载或者访问时会造成热点问题。Vertex Cut通过分散压力到集群中所有实例从而缓解单顶点产生的负载。
• 方法：JanusGraph通过label来切割顶点，通过定义vertex label成partition，那么具有该label的所有顶点将被分配在集群中所有机器上。
• 案例：对于product和user顶点，product顶点应该被定义为partition，因为用户和商品有购买记录（edge），热销商品就会产生大量的购买记录，从而会造成热点问题。

mgmt = graph.openManagement()
mgmt.makeVertexLabel('user').make()      //正常vertex label
mgmt.makeVertexLabel('product').partition().make()  // 分区vertex label
mgmt.commit()

Random vs. Explicit Partitioning 建议

• 图数据小使用Random分区策略，图大时（超过10亿条边）就要使用自定义分区策略

参考文章

图分区