最快的基于磁盘的解决方案，可缓存数万亿个唯一 md5 哈希答案

【问题标题】：Fastest disk based solution to cache trillions of unique md5 hashes最快的基于磁盘的解决方案，可缓存数万亿个唯一 md5 哈希
【发布时间】：2020-01-12 23:45:31
【问题描述】：

是否有一个非常低延迟的基于磁盘的缓存解决方案，我可以使用它来仅存储唯一值（不是键+值）？

我的脚本需要跟踪它已处理的文件，因此它不会重做任何工作。我需要检查缓存来搜索文件的 md5 哈希，如果它不存在，我会处理文件并将哈希添加到缓存中。

有没有比使用基于键值的解决方案更快的基于磁盘的缓存解决方案？

【问题讨论】：

首先，我们来决定空间是否实用。 “万亿”的 16 字节数量 = 一个非常巨大的磁盘。同时，“快”意味着 SSD。有 100TB 固态硬盘可用的硬件吗？

标签： database performance caching indexing nosql

【解决方案1】：

试试LevelDB。

它是一个键值对存储，但由于trie 结构而非常紧凑。

更少的空间使用 => 更少的 I/O => 更好的性能。

不确定“trillions”（一万亿 MD5 哈希值将是 16,000 TB），但比特币核心以及以太坊实现都使用 LevelDB。

【讨论】：

你知道用什么术语来描述只存储值（而不是键值存储）吗？我想我现在只需要使用 LevelDB 将 md5 哈希存储为键，并将 null 作为值。

【解决方案2】：

在您的情况下，不需要“有序键值存储”。也就是说，您可以依赖普通的键值存储（直接 dbm 继任者）：

优秀的候选人是：

tokyo cabinet 它具有基于哈希的格式，在您的情况下可能会更快。
gdbm

如果数据集适合内存，您可能需要尝试 LMDB。

我不推荐LevelDB，因为它很慢。

【讨论】：

谢谢。您提到 LevelDB 很慢，比您列出的选项慢多少？
显然，不多，最好的事情是对自己进行基准测试。以下是一些基准：lmdb.tech/bench/ondisk

【解决方案3】：

算一下。 1 万亿个 MD5，没有任何技巧，将占用 16TB 的磁盘空间。我认为这远远超过您的 RAM 大小。

由于每次 MD5 查找本质上是对磁盘的“随机”探测，因此每次检查必然会命中大约 1 个磁盘。

例如，如果 SSD 读取时间为 1 毫秒，则插入（或检查）一万亿个哈希需要 1e9 秒。那是 30 年。

我的数学有很多缺陷，但我认为这表明今天存储和检查一万亿个随机的东西是不切实际的。

如果您想将它降低到 10 亿个 MD5，现在我们正在进入 RAM 大小的范围。但是您可能希望保留数据？因此，您确实需要一些类似数据库的工具来为您进行持久化，同时纯粹在 RAM 中进行检查（CPU 速度）。

在任何情况下，我都会考虑编写将 MD5 分成 2 或 3 个块的代码，然后像目录结构一样使用这些块。在底层，最后一个块有一组可变长度的值。每个可能有 8 个字节长。这需要对一堆只有 MD5 大小的数字进行线性或二进制搜索。这里的节省有助于补偿结构其余部分的各种开销，以及将块写入磁盘的需要。因此，我仍然预计需要大约 16GB 的 RAM 来容纳 10 亿个 MD5。

鉴于这种方法，几乎所有数据库引擎都已经准备好合理高效地完成大部分工作。最低级别是包含多个 8 字节块的某种类型的 BLOB。

另一个使用技巧... 让我们看看 MD5 的前 5 个字节。 5 个字节中有上万亿个不同的值。如果您的数据集中只有十亿个条目，那么检查这 5 个字节有 99.9% 的机会正确说出“md5 不在数据集中”，而说出“md5 可能 em> 在数据集中”。在前一种情况下，您只需 5GB 就可以快速获得 10 亿个项目的答案。在后一种情况下，您可能必须转至磁盘并且速度较慢。平均时间仍然更好。这有助于提高检查速度。（但不涉及加载速度。）

【讨论】：