Database 创建大型散列数据库的技巧

问题是： 您需要什么解决方案或技巧来处理在高冗余强散列上索引的非常大（数TB）的数据库

某种反向存储

对博士后有什么办法吗

如果需要的话，我随时准备推出自己的存储

（提示：必须是开源的，没有Java，必须在Linux上运行，必须是基于磁盘的，最好是C/C++/Python）

详情如下:

我需要创建一个非常大的数据库，其中每个记录都有：

• 一些任意元数据（一些文本） 字段），包括一些主键
• 一个散列（128位散列，类似于强MD5）

我认为记录的数量相当大：几十亿到一千亿）。 跨行散列有大量冗余（超过40%的记录的散列与至少另一个记录共享，一些散列存在于100K记录中）

主要用途是通过哈希进行查找，然后检索元数据。 第二种用法是按主键查找，然后检索元数据

这是一个分析型数据库，因此总体负载是中等的，主要是读取，很少写入，主要是批处理写入

当前的方法是使用Postgres，主键上有一个索引，哈希列上有一个索引。该表在哈希上的索引关闭的情况下批量加载

所有索引都是b树。 哈希列上的索引越来越大，与表本身一样大或更大。在120 GB的表上，重新创建索引大约需要一天的时间。但是查询性能相当好

问题在于，基于400GB的较小数据集（约占总目标的10%）的测试，目标数据库的预计大小将超过4TB。一旦加载到Postgres中，不幸的是，哈希列上的SQL索引正在使用超过50%的存储空间

这太大了。我觉得散列中的冗余是存储更少数据的一个机会

---

另外请注意，虽然这描述了问题，但仍有一些表需要创建。

您可以创建一个仅包含id和哈希的表，以及包含索引、元数据和哈希id的其他数据。这样做，可以防止在表中写入同一个哈希多达10万次。

现在128位哈希并不是真正的加密级别。您是否尝试过不使用索引，而是基于散列的前8位进行分区？@Tyler 128位MD5或截断的SHA1对我来说是相当不错的加密。至少它很好地使用了键范围。我尝试不使用索引，查找性能非常糟糕。你能详细说明一下键分区吗？所以使用索引并占用磁盘空间。优化速度或空间，选择一个。@Tyler:thx，但是我认为速度和空间都有优化的空间，坦率地说，在这个规模上，它们开始紧密地联系在一起：更少的空间意味着更快更有趣、更简单。这确实有道理！现在有比btrees更好的哈希索引了吗？我使用了这种方法，并在postgres中构建了一个反向存储（也称为键/值表，其值是一个元组数组，在使用指针进行更新时扩展，实际上是一个发布列表）。。。这些都提供了有趣的大小缩减，是的，创建/更新时间真的变慢了：现在我真的错误地选择了一个真正的专用倒置存储容器，比如zettair、sphinx或xapian。