azure-cosmosdb - 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，我发现在我的数据库的“数据资源管理器” Blade 中，我的图表有一个“比例和设置”，我可以在其中更新吞吐量。

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

Answer 1

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

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

By default, the DocumentClientException with status code 429 is returned after a cumulative wait time of 30 seconds if the request continues to operate above the request rate.

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

在 CosmosDB Gremlin 服务器上，此重试策略允许显着减少，因此 RequestRateTooLargeException错误会更快浮出水面。

要回答您的问题:

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

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

2. 我怎样才能知道我的查询的 RU 以便我可以微调它？

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

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

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

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

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

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

索取费用，

CosmosDB 特定状态码(例如 429)和

Retry-after 值，表示为避免遇到 429 错误而等待的时间。