7
问题： 有什么解决方案或技巧，你将不得不处理一个非常大（数TB）的数据库索引在强冗余高冗余？创建一个非常大的哈希数据库的提示
某种倒立的存储？
Postgres有什么可以做的吗？
如果需要，我准备推出自己的存储空间。
（提示：必须是开源的，没有Java，必须在Linux上运行，必须是基于磁盘的，C/C++/Python的首选）
细节：
我需要建立一个非常大型数据库，其中每个记录都有：
- 一些任意元数据（一些文本 字段）包括一些主键
- 一个散列（128位散列，强MD5样）
记录的数量是我认为非常大的数量：几个10到100亿美元）。 行之间存在显着的散列冗余（超过40％的记录将其散列与至少另一个记录共享，一些散列存在于100K记录中）
主要用法是通过散列查找，然后检索元数据。 次要用途是通过主键查找，然后检索元数据。
这是一个分析类型的数据库，所以整体负载中等，大部分是读取，很少写入，大部分是批量写入。
当前的方法是使用Postgres，在主键和哈希列上的索引上使用索引。该表在批处理中加载关闭哈希上的索引。
所有的索引都是btrees。 哈希列上的索引正在变大，比表本身大或大。在120 GB的桌上，重新创建索引需要大约一天的时间。查询表现非常好。
问题是目标数据库的预计大小将超过4TB，基于400GB的较小数据集的测试，占总目标的10％左右。一旦在Postgres中加载，不幸的是超过50％的存储被哈希列上的SQL索引使用。
这太大了。而且我认为哈希中的冗余是存储更少的机会。
还要注意，虽然这描述了问题，但还是有一些需要创建的表。
现在128位散列并不是真正的加密等级。你有没有试过不使用索引，而是根据散列的前8位进行分区？ – 2011-03-15 14:41:51
@Tyler 128位MD5或截断的SHA1对我来说是不错的加密。至少它有很好的关键范围。我尝试不使用索引，查找性能很糟糕。你可以详细说明关键分区吗？ – 2011-03-15 14:43:41
因此，使用索引并占用磁盘空间。优化速度或空间，选择一个。 – 2011-03-15 14:45:47