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

Question

我需要从性能和存储角度找出存储哈希的最佳方法，例如MD5。目前的数据库是MariaDB，未来它可能是Oracle。该表将包含数亿或数十亿条记录，每条记录应包含一个可用于搜索的哈希值。此时用于存储哈希我使用varchar（32），但我认为这种类型不是最优的。我也考虑像二进制，char这样的类型，我也理解为稳定大小，就像在hash中一样，最好使用char而不是varchar和binary而不是varbinary。另外，我考虑将哈希转换为数字，它会更好吗？ 那么在数据库中存储哈希的最佳方法是什么？

Answer 1

简短的回答是每个数据类型都应该以RDBMS支持的本机格式存储。

这是针对MD5哈希码的 Oracle RAW(16) 。

您看到了这种类比 - 有些人决定使用VARCHAR格式存储DATE列。你得到 数据库独立性，但您无法使用DATE为RDBMS列提供的任何功能。

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

如果它可以替代快速识别行列的更改，它可以为您节省大量的编码和处理。

要使用哈希码作为键，尝试找到至少一个原因，即使用HASH键，与使用序列生成键相比。

小心不要将HASH用作关键词，因为这是从某些来源推荐的，然后才能看到你所描述的正面效果。

Answer 2

MySQL / MariaDB：BINARY(16)。它占用16个字节，足以用于MD5。显然，您需要在列上添加INDEX。

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

如果您有十亿行，但无法缓存超过一小部分，那么任何查找都很可能需要磁盘命中。这是因为MD5（或UUID或......）的随机性。 RAM内缓存（InnoDB的缓冲池，在MySQL / MariaDB的情况下）不太可能包含您需要的下一个值。

算一算。磁盘块（未缓存）的读取速度有多快？通过一些算术，您可以获得几秒钟的读取次数。旋转驱动：10ms - > 100读/秒。多线程无济于事。 RAID条带化将有所帮助。

同样，INSERTing限制在大约相同的数量。在插入十亿行的早期，由于缓存，事情会很快;之后它会减慢到100行/秒。插入十亿行将需要几个月。

PARTITIONing将不提高效果。

您可能需要代码（在SQL或您的应用程序中）在函数提供的任何内容和BINARY（类似于BLOB）之间进行转换。

Answer 3

在Oracle中，使用the RAW data type for binary data最多4000个字节，使用BLOB获取更大的值。

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