SSD 旧文引发新讨论，技术需要不断尝试才能不断优化

在微博上，PPTV 的网站运维总监诸超分享了一篇来自网站 Hellodb 的旧博文，作者是淘宝数据库团队负责人张瑞（微博账号： HelloDBA ）。文章标题是：《我对技术方向的一些反思》。在这篇写于 10 年的文章中，张瑞分享了关于 SSD、可扩展数据库架构、Oracle 和 MySQL、小型机和存储、NoSQL 和 Database、DBA 能力和技术发展趋势等多方面的话题。

最引起诸超兴趣的，是张瑞关于 SSD 的思考，而且网友也对此提出了他们的见解。

文中，张瑞指出了自己选择 SSD 的目的和遇到的问题：

我们曾经使用了一批 SSD 的 PC，用来做数据库的服务器，用来提高数据库服务器的 IO 能力。

如果将 SSD 作为主存储，存在一些问题：

• SSD 的稳定性还不够好，我们碰到了一些 SSD 盘损坏和 SSD 与机器不兼容的情况发生。
• SSD 的容量盘都比较小，考虑到稳定性的问题，如果做 RAID 会进一步损失容量，性价比不高。
• SSD 属于 NAND 类型的 flash，写操作不仅会产生“磨损”，而且随着碎片的不断增加，写操作的性能会不断下降。

张瑞认为：

SSD 并不太适合作为数据库的主存储，写操作并不是 SSD 的特长，而且作为主存储的代价过高。SSD 更加适合作为内存和磁盘之间的一层 cache，降低读操作的延迟时间，我们将其称为 flash cache。

将 SSD 和 Flash 卡配置在 PC 服务器上，与普通 SAS 或者 SATA 磁盘混插，采用数据库 flash cache 技术，可以达到一个非常理想的性能，代价又不是特别高。我们也在考虑采用 MySQL 的 flash cache 架构。但是，如果你采用大型的存储设备，比如 EMC 和 HDS，存储的 cache 实际上已经起到了一个二级缓存的作用，就没有太多必要使用 SSD 或者 Flash 卡了。

使用 SSD 还可以解决写操作的响应延迟，比如 Oracle 数据库的 redo，因为每次 commit 都必须物理写入到磁盘上，所以将 redo 放在 SSD 上，可以提高写的响应延迟，但是不必将数据文件放在 SSD 上，因为它们并不是必须被写入的。要注意的是，SSD 可能出现随着大量的写操作性能下降的情况。在我们的测试中，SLC 的写能力比较稳定，而 MLC 的写能力会出现下降的情况。

张瑞的结论是：

SSD 一定有光明的未来，取代磁盘只是个时间问题，只是我们还需要等待技术更加成熟，价格更加便宜。

绿茶饮士在看过后指出：

说来说去就是 SSD 虽然性能还行，就是性价比还不够高，如果再考虑高可用成本就更高了。还是从架构方面解决吧，实现热点功能，把 SSD 用于那些最需要加速的少数热点数据，其他冷门数据还是用 SATA 吧。人尽其才，物尽其用。

诸超的回复是：

其实不止 SSD；关于 MySQL 和 Oracle 选型，其实讲的很好的；不过后来淘宝走了彻底的去 O 的路；关于 NOSQL 和关系数据库的，都讲的不错；关于 SSD 的，redo 放 SSD 其实我不赞同。

绿茶饮士提到：其实 fusion io 也就是在 SSD 上嵌入了热点功能和存储单元健康检查容错功能。

他还指出 SSD 和 Fusion IO 在接口和存储单元上的区别：

接口不同，存储介质应该差不多，也有写寿命问题，不过他们控制器的算法让每个存储单元的磨损几率尽量相同，再就是在存储单元级实现了 RAID，RAID 几就不太清楚了，应该是 RAID5。而且健康检查会做得比较深度，有问题就标坏块。容量会越用越小。

在那篇文章的结尾部分，张瑞对技术发展趋势提出了自己的看法：

虽然现在的发展趋势是分布式架构，但是说不定过几年又会出现超级计算机，从而又走向集中式的道路。我们要做的是能够看到 3 年内技术发展的一个方向，适应技术发展的潮流，并不断调整目标，在解决问题的过程中不断优化。问题和技术都是不断发展的，试图设计一个完美的解决方案是不现实的，在一个问题被解决后，一定会有新的问题冒出来。

选择简单但是不完美的技术解决问题，先做！然后再不断优化。如果不去尝试，我们永远也不知道下一步要做什么，总是停留在对技术方案本身优劣的讨论上，是没有意义的。

人总是在不断反思，不断否定自我的过程中进步的，技术发展也是一样。

最新更新：

在诸超这篇微博的评论中，原作者张瑞现身，指出：

现在很多情况已经发生了变化。

让我们关注 HelloDB 网站，共同期待他继续分享 11、12 这两年的思考成果。