DocumentDB OfferThroughput 是不是应该在代码中设置？

Posted 2023-02-23

【中文标题】DocumentDB OfferThroughput 是不是应该在代码中设置？

【英文标题】：Should DocumentDB OfferThroughput be set in Code?DocumentDB OfferThroughput 是否应该在代码中设置？

【发布时间】：2016-04-19 09:33:00

【问题描述】：

DocumentDB 最困难的事情之一是确定每天运行应用程序以及在使用高峰期间需要多少每秒请求单位 (RUs/s)。当你弄错了，DocumentDB 客户端会抛出异常，这是一种糟糕的使用模式。

在 DocumentDB 示例中创建新集合时，我已经看到将 OfferThroughput 值硬编码为 400（这似乎是最低的 RUs/s）。我原以为最好在 Azure 门户中设置它，这样就可以动态更改它而无需更改代码。

在代码中设置它的场景是什么，哪个值优先？

【参考方案1】：

我必须同意，在 DocumentDB 上购买吞吐量的配置模型似乎非常不云。实际上，您要么预先配置到峰值所需的***别，要么您自己编写代码以通过 Azure SDK 提高和降低吞吐量（当有多个 SDK 时，这将成为一场噩梦该集合的峰值来源）。

定价模式很荒谬。由于底层架构（尤其是 250GB 层）似乎无论如何都可以很好地扩展，我们应该按使用量收费。

旁注，因为它是动态的，您正在编写代码，因为在 Azure 下似乎没有任何面向规则的解决方案可以提供帮助。

【参考方案2】：

Azure 门户和 SDK 都使用 REST API (https://msdn.microsoft.com/en-us/library/azure/mt632095.aspx) 来更新集合的吞吐量。该门户使用 DocumentDB 的 javascript 客户端 SDK。所以没有优先级或偏好顺序 - 最后一次调用更新性能将对集合有效。

关于哪些场景集在代码和门户中提供吞吐量，这取决于您的偏好和部署过程。对于生产应用程序，代码更好，因为您可以轻松实现自动化。您可以动态更改吞吐量，也可以从多个集合的配置中统一更改。

【参考方案3】：

实际上，您只需要编写自己的节流代码，如 documentdb 所示。如果你得到一个 DocumentClientException where ex.StatusCode == 429 然后执行 await Task.Delay(ex.RetryAfter)，然后再试一次。直到您遇到其他异常或它成功为止。