过去十年，固态硬盘（俗称闪存）已经从根本上改变了计算机信息处理技术。在客户端，U 盘取代了 CD；在服务器端，它有高于 RAM 和磁盘驱动器的性价比。但在过去的几年里，数据库才刚刚开始赶上这一趋势，而且大部分仍然依赖于针对旋转磁盘内部数据结构和存储管理的优化来提升性能。
近日， O’Reilly Media 资深编辑 Andy Oram 发表了一篇文章，他基于对数位数据库专家的采访，详细介绍了闪存如何改变了数据库存储引擎的设计，其中包括 Aerospike、Cassandra、FoundationDB、RethinkDB 和 Tokutek 的代表人物。对于正在设计应用程序和寻找最佳存储方案的读者而言，他们给出的各种方法会有一定的指导意义。
根据介绍，闪存影响数据库存储引擎设计的关键特性如下：
- 随机读：闪存不同于传统磁盘，它像内存一样，不管两次读的物理距离相差多远，它都可以以同样的速度提供数据。不过，它每次会读取整个块，所以，应用程序可能仍然会受益于访问局部性。比如，如果本次读与上次读的位置相近，那么本次操作可能可以直接从内存或者缓存读取数据。
- 吞吐量：有记录的原始吞吐量已达到每秒几十万次的读 / 写，这比磁盘高两个数量级，甚至更高。而且，随着磁盘密度的提高，吞吐量还在增长。
- 延时：据 FoundationDB CEO David Rosenthal 说，通常，闪存的读延时大约为 50 到 100 微秒。而 RethinkDB CEO Slava Akhmechetat 指出，闪存至少比磁盘快 100 倍。不过，闪存的延时已经达到了极限。
- 并行：闪存驱动器提供多个控制器或者单个性能更高的控制器。这对于能够使用多个线程和内核的数据库设计大有裨益，它可以将工作负载划分成许多独立的读写操作。
那么，这些特性对数据库存储引擎的设计有什么影响呢？为了说明这个问题， Oram 介绍了一些企业的现行做法。
Aerospike 是第一款从设计之初就选择了闪存的数据库产品。它将索引存储在 RAM 中，其它数据存储在闪存中。这样，他们可以在 RAM 中快速查找索引，然后从多个闪存驱动器中并行检索数据。由于索引在 RAM 中更新，向闪存写数据的次数就大大减少了。
Cassandra 通过排序数据实现了访问局部性。它的基本数据结构是日志结构的合并树（LSM- 树）。和闪存一起使用时，该结构可以显著减少写操作。据项目负责人 Jonathan Ellis 说，为了保证 LSM- 树的效率，Cassandra 承担了许多碎片整理工作，而大部分应用程序都把这项工作留给文件系统来做。而据 Rosenthal 说，FoundationDB 团队的做法则与此相反，他们依赖闪存控制器解决写碎片问题。闪存控制器可以完成 LSM 在数据库引擎层面所做的工作。现在，大部分闪存控制器都提供了这些算法。这里有一点需要注意，实现访问局部性会增加写操作的开销。在闪存吞吐量如此大的情况下，这部分开销可能会超过多次读操作的开销。
Tokutek 提供了一个聚簇数据库 TokuDB，他们发现聚簇是检索范围数据的理想选择。TokuDB 的压缩比很高（在 MySQL 或 MariaDB 上为 5 比 1 或 7 比 1，在 MongoDB 上为 10 比 1），这有效地减少了读写开销，并降低了存储成本。而且据官方介绍，它所使用的分形树索引结构减少了写操作次数，延长了闪存的使用寿命。
Aerospike、FoundationDB、RethinkDB 和 Tokutek 都是用 MVCC 或类似的概念连续写入新版本数据，并在稍后清理老版本数据，而不是直接用新值替换已存数据。因此，数据库的一个写请求会变成多个操作，这称为写入放大，是闪存的一个缺点。但据Bulkowski 说，通过将索引存储在内存中，Aerospike 的写入放大仅为2，而在其它应用程序中，这个值通常为10。
此外，按照Rosenthal 的说法，闪存的速度和并发为数据库设计带来了最大的变化。他说，“在传统关系型数据的设计中，每个连接一个线程，这在磁盘是瓶颈的时代可以工作的很好，但现在，线程成了瓶颈。”因此，FoundationDB 内部使用它自己的轻量级进程。在闪存延迟无法再改善的情况下，并发显得更重要了。而Bulkowski 则表示，由于大量的并发，深队列在闪存上比在旋转型磁盘上工作的更好。
总之，这些新的数据库存储引擎设计已经抛弃了许多传统的设计方案。为了利用这些新的发展成果，应用程序开发人员应该重新审视他们的数据库模式和访问模式了。
感谢郭蕾对本文的审校。
给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ）或者腾讯微博（ @InfoQ ）关注我们，并与我们的编辑和其他读者朋友交流。
评论