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

阅读数:1655 2012 年 8 月 26 日

话题:OracleMySQLDevOps架构

微博上,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 这两年的思考成果。