Efficient and scalable trie-based algorithms for computing set containment relations

一、对计算问题的概述

集合集是数据管理的基本操作，例如，在图形分析和数据挖掘应用程序中。由最近的硬件激发结束，在本文中提出用于计算集合包含连接的两种新颖解决方案大规模集：紧凑的trie结构不仅能够实现有效利用主存储器，但也显着增强了主存储器两种方法。通过仔细分析算法并用各种方法进行广泛的实验合成和真实世界的数据集，实验表明，在许多实际在这种情况下，此算法比数据快一个数量级。
最先进算法的大部分焦点都集中在基于磁盘的算法上。尽管已经证明这些算法对于加入大量集合非常有效，但这些解决方案的性能受其基础内存处理策略的限制，其中已完成的工作较少。例如，两个先进的基于磁盘的算法PSJ 和APSJ 与主存储器算法SHJ共享相同的内存处理策略。为了跟上不断增长的数据量和现代硬件趋势，我们需要将性能提升到一个新的水平。因此，重新访问（并开发新的）内存中的集合包含连接算法至关重要。这些算法既可以作为主存储器数据库的基本组件，也可以作为外部存储器和其他计算模型和平台的构建块和灵感。这很有挑战性，因为现有的工作已经研究了许多可能的优化技术，例如按位运算，缓存，重用结果集等等。
通过仔细分析现有解决方案并引入新的数据结构，在本研究中，提出了两种新颖的内存集合包含连接算法，在许多情况下比先前的算法快一个数量级。在我们的研究中，我们根据三个基本维度来扩展关系：集合基数，域基数和关系大小。这里，设置基数是关系中设定值的大小;从中选择集合元素的基础域的大小；和关系大小是每个关系中的元组数。
举一个简单的例子，考虑一个在线约会网站，其中每个用户都有一个相关的个人资料集，列出他们的特点，如爱好，兴趣等。用户约会偏好也由一组这样的特征指示。通过用该组用户简档执行该组用户偏好的集合包含连接，约会网站可以确定用户的所有潜在的约会匹配，将每个偏好集与其简档包含所有期望特征的所有用户配对。

二、对算法的理解
1.算法1

合的简明表示，并在执行实际集合比较之前使用签名比较作为过滤操作。在散列连接的精神中，SHJ的工作原理如下：（1）对于S中的每个元组，计算s.sig，并将（s.sig，s）插入到散列映射（idx）中;（2）对于R中的每个元组r，计算r.sig，枚举r.sig的所有子集，检查哈希映射中具有此类签名的所有元组（因此在S中），将它们与r进行比较。这种方法的伪代码可以在算法1和算法2中找到。这里我们将SHJ分成两部分：一个可以重用于其他算法的广义签名连接框架（算法1）;并且，在SHJ（算法2）中使用的枚举算法可以用更有效的算法（例如，下面的算法4和5）替换。
2.算法2

SHJ启发了其他算法（例如，PSJ [11]和APSJ [12]）。它是计算集合包含连接的最有效的内存解决方案之一。SHJ的一个缺点来自算法2的第2行，其中给定签名的所有子集在哈希映射中被枚举和验证。尽管作者提供了一个非常有效的程序（使用按位运算）来执行此枚举，但这种机制无法在签名长度方面进行扩展，并且因此无法按关系大小进行缩放并设置基数。因此，使用该机制的所有算法也遭受同样的问题。在第III节中，我们通过引入替代数据结构来解决这个问题。
3.算法3

PRETTI是一种非常有效的算法。它只遍历trie一次以生成所有结果。在遍历时自然地执行集合比较，并且最有趣的是，早期的包含结果被重新用于进一步比较。PRETTI有两个主要的弱点。首先，为算法构建了许多辅助数据结构，如trie和倒索引，如果设置基数高，则会占用太多空间。其次，与固定长度签名比较相比，变长集合比较可能是耗时的，特别是当设置基数高时。在我们后来的经验评估中，我们将看到PRETTI对低集基数数据集的表现非常好。但是，由于过多的主存储器消耗和元素比较，它无法扩展到更大的关系或更高的设置基数。在本文后面，我们开发了PRETTI的扩展，以克服这种主存消耗问题。
4.算法4

例如，如果我们想在表I中找到u1 的包含关系，我们首先得到它的签名0111.然后当我们运行算法4时，访问图2左侧分支中的所有节点并将其放在队列中。最后，返回叶节点处的p1 和p2 。
这种方法的局限性在于有许多不必要的节点在trie中只有一个子节点（我们后来将其称为单分支节点）。

5.算法5

我们在算法5中对Patricia尝试定义子集生成过程。它类似于算法4，唯一的区别在于，不是一次比较一个比特，而是比较比特段（来自合并的单分支节点）在每个节点。最后，具有包含关系的签名存储在结果列表中而不是队列q中。当然，我们可以再次重用算法1（通过在第5行调用PATRICIA ENUM）来执行连接。我们将此方法称为基于Patricia Trie的签名加入（PTSJ）。

6.算法6

合并相同的集合：在trie的帮助下，相同签名的元组自然地组合在一起。如果我们更进一步，维护具有相同集合元素的元组的映射列表，同时考虑它们输出，我们节省了重复比较的成本。该策略适用于我们的PTSJ实施。在创建时不会引入明显的开销，效果很好.虽然我们的算法是为R设计的S，可以很容易地修改它来执行以防我们想重用现有索引.
这里我们以算法4为例进行说明;算法5可以以类似的方式改变。唯一需要触及的地方是if-else语句（第7行到第10行）。应该切换两个案例处理语句，如算法6中给出的那样。此外，在算法1中设置

7.算法7

8.算法8

除了必须在每个节点中多次连接来自倒排索引的元组列表，因为每个节点都包含多个设置元素。通过使用Patricia trie替换标准trie，PRETTI +消耗的主内存比PRETTI少得多。但是，设置比较和元组列表连接仍然发生，与PRETTI相同。正如我们在实证研究中所看到的，PRETTI +总是比PRETTI更好的选择。

三、对实验过程和实验结果的理解

实验设定

1)合成数据集：我们创建一个数据生成器来生成合成关系。生成器可以生成不同大小的关系，设置基数，域基数等。数据的分布可以根据集合基数和元素而变化。使用Apache Commons Math1生成分布，这是一个强大的数学和统计软件包。我们从一个简单的设置开始，在不同的基数和集合元素上均匀分布。稍后我们测试算法在与Zipf和Poisson分布的关系上的表现，这在现实场景中很常见。
2)真实世界的数据集：我们试验了四个代表性的真实世界数据集，涵盖了低，中，高集合基数的情景。表III中显示了数据集2的一些统计数据。

3)实现细节：我们用Java实现所有算法。根据论文，SHJ的签名长度设置为最佳。PTSJ的签名长度按照第III-D节的建议设定。对于PRETTI和PRETTI +，我们在每个trie节点中维护一个哈希映射，以便在遍历时快速访问子节点。这是昂贵的，但算法必须达到其最佳性能。请注意，这里我们尝试了哈希映射的各种有效实现（例如，Fastutil6，CompactCollections7，Trove8），我们发现JDK 7本身的HashMap实现具有最佳性能和最低主内存消耗。所有实现的算法的开源代码都可在线获得。

4)测试环境：所有实验都在一台机器上执行（Intel Xeon 2.27 GHz处理器，12GB主内存，Fedora 14 64位Linux，JDK 7）。JVM最大堆大小设置为5GB，我们认为即使对于今天的计算机也是如此。在实验中，我们运行每个算法十次，并记录运行时间的平均值，标准偏差和中位数。我们在测量中观察到平均值给出了运行时间的良好估计，并且与总时间相比，标准偏差不显着。因此，在下文中我们仅显示平均运行时间。我们倾向于在可能的情况下测试更大的关系，因为更大的关系和更长的运行时间消除了OS调度引入的随机行为。我们使用taskset命令运行程序，以限制在一个CPU核心上执行。我们稍后提供的运行时间包括构建索引的时间（例如，SHJ的哈希映射和其余算法的trie结构）。我们注意到随着设定基数的增加，存在一种趋势，即索引构建时间与运行时间的百分比减少。这是因为较大的设置基数导致更多的设置元素比较，这相应地占用了更大的运行时间。但总的来说，SHJ和PTSJ的指数构建时间不到总运行时间的1％和5％;另一方面，PRETTI和PRETTI +占用超过70％和20％的运行时间来构建索引。

我们可以通过实验清楚地看到这一点。在图6a中，我们为每个连接算法绘制不同的设置基数设置，每个元组的主内存消耗。在这里我们注意到，虽然实验以217 元组运行，但结果对于更大的关系保持不变。这意味着我们可以根据关系大小和设置基数的信息来估计我们需要多少内存。
我们看到内存消耗基本上与设置基数有线性关系。SHJ，PTSJ和PRETTI +以常数因子变化，这基本上是较长签名（PTSJ），patricia trie（PTSJ和PRETTI +）和倒排索引（PRETTI +）的成本。另一方面，PRETTI需要的内存大约是其他内存的十倍。对于与基数26的关系，它需要每个元组超过10KB，这意味着10GB只有一百万个元组。这在经验上证实了我们对PRETTI的评论。
从图形分析，查询处理，OLAP系统和数据挖掘任务来看，在本文中，我们提出并研究了两种有效且可扩展的集合包含连接算法：PTSJ和PRETTI +。后者适用于低集基数，高域基数设置，而前者是适用于其他场景的更常见算法。如实验所示，这两种新算法在许多情况下可以比现有的最新算法快得多，并且可以通过设置基数，域基数来优雅地扩展，和关系大小。已经对PTSJ进行了详细分析，特别是为了找到关键参数（签名长度）的最佳值。PTSJ的各种扩展使得可以重用索引结构来回答其他类型的连接查询，例如集合相似性连接。

四、论文阅读的心得体会

最先进算法的大部分焦点都集中在基于磁盘的算法上。尽管已经证明这些算法对于加入大量集合非常有效，但这些解决方案的性能受其基础内存处理策略的限制，其中已完成的工作较少。例如，两个先进的基于磁盘的算法PSJ 与主存储器算法SHJ共享相同的内存处理策略。为了跟上不断增长的数据量和现代硬件趋势，我们需要将性能提升到一个新的水平。因此，重新访问（并开发新的）内存中的集合包含连接算法至关重要。这些算法既可以作为主存储器数据库的基本组件，也可以作为外部存储器和其他计算模型和平台的构建块和灵感。这很有挑战性，因为现有的工作已经研究了许多可能的优化技术，例如按位运算，缓存，重用结果集等等。

五、对算法课的意见和建议

经历了两个学期算法课之后，最明显的感觉就是课时不够用。数据结构与算法设计的课程甚至在大学四年里的重要程度都是数一数二的。甚至在以后的工作中，在面试的时候，算法占了绝大部分比重。然而去年的数据结构仅仅上了八周，每周仅仅两次课，而今年的算法设计也仅仅13周，每周两次课。这对于算法类的课程明显是不够的。虽然可以在课后的时间自行学习，但仍然不能满足计算机类学生的需求。