CouchDB 与 MySQL 的选择

最近，一家提供云端运行 Selenium 测试的公司 Sauce Lab 在其官方博客上发表了一篇博客《告别 CouchDB》，根据自身云平台的案例，介绍了为何在当初选择 CouchDB，而又在现在转而选择 MySQL 的详细过程。在如今 NoSQL 大行其道的时候，Sauce Lab 为何又要告别 NoSQL，转而投入传统关系数据库的怀抱呢？

在这篇博客中，作者 Steven Hazel 首先介绍了在项目开始之初，决定选择 CouchDB 的原因。一方面，他们广泛认同 NoSQL 在将来的前景，并对此充满了投身其中的技术热情；另一方面，则主要是从技术角度进行了选型决策。原因包括：

1. Sauce Lab 的云端自动化测试平台通过 REST API 存储数据，而 CouchDB 本身提供了丰富的 REST API；
2. 系统对数据库的 IO 需求很低，并且是水平伸缩（horizontally scalable）的；
3. 系统对数据的准确性要求不高（Fault-tolerant）；

然而随着公司规模的增长，随着越来越多的客户开始使用这一自动化测试平台，最初做出选型决策的前提条件已经发生了显著变化。首先，随着时间的推移，为了满足日益增长的用户量，系统需要按照用户对数据进行分区；而产品也开始逐渐依赖于数据库的 IO 性能。系统提供的服务对数据可靠性的要求远高于一般 Web 应用系统的平均水平。例如，一个单独的请求失败，就会影响到客户提交的一个测试，进而引起整个构建的失败。此时，使用 CouchDB 面临的数据可靠性就成了系统的关键问题。作者提到，虽然公司考虑过对一些硬件和软件的调整，并力图改变使用 CouchDB 的方式，但效果并不明显，最后还是决定改弦易辙，决定改用关系型数据库 MySQL。

Steven Hazel 在博客中介绍了他们使用 CouchDB 时所面临的问题。例如在可用性方面，在最初使用 CouchDB 时，缓慢的磁盘性能使得数据库在执行查询时，常常发生周期性失败。即使改为使用更加快速的 RAID，在随着负载增加后，这一问题依旧如幽灵般重现。而选用 MySQL 的 Percona，由于运行的 mysqld 进程很少访问 CPU，而数据库提供的 cache 非常有效，以至于可以达到最少的磁盘读取访问。CouchDB 常常会发生视图丢失索引的情况，除非删除视图文件并重启数据库，否则很难做到重新索引。有时候，一些被破坏的视图会导致所有视图无法正常工作，除非将这些被破坏的视图彻底移除。对数据的压缩有时候会失败，并且只有将这些失败的压缩文件删除后才能正常工作。

在性能方面，Steven 也认为 CouchDB 与 MySQL 相比并无明显优势。而维护性方面带来的问题，更是困扰着他们。因为 CouchDB 一旦失败，就要终止所有正在运行的查询，甚至包括数据复制与压缩，这就使得他们还要编写脚本去检查这些进程，保证在必要时重启进程。视图索引只能在查询时更新，却无法在插入记录时更新索引。这意味着需要编写脚本定期运行所有的视图，否则就会影响到查询的性能。

在决定放弃 CouchDB 时，Sauce Lab 的工程师也曾经考虑过选择 MongoDB 或其他 NoSQL 产品。然而经过对技术方案的分析与探索后，最终认为 MongoDB 存在与 CouchDB 相似的问题；而有的 NoSQL 产品与 CouchDB 的差异，甚至大于它与 MySQL 的差异，这会给整个架构迁移带来困难。考虑到工程师们都具有丰富的 MySQL 经验，并且它完全能够满足系统需要，因此这样的选择也就显得顺理成章。

在这篇博客中，作者并不讳言 MySQL 自身存在的问题，例如在数据库配置，查询引擎以及基于 SQL 的特性；也没有故意贬低 CouchDB，并在博客中列举了 CouchDB 的诸多好处，例如非关系型，无样式（No schemas)，以及它提供的 HTTP API，数据一致性，支持 Javascript 作为查询语言等特性。

作者还简要介绍了整个迁移的过程。他们对架构进行重新设计，抽取了抽象的数据层，并采用了逐步迁移数据库的形式。通过将 CouchDB 模型层导入到 MySQL 中，以降低迁移对代码库的影响。即使迁移到 MySQL 中，他们也避免使用外键，join 以及多语句的事务。这是出于水平伸缩的考虑。他们还为每个数据表提供了一个 TEXT 列，用以存储 JSON。虽然这并不能很好地与 MySQL 的特性结合，但带来的好处在于系统能够更好地使用 JSON，从而体会到无样式数据库带来的乐趣。

无论 NoSQL 与关系型数据库的争执如何，我们都必须看到这两种类型的数据库各有其适用的场景，甚至可以看到二者互相融合的趋势。这篇博客结合现实的案例表达了另一种观察视角，理智地根据自身项目的需求，做出了最符合项目需要的技术决策。这种不浮躁、不盲目、不人云亦云的架构决策思想，才是值得我们认真思考和借鉴的。

感谢崔康对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ）或者腾讯微博（ @InfoQ ）关注我们，并与我们的编辑和其他读者朋友交流。