为基于日期的全球 DocumentDB 应用程序选择正确的 PartitionKey
Choosing the right PartitionKey for a date-based worldwide DocumentDB app
我正在开发一个 worldwide 应用程序，其中大多数搜索基于 地理空间数据 （给定坐标的最近记录）和 日期范围.
因此，基本上可能是 AirBnb、Booking 等应用程序的主要搜索
考虑到这些上下文，我应该在 DocumentDB 分区集合中选择哪个分区键？
谢谢！
更新：就像我告诉 Matias（查看答案）一样，我和我的朋友正在考虑国家之类的事情。
该应用程序是关于搜索的。另一件重要的事情是我们有日期。大量的日期。
由于我们是 DDB 的新手，我们的问题是：“如果我们选择国家/地区作为分区键并且我们的查询必须在不同的国家/地区内搜索，会发生什么情况？”。即在国家边界附近进行 georadius 搜索。
不了解更多信息很难说，但我会从这些官方分区指南开始：Partitioning and scaling, especially the section about Designing。
要点应该是吞吐量分布（您不需要 "hot spots"）和事务原子性。请记住，当您发出查询时，它可以跨越多个分区，并且 DDB 将平均分配吞吐量（您可以将此功能与 EnableCrossPartitionQuery 选项一起使用）。
因此，真正决定最佳分区键的因素实际上取决于数据的分布方式以及查询的构建方式。
由于该应用程序是全球性的，也许最好的分区方法是除以 country/continent/region（其中之一），但这实际上取决于数据量，它应该均匀分布以避免真正热 partition/zone.
最后，您还可以检查 Performance and scale test example and DocumentDB performance tips 以提高性能。
就像Matias提到的，更多的信息将帮助我们提供更好的推荐。我在下面添加了一些 ideas/options 用于分区键选择：
- 使用通用分区键，例如用户 ID 或产品 ID。在此模型中，您的地理空间查询将跨分区执行，但由于 DocumentDB 在本地分区内构建空间索引，这可能会满足您的性能需求
- 使用基于位置 GeoHash 的分区方案。这将确保相似位置的数据点将放置在相同的分区上。这将需要在您的应用中添加一些额外的工作来添加 "GeoHash > abcdef and GeoHash < abcfff" 子句以将查询执行范围缩小到几个分区
- 基于 属性 的分区，例如 国家/地区 ，如果您的大部分查询都在一个国家/地区内。需要跨越国家/地区的罕见查询也将表现良好（尽管延迟不如针对单个 partition/country 的查询低），因为它们可以在每个分区中使用本地索引。您可能需要单独处理特殊情况。例如，如果美国拥有 >30-40% 的数据，您可能希望选择一种混合方法，其中美国数据使用州作为分区键，数据较少的国家/地区使用国家/地区作为分区键。国家/地区 + day/month/year 的复合键也可能有效，具体取决于数据分布。
- 如果您的查询在时间范围内均匀分布，您可以考虑使用日期作为分区键。但对于大多数应用程序来说，由于最近的数据被更频繁地访问，这不是一个好的选择。
如果您使用分区是因为您有大量数据，但希望仅根据地理空间标准查询 return 一条或几条记录，那么像 country 这样的东西可能会起作用，因为它会切出一个大量不相关的数据和分区内的索引将允许快速找到所需的文档。这可能会导致不规则的分区大小 - 想象一下如果俄罗斯和中国最终在同一个分区中。
但是，如果您的查询将 return 大量基于地理空间标准的文档，并且您希望提取所有这些记录或对它们应用进一步的过滤或其他功能，那么您将需要将该处理分散到尽可能多的分区上。在这种情况下，您需要一个将数据均匀分布在分区上的分区键。如果您希望查询针对相同的坐标、用户 ID 或站点 ID 等组合多个文档类型，那么最好有一个基于该值的键，以便可以在同一分区内一起处理所有相关文档。
在实际应用中，我发现使用递增值作为分区键是最好的通用解决方案，因为它允许在所有分区上均匀地处理查询。
我正在开发一个 worldwide 应用程序，其中大多数搜索基于 地理空间数据 （给定坐标的最近记录）和 日期范围.
因此，基本上可能是 AirBnb、Booking 等应用程序的主要搜索
考虑到这些上下文，我应该在 DocumentDB 分区集合中选择哪个分区键？
谢谢！
更新：就像我告诉 Matias（查看答案）一样，我和我的朋友正在考虑国家之类的事情。 该应用程序是关于搜索的。另一件重要的事情是我们有日期。大量的日期。 由于我们是 DDB 的新手，我们的问题是：“如果我们选择国家/地区作为分区键并且我们的查询必须在不同的国家/地区内搜索，会发生什么情况？”。即在国家边界附近进行 georadius 搜索。
不了解更多信息很难说，但我会从这些官方分区指南开始：Partitioning and scaling, especially the section about Designing。
要点应该是吞吐量分布（您不需要 "hot spots"）和事务原子性。请记住，当您发出查询时，它可以跨越多个分区，并且 DDB 将平均分配吞吐量（您可以将此功能与 EnableCrossPartitionQuery 选项一起使用）。
因此，真正决定最佳分区键的因素实际上取决于数据的分布方式以及查询的构建方式。
由于该应用程序是全球性的，也许最好的分区方法是除以 country/continent/region（其中之一），但这实际上取决于数据量，它应该均匀分布以避免真正热 partition/zone.
最后，您还可以检查 Performance and scale test example and DocumentDB performance tips 以提高性能。
就像Matias提到的，更多的信息将帮助我们提供更好的推荐。我在下面添加了一些 ideas/options 用于分区键选择：
- 使用通用分区键，例如用户 ID 或产品 ID。在此模型中，您的地理空间查询将跨分区执行，但由于 DocumentDB 在本地分区内构建空间索引，这可能会满足您的性能需求
- 使用基于位置 GeoHash 的分区方案。这将确保相似位置的数据点将放置在相同的分区上。这将需要在您的应用中添加一些额外的工作来添加 "GeoHash > abcdef and GeoHash < abcfff" 子句以将查询执行范围缩小到几个分区
- 基于 属性 的分区，例如 国家/地区 ，如果您的大部分查询都在一个国家/地区内。需要跨越国家/地区的罕见查询也将表现良好（尽管延迟不如针对单个 partition/country 的查询低），因为它们可以在每个分区中使用本地索引。您可能需要单独处理特殊情况。例如，如果美国拥有 >30-40% 的数据，您可能希望选择一种混合方法，其中美国数据使用州作为分区键，数据较少的国家/地区使用国家/地区作为分区键。国家/地区 + day/month/year 的复合键也可能有效，具体取决于数据分布。
- 如果您的查询在时间范围内均匀分布，您可以考虑使用日期作为分区键。但对于大多数应用程序来说，由于最近的数据被更频繁地访问，这不是一个好的选择。
如果您使用分区是因为您有大量数据，但希望仅根据地理空间标准查询 return 一条或几条记录，那么像 country 这样的东西可能会起作用，因为它会切出一个大量不相关的数据和分区内的索引将允许快速找到所需的文档。这可能会导致不规则的分区大小 - 想象一下如果俄罗斯和中国最终在同一个分区中。
但是，如果您的查询将 return 大量基于地理空间标准的文档，并且您希望提取所有这些记录或对它们应用进一步的过滤或其他功能，那么您将需要将该处理分散到尽可能多的分区上。在这种情况下，您需要一个将数据均匀分布在分区上的分区键。如果您希望查询针对相同的坐标、用户 ID 或站点 ID 等组合多个文档类型，那么最好有一个基于该值的键，以便可以在同一分区内一起处理所有相关文档。
在实际应用中，我发现使用递增值作为分区键是最好的通用解决方案，因为它允许在所有分区上均匀地处理查询。