Azure Cosmos DB图边划分

Cosmos DB已经预先宣布了Gremlin（Graph API）的通用性。大概到2017年底，它将退出预览，所以我们可能认为它足够稳定生产。这使我想到以下几点：

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

我们不仅要存储与用户相关的数据，还要存储用户之间的相关数据（关系）。纸面上的Cosmos应该非常适合这些场景，将it交叉api与文档api用于普通数据，而图形api仅用于关系

这些关系之一的一个例子是Follow。例如，

UserX

可以跟随

UserY

。为了实现这种关系，我们创建了一个Gremlin查询，该查询创建了一个

边

：

    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亿个分区的完整跨分区查询是不可接受的

我已经尝试将

边

放在

UserX

和

UserY

之间，放在它自己的分区中，但Graph API不允许我这样做。（编辑：将Cosmos更改为图形API）

现在，我要在

UserX

和

UserY

之间实现一对边，一个用于

UserX

的传出

Edge

和一个用于

UserY

的传出

Edge

，试图保持它们的同步。所有这些都是为了优化我的查询速度，同时也引入了更多的工作来实现最终的一致性

---

然后，我再一次想知道Graph API是否真的符合这些场景的要求，或者我真的缺少一些东西？

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

---

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

这是一个典型的分区难题，不是Cosmos/Graph所独有的

如果您的使用模式是大量小范围的查询，那么跨分区是不好的。如果它返回大数据集，那么跨分区开销相对于并行性的好处可能是微不足道的。除非你的查询量一直很高，否则我认为跨分区开销被夸大了（微软似乎认为每个人都在Cosmos上建立下一个Facebook）

---

在OP的情况下，您可以通过在每个方向上都有一条边来优化x跟随y，或x跟随y，或两者。请注意，RU是按每个分区（即总RU/分区数）保留的，因此要有效地使用它们，您需要高容量、均匀分布的单分区查询或跨多个分区的查询

这确实是Cosmo图形功能实现方式的一个限制。创建两条边以支持双向查询可能有助于提高性能，但显然需要内置应用程序逻辑以确保始终成功创建两条边。在对之间的文档进行操作时，不支持事务或ACIDpartitions@JesseCarter谢谢你的回答。实际上，是Graph API以这种方式实现的，如果我们直接使用Cosmos的REST接口，我们可以从中获得更多。现在我正在研究通过UDF创建顶点和边，以实现某种形式的交易…@cldons这是一个非常好的问题，我正在寻找答案，你解释得非常好。@JayanteMondal感谢你的回答-不幸的是，这不是我所希望的。我再次阅读了有关宇宙划分的官方文档，注意到在本文中，逻辑划分和物理划分之间没有明确的区别。如果我使用一对边（in&out）来定义一个关系，那么查询所花费的时间会比只定义一个out边和查询传入边少很多，这一想法对吗？