Azure functions Cosmos DB最小分区

我们有一个物联网场景，Azure Event Hub作为我们的数据摄取服务。我们建议的架构是，我们在EH上有一个事件捕获（窗口=15分钟），使用Azure批处理服务在一天结束/一天中的定期间隔处理捕获的数据，然后存储在冷库（BLOB/数据湖）中。 我们还希望有一个事件中心->函数应用->Cosmos DB的管道，用于通过事件捕获方法可能无法提供的即时查询（因为它们不会是即时的）。关于Cosmos DB的存储，我们计划使用ttl=24/48小时。现在的问题是，如果我们选择deviceId和ttl以上的分区，我们将无法有效地利用该分区（最大=10GB），并且会有多个分区，这将影响成本。 所以，我的问题是，我们可以使用哪些其他策略（其他db/分区机制）来优化（主要关注点-成本效率）数据库存储

尝试单分区收集-在移动到更高规模的设备时不会有用

按时间（小时/分钟）划分，这意味着一种预付款模式，这是不需要的

---

首先，您肯定需要对容器进行分区。deviceId将是密钥的完美匹配，但是我确实知道您可能会填充分区，以便查看复合密钥。复合键是由文档的两个不同属性组成的键。在您的情况下，它可能是

设备ID somethingElse

。它需要是文档中的一个单独属性，理想情况下称为

partitionKey

，由所选属性的值自动生成

有两件事我需要弄清楚，我认为你没有完全理解

Cosmos DB中分区的数量不会直接影响定价。它间接地影响了它，因为在系统中存储了大量数据之后，Cosmos将创建更多的物理分区，而这些物理分区反过来又具有它们需要配置的最小RU/s量

数据大小对定价的影响非常小，可以忽略不计

---

Nick，谢谢你的回答。但是我不得不不同意你的#2，我有过数据大小间接影响查询请求费用的第一手经验。您还可以对partitionkey更具体一点，其目的是最小化分区的数量。只有当您使用跨分区查询时，这才是信任，您永远不应该将跨分区查询作为应用程序正常工作流程的一部分。另外，关于分区最小化的问题，您必须非常小心，因为一个分区已满时，您就完成了。@AnirbanSinha您不应该关心逻辑分区的数量，特别是不要以最小化其计数的方式。恰恰相反，您应该拥有尽可能多的逻辑分区，以便将相关文档保持在同一逻辑分区中，以供您需要事务的文档使用。这样一来，cosmosdb将非常有效地散列密钥&跨物理分区分配存储和工作负载，这将产生最经济高效的结果。顺便说一句，日期/时间很少是好的分区键，因为它会产生写热点。拥有多个逻辑分区不会直接转换为多个物理分区。当现有分区达到10Gb存储限制或物理分区达到每个物理分区10000 RU/s的吞吐量限制时，物理分区将被拆分

deviceId

是分区键的第一个候选项。如果您假设它每

deviceId

会增长到10Gb以下，那么引入新属性

partitionKey

（合成键）并使其值，例如，

$“device{deviceId}{month}

或任何粒度足以让您永远不会达到10Gb限制的内容。