鉴于固态磁盘 (SSD) 的价格正在下降，并且很快将作为系统驱动器变得更加普遍，并且考虑到它们的访问速率明显高于旋转磁介质，那么在本地使用 SSD 时，哪些标准算法将获得性能提升？贮存？例如，SSD 的高随机读取速度使得基于磁盘的哈希表之类的东西成为大型哈希表的可行性；4GB 的磁盘空间很容易获得，这使得散列到 32 位整数的整个范围是可行的（尽管查找比填充更多，但这仍然需要很长时间）；虽然由于访问速度的原因，这种大小的哈希表无法与旋转媒体一起使用，但对于 SSD 来说，这应该不是什么大问题。
是否还有其他领域即将过渡到 SSD 将提供算法性能的潜在收益？我宁愿看到关于一件事如何运作的推理，而不是意见；我不希望这引起争议。
您的哈希表示例确实是受益的关键数据库结构。无需将整个 4GB 或更多文件加载到内存中来探测值，可以直接探测 SSD。SSD 仍然比 RAM 慢几个数量级，但在磁盘上有一个 50GB 的哈希表是相当合理的，但在 RAM 中则不然，除非你花大价钱买大铁。
一个例子是国际象棋位置数据库。我有超过 50GB 的散列位置。有复杂的代码来尝试在哈希中将彼此靠近的相关位置分组，因此我可以一次分页 10MB 的表，并希望将其中的一些重用于多个相似的位置查询。有大量的代码和复杂性来提高效率。
用 SSD 替换后，我能够放弃集群的所有复杂性，只使用非常愚蠢的随机散列。我的性能也得到了提升，因为我只从磁盘中获取我需要的数据，而不是 10MB 的大块。延迟确实更大，但净加速是显着的.. 超级干净的代码（20 行，而不是 800+），也许更好。
SSD 仅在随机访问时要快得多。对磁盘的顺序访问它们的性能仅是主流旋转驱动器的两倍。许多 SSD 在许多情况下性能较差，导致它们的性能更差，如此处所述。
虽然 SSD 确实有很大的进步，但它们仍然比 CPU 操作和物理内存慢得多。对于您的 4GB 哈希表示例，您可能能够维持 250+ MB/s 的 SSD 访问随机哈希表存储桶。对于旋转驱动器，您很幸运能打破个位数的 MB/s。如果您可以将这个 4 GB 的哈希表保存在内存中，您可以以每秒千兆字节的速度访问它 - 甚至比非常快速的 SSD 快得多。
引用的文章列出了 MS 在 SSD 上运行时为 Windows 7 所做的几项更改，这可以让您了解可以考虑进行的更改类型。首先，用于从磁盘预取数据的 SuperFetch 被禁用 - 它旨在绕过 SSD 缓解的磁盘随机访问缓慢的时间。碎片整理被禁用，因为分散在磁盘上的文件不会影响 SSD 的性能。
事实上，任何你能想到的算法都需要大量的随机磁盘 I/O（随机是关键词，这有助于将局部性原则抛给鸟类，从而消除大量缓存的用处） .
我可以看到某些数据库系统从中受益。MySQL，例如使用 MyISAM 存储引擎（其中数据记录基本上是美化的 CSV）。然而，我认为非常大的哈希表将是你最好的例子。
SSD 对于随机读取要快得多，对于顺序读取要快一些，而对于写入（随机或非随机）则要慢一些。
因此，基于磁盘的哈希表对 SSD没有用处，因为现在更新它需要大量时间，但搜索磁盘变得（与普通硬盘相比）非常便宜。
不要自欺欺人。SSD 仍然比系统内存慢很多。任何选择使用系统内存而不是硬盘的算法仍然会快得多，所有其他条件都相同。