具有一个ZSET的Redis GEORADIUS与许多特定大小的ZSET

Question

更快的是，一个包含地理数据的大型ZSET，我将使用GEORADIUS查询100米半径

或

有很多ZSET，每个ZSET负责100m x 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，会不会影响访问它们时的性能？

Answer 1

这种方法的精确比较只能通过benchmark完成，它将特定于您的数据集和配置。但是从架构上讲，你的优势和劣势是：

• BIG ZSET：更少的带宽和更少的操作(CPU周期)执行，边界没有问题(可能存在多个ZSET的重复)，可以使用
  • BIG ZSET获得吞吐量:其他操作的延迟更少(当大ZSET正在运行时，其他命令正在等待)，可以通过分片获得吞吐量，通过集群获得延迟。

至于底线问题，我没有看到实现代码，但是set名称应该与您使用的任何其他键相同。以下是Redis FAQ对密钥数量的描述：

单个Redis实例的最大密钥数量是多少？<...>

Redis最多可以处理2^32个密钥，并且经过实践测试，每个实例至少可以处理2.5亿个密钥。

更新：

看看Redis文档是怎么说GEORADIUS的：

时间复杂度: O(N+log(M))，其中N是由圆心和半径分隔的圆形区域边界框内的元素数，M是索引内的项数。

这意味着查询之外的项对查询的影响为O(log(M))。因此，10m项的17跳或1b项的21跳是相当实惠的。剩下的问题是，您会在节点之间进行分区吗？