在数据库中存储哈希的最佳方法

Question

我需要从性能和存储角度找到最佳方式来存储哈希，例如MD5。当前数据库是MariaDB，将来可能是Oracle。这个表将包含数亿或数十亿条记录，每条记录应包括一个哈希值，可用于搜索。目前我使用varchar（32）来存储哈希值，但我认为这种类型不是最优的。我还考虑过像二进制、字符之类的类型，同时我了解到对于稳定大小的哈希，最好使用char而不是varchar以及binary而不是varbinary。此外，我还考虑将哈希转换为数字，这样会更好吗？

那么，在数据库中存储哈希的最佳方法是什么？

- Andriy Mytroshyn

---

哈希计算的结果是二进制值，因此应将其存储为二进制值。转换为十六进制字符串会使其存储大小增加一倍，而转换为数字则会增加更多的大小。 - dnoeth

你为什么要使用哈希表？哈希表的来源是什么？哈希表如何被使用？ - Bohemian

VARCHAR2数据类型有什么问题吗？它完全适合您的需求。但我可能会增加长度，以便能够生成更多唯一的哈希值。顺便说一句，如果哈希是建立在一个单独的列上的，您可能不需要计算和存储它进行搜索，而是使用哈希分区。 - Rusty

目前我使用MD5，但可能会更改为SHA256，哈希的源是其他字段内行的数据。哈希将用于公共身份识别和证明正确性（即数据未被篡改）。目前varchar是正常的，但如果表格包含数亿行，并且每行都包括此哈希以进行标识，则可能会变慢。 - Andriy Mytroshyn

它可能会慢，但不是因为VARHCAR。 它与NUMBER或RAW具有相同的性能。 - Rusty

Answer 1

简单来说，每种数据类型都应该以RDBMS支持的本地格式存储。

这适用于Oracle的RAW(16) MD5哈希码。

有些人决定使用VARCHAR格式存储日期列。这样可以实现数据库独立性，但你不能使用RDBMS提供的任何DATE列函数。

无论如何，你应该仔细考虑为什么在数据库中使用哈希列。

如果它是用作快速识别行列变化的替代方法，那么它可以节省大量编码和处理时间。

如果要使用哈希码作为主键，请尝试找到至少一个原因，比起使用序列生成的主键，你会从哈希主键中获得利润。

在你看到所描述的积极效果之前，小心不要仅仅因为某个来源推荐而将哈希用作主键。

- Marmite Bomber

---

至少有一个从哈希键中获益的原因：哈希总是返回相同的值，而序列取决于插入的顺序。我并不是在倡导DataVault 2.0，但能够独立加载父/子表并在不同系统上获得相同的键真的很好。 - dnoeth

我不会将HASH用作键，它只是一个标识符，可用于保证数据的正确性。 - Andriy Mytroshyn

Answer 2

MySQL/MariaDB: BINARY(16)。它占用16个字节，对于MD5已经足够。显然，您需要在列上创建INDEX。

但是让我指出使用哈希的设计缺陷...

如果您有10亿行数据，但无法缓存超过其中的一小部分，那么任何查找都很可能需要磁盘读取。这是由于MD5（或UUID等）的随机性所致。在RAM缓存中（在MySQL/MariaDB的情况下为InnoDB的缓冲池），不太可能有包含您需要的下一个值的块。

算一下吧。未缓存的磁盘块读取速度有多快？对此进行简单的算术运算可以得出每秒可以执行多少次读取。旋转驱动器：10毫秒--> 100次/秒。多线程不会有帮助。RAID分段会有所帮助。

同样，INSERTing也受到约束，大约相同数量的限制。在插入十亿行数据的早期，由于缓存的原因，速度会很快；后来速度会减慢到每秒100行。插入十亿行数据需要几个月的时间。

PARTITIONing不会提高性能。

您可能需要使用代码（无论是SQL还是您的应用程序）在函数提供的内容与BINARY（类似于BLOB）之间进行转换。

- Rick James

Answer 3

在 Oracle 中，使用 RAW 数据类型来存储二进制数据，长度最大为 4000 字节，并使用 BLOB 来存储更大的值。

如果您的哈希函数生成一个数字，则可以使用 UTL_RAW.CAST_FROM_NUMBER 函数 将其转换为 RAW 数据类型。

- MT0