面向顺序访问的Cosmos数据库分区密钥和查询设计

Question

如果我们只使用CustomerID作为分区键，我们最终将超过逻辑分区的10GB限制，如果我们使用Eventid，那么查询将变得低效（将导致跨分区查询和高RU使用率，这是我们希望避免的）。

另一个想法是将文档分组为块。即PartitionKey=int（EventId/PartitionSize)。这将导致所有客户机访问最新的分区，这可能会导致性能差和节流。

如果我们使用CustomerID和int(EventId/PartitionSize)的组合PartitionKey，那么我不清楚如何避免跨分区查询来检索正确的文档集。

澄清几点：

• 客户端将通过指定CustomerID的列表、它们收到的最后一个Eventid以及要检索的最大记录数来访问事件。
• 因此，单独使用EventId不会很好地执行，因为它会导致跨分区查询（即whereevent>lasteventid)。
• 系统可能会以每天1GB的速度，以15分钟的速度递增。
• 很难知道读取量会是多少，但我猜可能会适中，可能有几千个客户机定期轮询API。

Answer 1

所以首先，逻辑分区的大小限制现在已经增加到20GB，请看这里。

您也可以使用EventID作为分区，因为逻辑分区的大小以GB为单位有限制，但逻辑分区的数量没有限制。所以使用EventID很好，如果使用EventID查询，您将得到一个点到点的读取，这是非常快的。现在您提到使用这种方式，您将不得不执行跨分区查询，您能解释一下如何执行吗？

但有几件事要记住，Cosmos DB并不是真正用来存储这种基于日志的数据，因为它将所有东西都存储在固态硬盘中，所以请计算您的1文档大小，以及您在一秒钟内需要存储多少，然后在一天内存储多少，再到在一个月内存储多少。完成后，可以使用TTL从Cosmos中删除，对于长期存储，可以将其存储在Azure BLOB存储中，对于快速检索，可以使用Azure Search在搜索查询中使用CustomerID和EventID查询BLOB中的数据。