问题： 您需要使用哪些解决方案或技巧来处理在具有高冗余的强哈希上索引的非常大（多TB）的数据库？
某种倒置存储？
Postgres有什么可以做的吗？
如果需要，我准备推出自己的存储空间。
（提示：必须是开源的，没有Java，必须在Linux上运行，必须基于磁盘，首选C / C ++ / Python）
细节：
我需要创建一个非常大的数据库，其中每条记录都包含：
记录的数量是我认为非常大的数量：数十到100亿的数十亿。 跨行的哈希存在显着冗余（超过40％的记录的哈希与至少另一条记录共享，一些哈希存在于100K记录中）
主要用法是通过哈希查找，然后检索元数据。 第二种用法是按主键查找，然后检索元数据。
这是一个分析型数据库，所以总体负载是中等的，大部分都是读取的，很少写入，主要是批量写入。
当前的方法是使用Postgres，主键上有索引，哈希列上有索引。该表是批量加载的，并且关闭了散列上的索引。
所有索引都是btree。 哈希列上的索引越来越大，比表本身大或大。在120 GB的表上，重新创建索引大约需要一天。查询表现相当不错。
问题是目标数据库的预计大小将超过4TB，基于400GB的较小数据集的测试，约占总目标的10％。一旦加载到Postgres中，遗憾的是，超过50％的存储被哈希列上的SQL索引使用。
这太大了。我觉得哈希中的冗余是存储更少的机会。
另请注意，虽然这描述了问题，但仍需要创建一些这些表。
答案 0 :(得分：5)
您可以创建一个仅包含id和Hash的表，以及包含index，Metadata和hashId的其他数据。这样做，您可以防止在表中写入相同的哈希值达到100k次。