由于一段时间内流量激增,我们遇到了节流(429)。为了缓解此问题,我们目前在 azure 门户中增加了RU,后来又减少了。
我想基于指标按比例放大/缩小,但是,它没有公开为文档数据库容器创建的物理分区的数量。
最佳答案
所需RU限制的依据是什么
我根本不会进入物理分区级别,因为无论如何,负载可能不会在各个分区之间平均分配。我认为您可能不在乎平均分区吞吐量,但需要照顾最坏的分区吞吐量。
因此,如果您需要完全自动缩放,那么我将专注于跟踪节流事件(在事后发生)或监视总RU使用情况(分区魔术)。两条路径都可能变得非常复杂,无法获得真正的自动缩放,可能需要将它们结合起来使用。升级似乎是可以实现的,然后决定何时降级以及降低到哪个级别比较棘手。
很难期望意外的事情在事情发生之前能够可靠地使用react。与简单的解决方案相比,绝对要考虑在您的方案中是否值得。
基于日历的RU限制基准
甚至更简单的解决方案是按照平均峰值负载趋势,通过准备好的时间表(即工作日+一天中的时间)来设置RU限制。
这不会针对意外的峰值或下降进行自动缩放,并且需要进行一些监视以适应意外的情况,但是无论如何您都可以,对吗?
这种简单的解决方案将为您提供灵活的吞吐量限制,并且每天花费最少的精力就可以实现每天的可预测成本。
更改RU限制
一旦知道了在任何给定时间想要的RU限制,那么执行它就很容易。增减或RU限制可以进行编程,例如通过Azure functions运行。实际更改限制的C#示例如下:
var offer = client.CreateOfferQuery()
.Where(r => r.ResourceLink == collection.SelfLink).Single();
offer = new OfferV2(offer, newthroughput);
client.ReplaceOfferAsync(offer);
您的Azure函数可能会定期打勾,并根据您配置的日程安排或收集到的事件相应地调整newthroughput
。注意事项
无论您实现哪种自动缩放解决方案,都应考虑为您愿意达到的水平设置合理的硬性限制。否则,如果发生事故或恶意事件(DDOS),您可能会从Azure获得意外账单。节流有时会更好。
关于azure - 自动按比例放大/缩小Cosmos DB RU,我们在Stack Overflow上找到一个类似的问题:https://stackoverflow.com/questions/48653687/