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

Question

在我学习如何使用Cosmos DB的图形时,我发现了两个Microsoft教程:

• 一个使用Gremlin.Net
• 在其他使用Microsoft.Azure.Graph预发布

虽然我使用相同的查询,但它的执行不同.

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

实际上,使用Micorosft.Azure.Graph,我必须调用ExecuteNextAsync一个循环,一次返回一个结果.

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

更新

问题3,我发现在我的数据库的"数据资源管理器"刀片中,我的图表有一个"Scale&Settings",我可以更新吞吐量.

Update2

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

Answer 1

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

此处描述了DocumentClient关于这些错误的默认重试行为:

默认情况下,如果请求继续高于请求率运行,则在累积等待时间为30秒后返回状态代码为429的DocumentClientException.

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

在CosmosDB Gremlin服务器上,此重试策略限额显着减少,因此RequestRateTooLargeException错误将更快浮出水面.

回答你的问题:

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

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

2.我如何知道查询的RU,以便对其进行微调？

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

在此期间,您可以通过Azure CosmosDB帐户门户上的Metrics刀片观察您的请求发出429错误的频率.这显示了给定集合的请求数量,超出容量的请求,存储配额等的聚合视图.

3.是否可以提高现有集合的吞吐量？

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

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

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

• 要求收费,
• CosmosDB特定的状态代码(例如429)和
• Retry-after值,表示等待的时间,以避免遇到429错误.