c++ - IRLBot Paper DRUM 实现 - 为什么要将键、值对和辅助桶分开？

Question

我正在尝试根据 IRLBot paper 在 Java 中实现 DRUM(具有更新管理的磁盘存储库) (相关页面从 4 开始)但作为快速总结，它本质上只是一种针对持久存储库批量更新(键，值)对的有效方法。在链接的论文中，它被用作爬虫 URLSeen 测试、RobotsTxt 检查和 DNS 缓存背后的 Backbone 。

在 c++ 中完成了一个有用的实现 here ，它以一种更易于理解的方式展示了架构。为了便于引用，这是 c++ 实现的架构图:

我很难理解的部分是将(键，值)桶和辅助桶分开的原因。带有 c++ 实现的文章说明如下:

During merge a key/value bucket is read into a separate buffer and sorted. Its content is synchronized with that of the persistent repository. Checks and updates happen at this moment. Afterwards, the buffer is re-sorted to its original order so that key/value pairs match again the corresponding auxiliary bucket. A dispatching mechanism then forwards the key, value and auxiliary for further processing along with the operation result. This process repeats for all buckets sequentially.

因此，如果(键，值)桶的顺序需要恢复到辅助桶的顺序，以便将(键，值)对与辅助信息重新链接起来，为什么不只保留(键, value, aux) 值一起放在单个桶中？将它们分开的原因是什么？将它们放在一起会更有效吗(因为您不再需要恢复存储桶的原始未排序顺序)？

Answer 1

在合并时，DRUM 会加载相应存储桶的键/值磁盘文件的内容，并根据使用的操作使用后备数据存储检查、更新或检查+更新该文件的每个条目。

因此，辅助磁盘文件是无关紧要的，不将辅助数据加载到内存中只是在排序时节省了一些内存占用空间，DRUM 试图将其最小化以处理超过 60 亿个条目的唯一性。如果是 f.e. RobotsCache 的辅助数据甚至可以是每个条目 100kb。然而，这只是我自己的一篇论文，如果你真的想知道为什么他们将这两个缓冲区和磁盘文件分开，你应该问问 Dmitri Loguinov。

我还创建了一个基于 Java 的 DRUM implementation (也是基于 Java 的 IRLbot implementation )，但两者可能都需要更多的爱。还有一个名为 DRUMS 的基于 Java 的 Github 项目。它使用用于存储基因组代码的选择功能扩展了 DRUM。