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

Question

问题

我发现Cosmos DB 的定价非常高，如果与许多数据类型一起使用，可能会很昂贵。

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

但是，每个收款每月至少要花费 24 美元。这是如果我选择“固定”，这将我限制为 10GB 并且不可扩展。几乎不是 Cosmos DB 的重点，所以我宁愿选择“无限”。但是，这里的价格至少为每月 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 中实现最大可能的分布和规模。

这正是Cosmonaut 中集合共享的工作方式 （免责声明，我是这个项目的创建者），我没有注意到任何问题，即使在具有许多不同数据类型的系统上也是如此。

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