图分区
- 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亿条边）就要使用自定义分区策略
