小编cld*_*ons的帖子

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