java - SSD 上的键/值存储速度极慢

Question

我确定的是:

• 我在 Linux 上使用 Java/Eclipse，并尝试在磁盘上分别存储大量 16/32 字节的键/值对。 key 是完全随机的，由 SecureRandom 生成。
• 速度恒定在约 50000 次插入/秒，直到达到约 100 万个条目。
• 一旦达到此限制，java 进程每 1-2 秒振荡一次，从 0% CPU 到 100%，从 150MB 内存到 400MB，从 10 插入/秒到 100。
• 我尝试使用 Berkeley DB 和 Kyoto Cabinet 以及 Btrees 和 Hashtables。结果相同。

可能有什么贡献:

• 它在 SSD 上写入。
• 对于每个插入，平均有 1.5 次读取 - 不断交替读取和写入。

我怀疑在达到某些缓存/缓冲区限制之前，不错的 50000 速率已经达到。那么速度变慢可能是由于 SSD 没有处理混合在一起的读/写，正如在这个问题上所建议的:Low-latency Key-Value Store for SSD .

问题是:
这种极度减速可能从何而来？这不可能全是 SSD 的错。许多人愉快地使用 SSD 进行高速数据库处理，我敢肯定他们经常混合读取和写入。

谢谢。

编辑:我已确保移除任何内存限制，并且 java 进程始终有空间分配更多内存。
编辑: 删除读数并仅进行插入不会改变问题。

上次编辑: 作为记录，对于哈希表，它似乎与初始数字桶有关。在 Kyoto 机柜上，该数字无法更改，默认为约 100 万，因此最好在创建时正确设置数字(要存储的最大记录数的 1 到 4 倍)。对于BDB，它被设计为逐步增加桶的数量，但由于它是资源消耗，最好提前预定义数量。

Answer 1

您的问题可能与您正在使用的数据库的强持久性保证有关。

基本上，对于任何符合 ACID 的数据库，每次数据库提交至少需要调用一次 fsync()。这必须发生以保证持久性(否则，更新可能会在系统故障的情况下丢失)，同时也是为了保证磁盘上数据库的内部一致性。在 fsync() 调用完成之前，数据库 API 不会从插入操作返回。

fsync() 在许多操作系统和磁盘硬件上，甚至在 SSD 上，都是非常的重量级操作。 (电池或电容器支持的企业级 SSD 是一个异常(exception)——它们基本上可以将缓存刷新操作视为空操作，以避免您可能遇到的延迟。)

一个解决方案是在一次大交易中处理您的所有商店。我不知道 Berkeley DB，但对于 sqlite，性能可以大大提高。

要弄清楚这是否是您的问题，您可以尝试使用 strace 观察您的数据库写入过程并寻找频繁的 fsync() 调用(每秒多次调用是一个非常强烈的提示)。

更新:如果您绝对确定您不需要需要耐用性，您可以尝试来自 Optimizing Put Performance in Berkeley DB 的答案。 ;如果这样做，您应该研究 Berkeley DB 的 TDS(事务数据存储)功能。