Cosmos DB 图边缘分区

Question

Cosmos DB 已预先宣布 Gremlin（图形 API）的全面可用性。可能到 2017 年底它会退出预览版，因此我们可能认为它足够稳定以进行生产。这让我想到以下几点：

我们正在设计一个估计用户群高达 1 亿用户的系统。每个用户在 Cosmos 中都会有一些文档来存储用户相关的数据，这些文档根据用户的 id（一个 Guid）进行分区。因此，当估计成真时，我们最终会得到至少 1 亿个分区，每个分区都包含一堆文档。

我们不仅会存储与用户相关的数据，还会存储用户之间的相关数据（关系）。从理论上讲，Cosmos 应该非常适合这些类型的场景，将它与文档 API 跨 API 用于普通数据，将 Graph API 用于纯粹的关系。

这些关系之一的示例是关注。例如UserX可以 Follow UserY。为了实现这种关系，我们创建了一个 Gremlin 查询，它创建了一个Edge：

    g.V().hasId('{userX.Id}').has('pkey','{userX.Partition}')
    .addE('follow').to(g.V().hasId('{userY.Id}').has('pkey','{userY.Partition}'))

结果会Edge自动分配给 的分区UserX，因为UserX是出顶点。

在传出边缘（所有UserX跟随的用户）上查询时，一切都很好，因为查询仅限于UserX.

    g.V().hasId('{userX.Id}').has('pkey','{userX.Partition}').outE('follow').inV()

但是，当反转查询（查找 的所有关注者UserY），寻找传入的边时，情况会发生变化 - 据我所知，这将导致完整的跨分区查询：

    g.V().hasId('{userY.Id}').has('pkey','{userY.Partition}').inE('follow').outV()

在我看来，具有 1 亿个分区的完整跨分区查询是不可接受的。

我曾尝试将其内部和Edge之间放入自己的分区，但 Graph API 不允许我这样做。（编辑：将 Cosmos 更改为 Graph API）UserXUserY

现在我已经到了在UserX和之间实现一对边的地步UserY，一个传出EdgeforUserX和一个传出Edgefor UserY，试图保持它们同步。这一切都是为了优化我的查询速度，同时也引入了更多的工作来实现最终的一致性。

然后我又想知道 Graph API 是否真的适合这些场景 - 或者我真的在这里遗漏了什么？

Answer 1

首先，我将澄清您对 CosmosDB 分区的一个轻微误解。1 亿用户并不意味着 1 亿个分区。它们只是意味着 1 亿个分区键。当您创建 cosmos dB 图时，它从 10 个物理分区开始（这是启动默认值，可以根据请求进行更改），然后随着数据的增长自动扩展。

\n\n

在这种情况下，1亿用户将分布在10个物理分区中。因此，完整的跨分区查询将命中 10 个物理分区。另请注意，这些分区将并行命中，因此预期延迟将类似于命中一个分区，除非操作本质上类似于聚合。

\n