Redis位图拆分键划分策略

Question

我正在从联邦选举委员会公共数据源API中抓取并归档大量数据，该API具有一个唯一的记录标识符，称为“ sub_id”，它是19位整数。

我想考虑一种内存有效的方式来对我已经存档的订单项进行分类，并立即想到位图。

阅读有关redis位图的文档，表明最大存储长度为2 ^ 32（4294967296）。

一个19位整数从理论上可以在0000000000000000001-9999999999999999999之间变化。现在我知道有问题的数据源实际上没有99亿个记录，因此它们显然是稀疏填充的，不是连续的。在我当前已归档的数据中，最大ID为4123120171499720404，最小值为1010320180036112531.（我可以根据ID告诉日期一个日期，因为键中的2017和2018对应于它们引用的记录的日期，但是我无法继续其余模式。）

如果我想存储已经下载的行项目，是否需要2328306436不同的redis位图？ （9999999999999999999/4294967296 = 2328306436.54）。我可能可以设计出一个微小的算法来确定给定的19位数字，然后除以某个常数以确定要检查的拆分位图索引。

这种策略似乎不可能成立，因此我认为我必须从根本上误解这种策略。是吗？

Answer 1

诸如 RedisBloom 之类的Bloom过滤器将是最佳解决方案（如果您错误地计算了所需容量，RedisBloom甚至可以增长）。

BF后。创建过滤器，您将转到BF。 ADD 要插入的“项目”。此项可以根据您的需要而定。过滤器使用哈希函数和模数使其适合过滤器大小。如果要检查项目是否已被检查，请用“ item”调用BF。 EXISTS 。

简而言之，这里描述的是一个经典示例，说明Bloom Filter非常适合。

Answer 2

有多少个“项目”？什么是“很多”？

无论如何。使用一位来跟踪10 ^ 19个潜在项目中的每一个的线性方法至少需要1250 PB。这使得将其存储在内存中是不切实际的（atm）。

我建议您总体上讲授概率数据结构，并且在权衡利弊之后，开始考虑使用RedisBloom工具箱中的内容。

Answer 3

如果ID的ID不是连续的且分布很广，那么最好不要选择使用位图来跟踪哪个ID，因为这样会浪费大量内存。

但是，在不知道您的数据集有多少个不同的sub_id的情况下，很难找到最佳解决方案。如果您谈论的是几千万，那么在Redis中进行简单设置就足够了。