什么会更快，一个带有地理数据的大 ZSET，我将在其中使用 GEORADIUS 查询 100 米半径
或
很多 ZSET，每个 ZSET 负责覆盖整个世界的 100m X 100m 正方形？并以这 100m 的正方形命名，例如:
left_corner1_49_2440000_28_5010000
left_corner2_49_2450000_28_5010000
.......
并且将所有 100 米都放在组内的右侧和底部。 因此，在搜索最近点时，我将省略 gps 中的冗余数字，例如:49.2440408，28.5011694 将变为 49.2440000、28.5010000 这样我就可以知道 ZSETS 的名称，只需以 100 米的精度获取所有精确值。
或者以一般形式质疑它:ZSET 的名称是如何在 Redis 中存储和访问的？如果我的 ZSETS 太多，访问它们时会影响性能吗？
最佳答案
这种方法的精确比较只能通过基准来完成，并且它会特定于您的数据集和配置。但从架构上讲，您的优缺点是:
- 大 ZSET:更少的带宽和更少的执行操作(CPU 周期)，边界上没有问题(许多 ZSET 可能重复)，可以通过分片获得吞吐量；
- 许多 ZSET:其他操作的延迟更短(大 ZSET 正在进行时，其他命令正在等待)，可以通过分片获得吞吐量，通过集群获得延迟。
至于底线问题，我没有看到实现代码，但设置名称应该与您使用的任何其他键相同。这就是Redis FAQ说到键的数量:
What is the maximum number of keys a single Redis instance can hold? <...>
Redis can handle up to 2^32 keys, and was tested in practice to handle at least 250 million keys per instance.
更新:
看看 Redis 文档对 GEORADIUS 的看法:
Time complexity: O(N+log(M)) where N is the number of elements inside the bounding box of the circular area delimited by center and radius and M is the number of items inside the index.
这意味着您的查询之外的项目会对您的查询产生 O(log(M)) 的影响。因此，10m 元素需要 17 跳，1b 元素需要 21 跳，这是相当实惠的。剩下的问题是你会在节点之间做分区吗？
关于data-structures - 具有一个 ZSET 的 Redis GEORADIUS 与许多特定大小的 ZSET，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/50374815/