azure - 为什么我不应该将所有数据放入一个 CosmosDB 集合中？

Question

问题

我有discovered Cosmos DB 的定价非常激进，如果与多种数据类型一起使用，价格可能会很昂贵。

我认为一个好的结构是将我拥有的每种数据类型放入它们自己的集合中，几乎就像数据库中的表(不完全是)。

但是，每次收集费用每月至少 24 美元。如果我选择“固定”，则会将我限制为 10GB 并且不可扩展。几乎不是 Cosmos DB 的重点，所以我宁愿选择“Unlimited”。不过，这里的价格至少是每月 60 美元。

每种数据类型每月 60 美元。

这包括 1000 RU，但除此之外，我还必须支付更多的消费费用。

如果我有几种数据类型，这可能没问题，但如果我有一个包含 30 种数据类型的成熟业务应用程序(一点也不罕见)，那么每月至少需要 1800 美元。作为起始价。当我还没有数据时。

问题

集合中数据的结构并不严格。我可以在同一个集合中存储不同类型的文档。

使用“无限”集合时，我可以使用分区键，应该使用分区键对我的数据进行分区以确保可扩展性。

但是，为什么我不只在分区键中包含数据类型？

然后分区键就变成这样:

[customer-id]-[data-type]-[actual-partition-value, like 'state']

只要一动，我的最低成本就变成了 60 美元，其余的则根据消费情况而定。据推测，无论数据量有多大，分区键都能确保令人满意的性能。那么我错过了什么？这种方法有问题吗？

更新

Microsoft 现在支持在所有容器之间共享 RU(不低于 10000 RU)，因此这个问题基本上不再相关，因为您现在可以自由选择将数据分离到不同的容器中，而无需任何额外费用。

Answer 1

不，本身不会有任何问题。这一切都归结为您是否愿意为整个系统提供 1000 RU/s，或更具体地说是单个瓶颈。

事实上，您可以通过将文档 ID 作为分区键来进一步简化这一过程。这将保证文档 ID 的唯一性，并在 CosmosDB 中实现最大可能的分布和规模。

就是这样collection sharing works in Cosmonaut (免责声明，我是这个项目的创建者)并且我没有注意到任何问题，即使在具有许多不同数据类型的系统上也是如此。

但是，您必须记住，即使您可以上下扩展此集合，您仍然会因为这个瓶颈而限制整个系统。我建议您不要只创建一个集合，而可能创建 2 或 3 个其中包含共享实体的集合。如果这做得足够聪明，并且您以逻辑方式批处理实体，那么您可以扩展系统特定部分的吞吐量。