Cosmos Db Graph - Gremlin.Net 与 Microsoft.Graph 的性能和吞吐量

Question

在学习如何将图形与 Cosmos DB 结合使用时，我发现了两个 Microsoft 教程：

• One 使用 Gremlin.Net
• other 使用Microsoft.Azure.Graph pre-release

虽然我使用相同的查询，但它的执行方式不同。

使用 Gremlin.Net，它立即执行。我经常（我会说 70% 的时间）收到RequestRateTooLargeException。如果我理解正确，这意味着我一直在达到我选择开始的 400RU/s 限制。但是，当查询进入低谷时，它的速度是 Microsoft.Azure.Graph 解决方案的两倍。

确实，对于 Micorosft.Azure.Graph，我必须在一次返回一个结果的循环中调用 ExecuteNextAsync。

所以问题是：
1°) 我应该使用哪种方法以获得更好的性能？
2°) 我怎样才能知道我的查询的 RU 以便我可以微调它？
3°) 是否可以增加现有集合的吞吐量？

更新

关于问题 3，我发现在我的数据库的“数据资源管理器”刀片中，我的图表有一个“规模和设置”，我可以在其中更新吞吐量。

更新2

关于问题 2，我们无法在使用第一种方法 (Gremlin.Net) 时收取 RU，但 Microsoft.Graph 方法 ExecuteNextAsync 返回带有字段 RequestCharge 的 FeedResponse。

Answer 1

您通过 Gremlin.NET 与 Microsoft.Azure.Graphs 遇到 RequestRateTooLarge 异常（429 状态代码）的原因可能是由于 CosmosDB Gremlin 服务器上的重试策略与 DocumentClient 的默认重试策略之间的差异。

针对这些错误的 DocumentClient 的默认重试行为描述为 here：

默认情况下，如果请求继续以高于请求速率运行，则会在累积等待 30 秒后返回状态代码为 429 的 DocumentClientException。

因此，Microsoft.Azure.Graphs 可能会在内部处理并重试来自服务器的这些错误并最终成功。这有助于提高请求的可靠性，但会混淆请求率错误，并会影响执行持续时间。

在 CosmosDB Gremlin 服务器上，此重试策略允许值显着降低，因此RequestRateTooLargeException 错误将更快出现。

回答您的问题：

1.我应该使用哪种方法以获得更好的性能？

通过 Gremlin.NET 使用 CosmosDB Gremlin 服务器有望获得更好的性能。 Microsoft.Azure.Graphs 使用不同的请求处理方法，它涉及到服务器的更多往返行程，因此它有开销，此外还有许多版本落后于部署到服务器的版本。

2。我怎样才能知道查询的 RU 以便进行微调？

RU 费用将作为属性包含在 Gremlin 服务器响应中。目前 Gremlin.NET 无法在响应中公开属性，但是正在讨论对客户端驱动程序的更改here。

在此期间，您可以通过 Azure CosmosDB 帐户门户上的指标刀片观察您的请求遇到 429 错误的频率。这会显示给定集合的请求数量、超出容量的请求、存储配额等的聚合视图。

3.是否可以增加现有集合的吞吐量？

如您所见，您可以通过门户增加现有集合的吞吐量。或者，这可以通过 Microsoft.Azure.Documents SDK 以编程方式实现。

---

最后，我的建议是围绕 Gremlin.NET 请求添加重试策略，以处理这些异常并匹配 RequestRateTooLargeException 消息。

当 Gremlin.NET 上公开响应状态属性时，它们将包括：

• 请求收费，
• CosmosDB 特定状态代码（例如 429），以及
• Retry-after 值，表示为避免遇到 429 错误而等待的时间。

Answer 2

我的理解是 Gremlin.Net 驱动程序更快，但是由于 cosmos 不支持字节码，因此您只能使用文档客户端与数据库进行交互。

https://github.com/Azure/azure-documentdb-dotnet/issues/439

https://groups.google.com/forum/#!topic/gremlin-users/Ve-cEZed94o