我正在努力想出我应该使用多少集合作为我的解决方案。我知道这取决于情况,但我想给出一些关于我们将要处理的数据类型的上下文。
此外,我们将利用IoT事件和引用数据上的cosmos db change提要,因此我知道为此需要一个租约集合。
任何帮助或建议都会很好!
发布于 2018-11-03 12:41:28
就像你说的,这一切都取决于多方面的事情,我没有全貌给出最准确的答案,但我会尝试总结你需要知道的一切,以作出正确的选择。
分区
首先,分区键是不可变的。这意味着,一旦使用分区键创建了集合,它的定义就无法更改。文档上的分区键值也是如此。
其次,分区的最大大小为10 at (至少目前如此)。这意味着,如果您选择一个分区键,最终会达到这个数字,那么游戏就结束了,您必须将您的集合迁移到一个具有更多不同值的分区键上。
我之所以提到这一点,是因为多个类型的实体可以存储在同一个集合中,唯一的限制是分区键。如果他们可以有一个共享的分区键(比如某种类型的id,比如eventId),那么他们就没有理由不能共享相同的集合。
成本和吞吐量缩放
我撒了谎。还有另一个原因,您的实体可能不应该共享相同的集合,这就是成本和吞吐量缩放。每种类型的实体拥有一个集合具有(潜在的)优势,即拥有一个更合适的分区键,但也能够相互独立地扩展。这意味着您可以在600 RU/s上提供遥测事件收集,而在400 RU/s上提供参考数据。同样,这取决于您所期望的负载,因此完全取决于您自己。从长远来看,这样做的最终结果可能是省钱,或者比应该花费更多的钱。
换料
为了存储与租约相关的文档,需要将更改提要指向一个集合,但许多更改提要进程可以共享相同的更改提要集合,因此至少需要一个。
https://stackoverflow.com/questions/53131289
复制相似问题