1

我们有一个 IoT 场景，使用 Azure Event Hub 作为我们的数据摄取服务。我们建议的架构是，我们在 EH 上有一个事件捕获（窗口 = 15 分钟），使用 Azure Batch 服务在一天结束时处理捕获的数据/全天定期间隔，然后存储在冷库（blob/数据湖）中。我们还希望有一个 Event Hub -> Function App -> Cosmos DB 管道，用于通过事件捕获方法可能无法获得的瞬时查询（因为它们不会是瞬时的）。关于 cosmos db 的存储，我们计划有一个 ttl = 24/48 小时。现在的问题是，如果我们选择 deviceId 及以上 ttl 的分区，我们将无法有效利用该分区（最大 = 10GB），并且有多个分区会影响成本。所以，我的问题是其他策略（其他数据库）

  1. 尝试过单分区集合 - 在移动到更高规模的设备时不会有用
  2. 按时间（小时/分钟）分区，这意味着预付费模型，这是不希望的
4

1 回答 1

2

首先，您绝对需要对容器进行分区。deviceId 将是键的完美匹配，但是我确实知道您可能会填满分区，因此您可能会查看复合键。复合键是由文档的两个不同属性组成的键。在你的情况下，它可能是deviceId-somethingElse. 它需要是文档中的一个单独属性，理想情况下称为partitionKey，由您选择的属性的值自动生成。

我需要澄清两件事，我认为您不太正确理解。

  1. Cosmos DB 中的分区数量不会直接影响定价。它间接影响它，因为在您的系统中存储了很多数据之后，Cosmos 将创建更多的物理分区，作为回报，它们需要为每个分区提供最少的 RU/s。
  2. 数据大小对定价的影响很小，可以忽略不计。
于 2019-07-08T08:03:35.510 回答