为基于日期的全球DocumentDB应用程序选择正确的PartitionKey

Question

我正在开发一个全球应用程序，其中大多数搜索基于 geospacial数据（最近的记录给定坐标）和日期范围

因此，基本上可能主要搜索AirBnb，Booking等应用程序

考虑到这些背景，我应该在DocumentDB分区集合中选择哪个分区键？

谢谢！

更新：就像我告诉马蒂亚斯（见答案），我和我的朋友，我们正在考虑像国家这样的事情。 该应用程序是关于搜索。另一件重要的事情是我们有约会。大量的约会。 由于我们是DDB的新手，我们的问题是：＆＃34; 如果我们选择国家/地区作为分区键会发生什么，我们的查询必须在不同国家/地区内搜索？＆＃34;。即靠近国家边界的地理搜索。

Answer 1

与Matias提到的一样，更多信息将有助于我们提供更好的建议。我在下面添加了一些分区键选择的想法/选项：

• 使用通用分区键，如用户ID或产品ID。在此模型中，您的地理空间查询将跨分区执行，但由于DocumentDB在分区内本地构建空间索引，因此可能满足您的性能需求
• 根据位置的GeoHash使用分区方案。这将确保类似位置的数据点将放置在相同的分区上。这将需要您的应用中的一些额外工作来添加＆＃34; GeoHash＆gt; abcdef和GeoHash＆lt; abcfff＆＃34;将查询执行范围缩小到几个分区的条款
• 如果您的大多数查询属于单个国家/地区，则基于国家/地区等属性进行分区。需要跨越国家的罕见查询也将表现良好（尽管不像单个分区/国家的查询那样低延迟），因为它们可以使用每个分区内的本地索引。您可能需要单独处理特殊情况。例如，如果美国有大约30-40％的数据，您可能希望选择混合方法，其中美国数据使用州作为分区键，而数据较少的国家/地区使用国家/地区作为分区键。国家/日/月/年的组合密钥也可能有效，具体取决于数据分布。
• 如果您的查询在时间范围内均匀分布，则可以考虑使用日期作为分区键。但对于大多数应用程序，由于最近访问的数据更频繁，因此这不是一个好的选择。

Answer 2

不知道多一点很难说，但我会从这些官方分区指南开始：Partitioning and scaling，尤其是关于Designing的部分。

要点应该是吞吐量分布（你不想要“热点”）和交易原子性可能。请记住，当您发出查询时，它可以跨越多个分区，DDB将均匀分配吞吐量（您可以将此功能与EnableCrossPartitionQuery选项一起使用）。

那么，真正决定哪个是最好的分区键实际上取决于数据的分布方式以及查询的构建方式。

由于应用程序是全球性的，也许最好的分区方法是按国家/洲/区域（其中之一）划分，但它实际上取决于数据量，应该均匀分布以避免真正热门的分区/区。

最后，您还可以查看Performance and scale test example和DocumentDB performance tips以改善效果。

Answer 3

如果您正在使用分区，因为您有大量数据，但希望查询仅根据地理空间标准返回一条或几条记录，那么像国家这样的东西可能会起作用，因为它会立即删除大量不相关的数据分区中的索引将允许快速找到所需的文档。这可能会导致不规则的分区大小 - 想象一下，如果俄罗斯和中国最终进入同一分区。

但是，如果您的查询将根据地理空间标准返回大量文档，并且您希望提取所有这些记录或对其应用进一步过滤或其他功能，那么您将希望将该处理分散到尽可能多的分区尽可能。在这种情况下，您需要一个分区键，它将数据均匀地分布在分区上。如果您希望查询将多个文档类型组合为相同的坐标，用户ID或站点ID等，那么最好有一个基于该值的键，以便所有相关文档可以在同一个分区中一起处理。

在实际应用中，我发现使用递增值作为分区键是最佳通用解决方案，因为它允许在所有分区上均匀处理查询。