图分片和存储

概览

图数据物理存储在数据库部署的Shard服务器上。根据需要，可部署一个或多个Shard服务器。

创建图时，可指定将图数据存储在一个Shard或分布式地存储在多个Shard中。这种分片架构支持数据量的水平扩展，同时保持高性能的查询能力。

图分片

创建类型图g1，指定使用CityHash64哈希函数将图数据分布存储到三个Shard [1,2,3]：

CREATE GRAPH g1 { 
  NODE User ({name STRING, age UINT32}),
  NODE Club ({name STRING, score FLOAT}),
  EDGE Joins ()-[{joinedDate DATE}]->()
}
PARTITION BY HASH(CityHash64) SHARDS [1,2,3]

使用关键词PARTITION BY指定哈希函数，SHARDS指定Shard服务器ID列表：

• 哈希函数：哈希函数（Crc32、Crc64WE、Crc64XZ或CityHash64）计算分片键（即点_id）的哈希值，对图数据分片至关重要。了解更多信息，请参阅Crc和CityHash。
• Shard服务器ID列表：用于存储图数据的Shard服务器的ID列表。

这两个关键词都是可选的。默认使用Crc32将图数据分布到所有Shard。

创建开放图g2，将图数据存储到Shard [1]：

CREATE GRAPH g2 ANY SHARDS [1]

图数据迁移

图数据迁移有时是有必要的。比如，现有Shard过载时需迁移至更多Shard，或需要将数据分布到其他地理区域；将数据迁移至更少的Shard则可以释放未充分利用的资源，降低消耗，简化管理。

将图g3迁移至Shard [1,4,5]:

ALTER GRAPH g3 ON SHARDS [1,4,5]

这等同于

ALTER GRAPH g3 ON SHARDS [1,4,5] PARTITION CONFIG {strategy: "balance"}

默认的迁移策略是balance，即将所有图数据重新平均分配新Shard中。除此之外，也可指定以下一种策略：

• quickly_expand：将部分数据从当前Shard快速迁移至新Shard，这要求新Shard列表必须包含当前所有Shard。
• quickly_shrink：将被移除的Shard上的数据快速迁移至剩余Shard，这要求新Shard列表必须是当前Shard列表的子列表。

假设图g3当前分布在Shard [1,2]上，将其快速迁移至Shard [1,2,4]：

ALTER GRAPH myGraph ON SHARDS [1,2,4] PARTITION CONFIG {strategy: "quickly_expand"}

将图g3从Shard [1,2]快速迁移至[1]：

ALTER GRAPH myGraph ON SHARDS [1] PARTITION CONFIG {strategy: "quickly_shrink"}