【发布时间】：2011-07-15 20:39:05
【问题描述】：
问题： 您需要什么解决方案或技巧来处理一个非常大（数 TB）的数据库，该数据库以高冗余的强哈希为索引？
某种倒置存储？
Postgres 有什么可以做的吗？
如果需要，我已准备好推出自己的存储空间。
（提示：必须开源，无 Java，必须在 Linux 上运行，必须基于磁盘，首选 C/C++/Python）
详情：
我需要创建一个非常大的数据库，其中每条记录都有：
- 一些任意元数据（一些文本 字段），包括一些主键
- 一个哈希（128 位哈希，类似 MD5 的强）
记录的数量是我认为相当大的：几十到上千亿）。 跨行的散列存在显着冗余（超过 40% 的记录的散列至少与另一条记录共享，一些散列存在于 10 万条记录中）
主要用途是通过哈希查找，然后检索元数据。 次要用途是通过主键查找，然后检索元数据。
这是一个分析型数据库，所以整体负载中等，主要是读取，很少写入，主要是批量写入。
目前的方法是使用 Postgres，在主键上有一个索引，在哈希列上有一个索引。该表是在关闭散列索引的情况下批量加载的。
所有索引都是 btree。 哈希列上的索引越来越大，与表本身一样大或更大。在一个 120 GB 的表上，重新创建索引大约需要一天时间。不过查询性能还是不错的。
问题在于，根据测试，目标数据库的预计大小将超过 4TB，其中 400GB 的较小数据集约占总目标的 10%。一旦在 Postgres 中加载，超过 50% 的存储空间不幸被散列列上的 SQL 索引使用。
这太大了。而且我觉得散列中的冗余是一个减少存储的机会。
另请注意，虽然这描述了问题，但需要创建其中一些表。
【问题讨论】：
-
如今 128 位哈希并不是真正的加密级别。您是否尝试过不使用索引，而是根据散列的前 8 位进行分区？
-
@Tyler 128 位 MD5 或截断的 SHA1 对我来说是不错的加密货币。至少它很好地利用了键范围。我尝试不使用索引，查找性能很糟糕。你能详细说明一下关键分区吗？
-
所以使用索引并占用磁盘空间。优化速度或空间，选择一个。
-
@Tyler：谢谢，但恕我直言，速度和空间优化都有空间，坦率地说，在这种规模下，它们开始相互紧密联系：更少的空间意味着更高的速度
标签： database hash inverted-index bigdata