索引大文本的最佳散列技术

Question

幸运的是，当我尝试在大长度文本列上创建唯一索引时，Erwin Brandstetter救了我。

插入率的上限是每年数百亿行。

对于我的实现，散列永远不需要离开数据库，但散列数据必须经常与外部数据进行比较才能存在。

根据我针对这些目的进行优化的有限经验，我假设散列的最佳数据类型是bytea. 替代方案当然是更长的十六进制字符串。

bytea这些哈希的最佳数据类型是否正确？

如果bytea不是最优的，什么是最优的？

我的意图应该如何实现？

澄清

我根据 Erwin Brandstetter 的建议使用文本的哈希值，以确保大文本是唯一的。我有限的理解是，原始二进制数据总是性能最好的，尤其是与字符串相比时。

只需比较哈希是否存在即可抢占唯一性违规，因此哈希很高兴永远不需要离开数据库。由于 libpqxx 令人难以置信的设计，看起来好像数据可以简单地通过准备好的语句输入并使用(decode(md5($1::text), 'hex')). 当我更熟悉bytea通过 libpqxx 3.1 插入时，我会将其移至 C++。

对于此实现，冲突是可以接受的，因为可以在不破坏系统的情况下重建数据以符合要求。

如果愉快地达到最大吞吐量，那么应该预期经济资源将可用于容纳它；因此，主要关注点始终是性能，所以如果我对 Postgres 的功能及其分区表处理这些行数的能力的理解是准确的，那么它有望在很长一段时间内成为该工作的正确工具。幸运的是，超过几秒钟的数据永远不会改变，我的理解是 Postgres 分区表可以将这些数据制成碎肉。如果没有，这将是那些好问题之一。

Answer 1

bytea 将是存储散列的最佳选择。

无论如何，它都会作为十六进制字符串传入/传出数据库，除非您使用 PostgreSQL 的二进制有线协议（由 libpq 支持，部分由 PgJDBC 支持）来传输它们。

为获得最佳结果，存储为 bytea 并让客户端应用程序使用PQexecParams请求二进制结果的调用。

虽然在重新阅读时，这令人困惑：

对于我的实现，hash 永远不需要离开数据库，但是散列数据必须经常与外部数据进行比较才能存在

您的意思是不传输散列进行比较，原始未散列的文本数据是吗？如果是这样，则上述内容无关紧要，因为二进制协议对文本形式的数据没有任何好处。

另外：“数百亿”行很多。PostgreSQL 的每行开销很大，为 28 字节，因此您将损失大量空间。尤其是当您也将索引开销考虑在内时。PostgreSQL 是适合这项工作的工具吗？

最后一个想法：有了这么多行，你就进入了哈希冲突领域。您是否关心是否有可能——尽管不太可能——两个不同的字符串具有相同的哈希值，从而报告不正确的唯一违规？如果这是一个问题，那么哈希上的唯一 b 树索引可能不是适合该工作的工具。