redis - 在分层数据模型中使用 Redis 进行复合索引

Question

我有一个这样的数据模型:

领域:

计数器编号(例如 00888、00777、00123 等)

计数器代码(例如 XA、XD、ZA、SI 等)

开始日期(例如 2017-12-31 ...)

结束日期(例如 2017-12-31 ...)

其他柜台日期(例如xxxxx)

当前的数据结构组织是这样的(根和多子格式):

counter_num + counter_code
       ---> start_date + end_date --> xxxxxxxx
       ---> start_date + end_date --> xxxxxxxx
       ---> start_date + end_date --> xxxxxxxx

例子:

00888 + XA
       ---> Jan 10 + Jan 20 --> xxxxxxxx
       ---> Jan 21 + Jan 31 --> xxxxxxxx
       ---> Feb 01 + Dec 31 --> xxxxxxxx

00888 + ZI
       ---> Jan 09 + Feb 24 --> xxxxxxxx
       ---> Feb 25 + Dec 31 --> xxxxxxxx

00777 + XA
       ---> Jan 09 + Feb 24 --> xxxxxxxx
       ---> Feb 25 + Dec 31 --> xxxxxxxx

今天，检索以两种方式发生:

//Fetch unique counter data using all the composite keys
counter_number + counter_code + date (start_date <= date <= end_date)

//Fetch all the counter codes and corresponding data matching the below conditions
counter_number + date (start_date <= date <= end_date)

在 redis 中对此进行建模的最佳方法是什么，因为我需要缓存一些经常命中的数据。我觉得排序集应该以某种方式做到这一点，但无法对其进行建模。

更新:

只是为了消除混淆，这里的询问不是针对 SQL“BETWEEN”之类的查询。 '因为我不知道 start_date 和 end_date 值是什么。认为它们只是列名。

我不要的是

SELECT * FROM redis_db  
WHERE counter_num AND 
date_value BETWEEN start_date AND end_date

我要的是

SELECT * FROM redis_db
WHERE counter_num AND
start_date <= specifc_date AND end_date >= specific_date

注意:该要求非常接近 Redis 多维索引文档中提出的 2D 索引

https://redis.io/topics/indexes#multi-dimensional-indexes

我理解了这个概念，但无法消化给出的实现细节。

Answer 1

我不太可能在赏金前及时完成这项工作，但到底是什么……

这听起来像是 geohashing 的工作。 Geohashing 是您想要索引二维(或更高)数据集时执行的操作。例如，如果您有一个城市数据库，并且希望能够快速响应诸如“查找 X 的 50 公里内的所有城市”之类的查询，则可以使用地理哈希。

对于这个问题，你可以想到 start_date和 end_date如 x和 y坐标。通常在 geohashing 中，您正在数据集中搜索空间中特定点附近或某个有界空间区域中的点。在这种情况下，您只有一个坐标的下限和另一个坐标的上限。但我想在实践中整个数据集无论如何都是有界的，所以这不是问题。

如果在 Redis 中有一个库可以做到这一点，那就太好了。可能有，如果你看得够仔细的话。较新版本的 Redis 具有内置的地理散列功能。查看以 GEO 开头的命令.但它并没有声称非常准确，它是为球体表面而不是平面设计的。

因此，据我所知，您有 3 个选择:

将您的搜索空间映射到球体的一小部分，最好靠近赤道。使用 Redis GEO 命令。要搜索，请使用 GEOSPHERE在覆盖您尝试搜索的三角形的圆上，考虑到内置的不准确度和映射到球体上的失真，然后过滤结果以获取实际在三角形内的结果。

找一些适用于 Redis 的 3rd-party geohashing 客户端，它适用于平面空间并且比 GEO 更准确。

阅读本答案的其余部分，或其他一些关于 geohashing 的入门读物，然后在 Redis 上自己实现。这是最难(但最具教育意义)的选择。

如果您有一个使用数字排序索引数据的数据库，这样您就可以执行诸如“查找 z 介于 a 和 b 之间的所有行/记录”之类的查询，您可以在最重要的。假设坐标是(非负)整数 x和 y .然后添加一个整数值列 z , 索引 z .计算 z , 写 x和 y二进制，然后从每个数字中取出替代数字。例子:

x =     969 = 0 1 1 1 1 0 0 1 0 0 1 
y =    1130 =  1 0 0 0 1 1 0 1 0 1 0
z = 1750214 = 0110101011010011000110

请注意，索引允许您查找，例如，所有以 z 定位的记录。之间 0101100000000000000000和 0101101111111111111111包括的。换句话说， z 的所有记录以 010110 开头.或者换句话说，您可以找到 x 的所有记录。以 001 开头和 y以 110 开头.这组记录对应于我们试图搜索的二维空间中的一个正方形。

并非所有方块都可以通过这种方式进行搜索。我们将这些称为可搜索方块。假设客户端发送对所有 (x,y) 的所有记录的请求。位于特定矩形内。 (或圆形，或其他一些合理的几何形状。)然后您需要找到一组覆盖矩形的可搜索正方形。然后，对于您选择的每个方格，查询数据库中该方格内的记录并将结果发送给客户端。 (但您必须过滤结果，因为并非正方形中的所有记录实际上都在原始矩形中。)

需要取得平衡。如果您选择少量的大型特殊方块，您最终可能会覆盖比您需要的更大的 map 区域；对数据库的查询将返回许多您必须过滤掉的额外结果。或者，如果您使用许多特殊的小方块，您将对数据库进行大量查询，其中许多查询不会返回任何结果。

我上面说了 x和 y可能是 start_time和 end_time .但实际上，数据集的分布不会像地理散列的大多数用途那样对称。因此，如果您使用 x = end_time + start_time，性能可能会更好(或更糟)。和 y = end_time - start_time .