azure - Cosmos DB 图边缘分区

Question

Cosmos DB 已预先宣布 Gremlin(图形 API)全面可用。到 2017 年底，它可能会停止预览，因此我们可能会认为它足够稳定，可以用于生产。这让我想到以下几点:

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

我们不仅会存储与用户相关的数据，还会存储用户之间的相互关联的数据(关系)。从理论上讲，Cosmos 应该非常适合此类场景，将其跨 api 与文档 API 一起用于普通数据，而图形 API 纯粹用于关系。

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

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

生成的边会自动分配给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 亿个分区的完整跨分区查询是 Not Acceptable 。

我尝试将 UserX 和 UserY 之间的 Edge 放入其自己的分区内，但 Graph API 不允许我这样做。 (编辑:将 Cosmos 更改为 Graph API)

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

然后我又想知道 Graph API 是否真的适合这些场景 - 或者我真的错过了一些东西？

Answer 1

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

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