SSD时代的编程
我想知道即将到来的 SSD 技术如何影响（大多数系统）编程。出现了大量问题，但这里有一些最明显的问题：
- 磁盘访问速度是否可以被视为接近内存速度？
- 如果不是，这是否只是一个临时状态，或者有一些根本原因导致 SSD 永远不会像 RAM 一样快？
- B 树（及其近亲）仍然有用吗？
- 如果是的话，是否对 SSD 的 B-Tree（B+-Tree、R-Tree 等）进行了任何调整或修改？如果没有，是否还有其他专为 SSD 设计的数据结构？
I am wondering how the oncoming SSD technology affects (mosty system) programming. Tons of questions arise, but here are some most obvious ones:
- Can the speed of disk access be considered anywhere near to the memory speed?
- If not, is it either just a temporary state, or there are some fundamental reasons why SSD won't ever be as fast as RAM?
- Are B-Trees (and its cousins) still relevant?
- If so, are there any adjustments or modifications of B-Trees (B+-Trees, R-Trees, etc.) made for SSD? If not, are there any other data structures crafted for SSD?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
诚然，SSD 消除了读取的寻道时间问题，但在 SSD 上高效写入却相当棘手。我们一直在对这些问题进行一些研究，同时寻找将 SSD 用于 Acunu 存储核心的最佳方法。
您可能会发现这些有趣：
It is true that SSDs eliminate the seek time issue for reading, but writing efficiently on them is quite tricky. We have been doing some research into these issues while looking for the best way to use SSDs for the Acunu storage core.
You might find these interesting:
很容易想到一个因素...
越来越多的趋势是将硬盘驱动器视为磁带驱动器，因为使磁头在相隔较远的磁道之间移动的相对成本较高。这导致人们努力优化数据访问模式，以便磁头可以在表面上平滑移动，而不是随机寻找。
SSD 实际上消除了寻道损失，因此我们可以不再太担心磁盘上数据的布局。 （更准确地说，由于磨损均衡问题，我们有一系列不同的担忧）。
One factor comes readily to mind...
There has been a growing trend towards treating hard drives as if they are tape drives, due to the high relative cost of making heads move between widely separated tracks. This has led to efforts to optimise data access patterns so that the head can move smoothly across the surface rather than seeking randomly.
SSDs practically eliminate the seek penalty, so we can go back to not worrying so much about the layout of data on disk. (More accurately, we have a different set of worries, due to wear-levelling concerns).
虽然 SSD 的寻道时间比 HDD 的寻道时间快一两个数量级，但与 RAM 相比，这些时间仍然很重要。这意味着与寻道时间相关的问题没有那么严重，但仍然存在。吞吐量仍然比 RAM 低得多。除了存储技术之外，连接也很重要。 RAM 在物理上非常靠近 CPU 和主板上的其他组件，并使用特殊的总线。大容量存储设备不具备这个优势。存在电池支持的 RAM 模块包，可以充当超高速 HDD 替代品，但如果它们通过 SATA、SCSI 或其他典型磁盘接口连接，则仍然比系统 RAM 慢。
这意味着 B 树仍然很重要，为了获得高性能，您仍然需要注意 RAM 中的内容和永久存储中的内容。由于整个架构和物理限制（非易失性写入可能总是比易失性写入慢），我认为这种差距可能会变得更小，但我怀疑它在可预见的未来会完全消失。即使您查看“RAM”，您实际上也没有单一的速度，而是多个级别的越来越快（但更小且更昂贵）的缓存。因此，至少存在一些差异。
While the seek times of SSDs are better than those of HDDs by an order of magnitude or two, compared to RAM, these times are still significant. This means that issues related to seek times are not as bad, but they still are there. The throughput is still much lower than in RAM. Apart from the storage technology, the connections matter. RAM is physically very close to the CPU and other components on the motherboard and uses a special bus. Mass-storage devices don't have this advantage. There exist battery-backed packages of RAM modules which can act as an ultra-fast HDD substitute but if they attach via SATA, SCSI or other typical disk interface, the still are slower than system RAM.
This means that B-trees stil are significant and for high performance you still need to take care of what is in RAM and what is in permanent storage. Due to the whole architecture and physical limitations (non-volatile writes probably always will tend to be slower than volatile ones), I think this gap may become smaller but I doubt it will be completely gone in any foreseeable future. Even if you look at "RAM", you really don't have a single speed there, but several levels of faster and faster (but smaller and more expensive) caches. So at least some differences are there to stay.
我测试了 SSD 和 RamDisk 上的构建时间，SSD 更快一些。
我的同事使用完全不同的设置获得了相同的结果 - HDD 上的构建时间为 9 分钟，RamDisk 上的构建时间为 3 分 30 秒，SSD 上的构建时间为 3 分 0 秒。
I tested build time on SSD and RamDisk, SSD was a little faster.
Same result was achived by my coworker with entirely different setup - build time on HDD was 9 minutes, on RamDisk 3min 30sec, on SSD 3min 0sec.