【发布时间】：2015-06-12 01:06:16
【问题描述】：
我正在构建一个地图切片存储，需要存储 15 亿~3KB 的 blob。其中超过 95% 是重复的。是否有 NoSQL 存储引擎可以避免存储相同的值？
我当然可以实现双重去引用，例如键->哈希->值。如果散列是 MD5，16 字节散列将仅用于散列就用掉 24GB，加上每项开销，这可能更多。还有什么更高效的吗？
谢谢！
【问题讨论】：
标签： maps key-value-store large-data nosql
【发布时间】：2015-06-12 01:06:16
【问题描述】：
双重取消引用是可行的方法 - 通过不存储重复数据，您可以节省 4-5TB 的数据，因此存储 24GB 的哈希值是值得的。此外，您只需在插入和更新时计算哈希函数，而不是在查找或删除时计算。
为了减少查找时双重取消引用的成本，您可以使用内存缓存来补充磁盘键值数据库，例如Redis - 您可以缓存经常访问的key->hash 对以避免在主数据库上进行两次查找，或者您可以直接将整个key->hash->blob 结构存储在缓存中（前者实现起来要简单得多，因为您不需要'不需要从主数据库复制双重取消引用，而如果只有一小部分 blob 处于活动状态，则后者更有意义。
您可以使用更简单/更小的散列 - probability of a hash collision 是 1 - e^(-k^2 / 2N) 其中 k 是要散列的值的数量，N 是散列的大小，所以 64-位散列有大约 12% 的机会发生冲突，而一个好的 128 位散列发生冲突的可能性很小。 MurmurHash 有 64 位和 128 位版本，因此您可以在两者之间进行试验，它比 MD5 更快，主要是因为 MD5 是一种加密哈希函数，而 Murmur 没有加密安全的额外费用/复杂性（I' m 假设您不关心任何人试图故意生成哈希冲突或类似的东西）。一些键值存储也使您的设计容错变得相对容易，例如，您可以将哈希存储在 Riak Map 中，并带有一个标志，指示该哈希值是否存在任何冲突 - 如果为 false 则只需返回 blob，否则回退到选项 2（例如，索引 blob 变成了两个 blob，哈希冲突被压缩/tarred 以及一个 CSV，其中键对应于哪个 blob；即使使用 64 位哈希，此代码路径也会不经常使用，因此实现简单性可能胜过性能）；问题是减少的内存/散列开销是否弥补了冲突容忍的复杂性。
【讨论】：