可逆布隆查找表（IBLT）

可逆布隆查找表

 

水平可扩展性是现代软件开发中最重要的问题之一。如果你的程序可以通过创建更多的实例来处理更多的任务，生活就会容易得多。但是正如您所经历的那样，在现实世界中实现这种可扩展性是极其困难的。现代计算机系统的几乎每个方面都在解决这个问题，如果你的目标是非常大的系统，事情会变得更加复杂。

并行化困难的根本原因是程序的大部分重要操作与其底层状态紧密耦合。换句话说，程序的每个实例都有自己的状态，可能彼此不同，因此它们可能没有相同的行为。这就是为什么很多人关注数据同步方案，以确保每个节点具有相同的内部状态。

让我们假设 Alice 和 Bob 想要共享项目列表，例如他们存储中剩余的水果数量。Alice 知道他们有 3 个苹果、10 个葡萄和 7 个甜瓜。Bob 知道还剩下 10 个葡萄、7 个甜瓜和 2 个柠檬。在朴素算法中，Alice 会告诉所有她知道的水果，而 Bob 告诉 Alice 她不知道的，在这个例子中是 (lemon, 2)。这是非常低效的，因为他们必须在消息中包含 3 个项目，而他们真正需要的只是 1 个项目，这是它们内部状态之间差异的大小。如果他们只发送它们之间的差异，而不是完整的水果清单，效率会高得多。这就是 IBLT（Invertible Bloom Lookup Table）的用武之地。

可逆布隆查找表

IBLT 的基本思想与计数布隆过滤器非常相似，但它增加了一些功能，这对于数据同步问题非常有用。IBLT的特点包括：

• 空间与两组之间的差异成正比
• 可以保存每个item的key和value

IBLT在每个表行中维护count、key_sum、val_sum和hash_sum。在每次插入项目时，count增加 1，并且key_sum和val_sum通过异或与当前键和值合并。hash_sum用于容错，并与当前 key 的 hash 合并。当然，与任何其他布隆过滤器衍生品一样，键是用多个哈希函数进行哈希处理的，因此键/值对被插入到多个索引中。

让我们尝试从 Alice 的水果列表中构建一个 IBLT，大小为 5，哈希计数为 3。如果苹果哈希为 0、1、4 和 11，则表将如下所示。

 

接下来，如果葡萄散列到 1、3、4 和 6

 

如果 melon 散列到 0、2、4 和 9

 

现在，有些项目的计数为 1。如果我们只进行了插入，那么那些key_sum和val_sum将保持其原始值。我们称它们为纯物品，它们可以安全地从桌子上移除。根据纯项目的键和值，我们可以重新计算插入位置的索引，并将它们从表中剥离出来。通过一一剥离纯项目，我们可以从 IBLT 中恢复项目的原始列表。

正如您所注意到的，要解码构建的 IBLT，在解码的每一步中都应该至少有一个纯项目。为此，IBLT 应具有比其包含项目更大的空间。当然，如果我们将它用作包含所有项目的表，它比简单的查找表效率低得多。但令人着迷的是，您可以减去两个 IBLT。

Alice 的 IBLT（称为X）和 Bob 的 IBLT（称为Y）将具有 (grape, 10) 和 (melon, 7) 共同点。换句话说，在每个目标索引中，两个表在其key_sum、val_sum和hash_sum 中都有(grape, 10) 和 (melon, 7) 的异或键、值和哈希值。这意味着，如果我们减去每个计数第X从ÿ，和XOR每个key_sum，val_sum和hash_sum的X与Y ^，那么常见的元素将被抵消。生成的 IBLT，称为Z，将仅包含X之间的差异和Y（在数学上，( X - Y )∪( Y - X ))

但问题是，计数为1 的行可能不再是纯项目。由于IBLT使用多个哈希函数生成的索引，并且一些项目可以有重叠的指标，一些项目可能刚刚“意外”得到了数1.为了处理这种情况下，我们检查的哈希key_sum等于hash_sum太. 此外，由于我们做了减法，被列入纯商品X，但不Ÿ会算的-1。因此，为了解码这个减去的 IBLT，我们寻找计数为1 或 -1 的项目，并检查key_sum 的哈希值是否等于hash_sum，并将其从 IBLT 剥离。

乍一看似乎很奇怪，有些人可能想知道它是否真的按预期工作。已经有一些关于这方面的论文，它说超过 90% 的案例被成功解码，其中表大小为 50，设置差异为 30。根据论文，似乎 3~4 的哈希数就足够了，并且1.5倍的集差大小，99%的案件都可以成功处理。

IBLT 是一种相对年轻的数据结构，在野外没有足够的用例。然而，已经有一些人试图利用这一点，例如在比特币区块传播中。IBLT 具有很大的潜力，并且与其他传统技术相比具有很多优势。也许下次系统设计值得考虑。