我正在开发一个全局应用程序，其中大多数搜索都基于地理空间数据(给定坐标的最近记录)和日期范围。
所以，基本上可能是 AirBnb、Booking 等应用程序的主要搜索。
考虑到这些上下文，我应该在 DocumentDB 分区集合中选择哪个分区键？
谢谢!
更新:就像我告诉 Matias 的那样(参见答案)，我和我的 friend 正在考虑像国家这样的事情。 该应用程序主要是关于搜索的。另一件重要的事情是我们有约会。大量的日期。 由于我们是 DDB 新手，我们的问题是:“如果我们选择国家/地区作为分区键并且我们的查询必须在不同国家/地区内搜索，会发生什么？”。即国家边界附近的 georadius 搜索。
最佳答案
正如 Matias 提到的，更多信息将帮助我们提供更好的推荐。我在下面添加了一些分区键选择的想法/选项:
- 使用通用分区键，例如用户 ID 或产品 ID。在此模型中，您的地理空间查询将跨分区执行，但由于 DocumentDB 在分区内本地构建空间索引，这可能会满足您的性能需求
- 使用基于 GeoHash 的分区方案的位置。这将确保相似位置的数据点将被放置在相同的分区上。这将需要在您的应用中进行一些额外的工作来添加“GeoHash > abcdef 和 GeoHash < abcffff”子句，以将查询执行范围缩小到几个分区
- 如果您的大部分查询都位于一个国家/地区，则根据国家/地区等属性进行分区。需要跨越国家/地区的罕见查询也将表现良好(尽管延迟不如针对单个分区/国家/地区的查询那么低)，因为它们可以使用每个分区内的本地索引。您可能需要单独处理特殊情况。例如，如果美国拥有 >30-40% 的数据，您可能需要选择一种混合方法，其中美国数据使用州作为分区键，数据较少的国家/地区使用国家/地区作为分区键。国家/地区 + 日/月/年的复合键也可能有效，具体取决于数据分布。
- 如果您的查询均匀分布在时间范围内，您可以考虑使用日期作为分区键。但对于大多数应用程序来说，由于最近的数据被更频繁地访问，这不是一个好的选择。
关于database - 为基于日期的全局 DocumentDB 应用程序选择正确的 PartitionKey，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/40795590/