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

Question

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

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.

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

Answer 1

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

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

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