CouchDB与MySQL的选择

   <div id="news_body">     <p> 最近，一家提供云端运行 Selenium 测试的公司 <a href="/misc/goto?guid=4958188651027993813">Sauce Lab</a> 在其官方博客上发表了一篇博客<a href="/misc/goto?guid=4958341389027374223">《告别 CouchDB》</a>，根据自身云平台的案例，介绍了为何在当初选择 CouchDB，而又在现在转而选择 MySQL 的详细过程。在如今 NoSQL 大行其道的时候，Sauce Lab 为何又要告别 NoSQL，转而投入传统关系数据库的怀抱呢？</p>     <p> 在这篇博客中，作者 Steven Hazel 首先介绍了在项目开始之初，决定选择 CouchDB 的原因。一方面，他们广泛认同 NoSQL 在将来的前景，并对此充满了投身其中的技术热情；另一方面，则主要是从技术角度进行了选型决策。原因包括：</p>     <ol>      <li>Sauce Lab 的云端自动化测试平台通过 REST API 存储数据，而 CouchDB 本身提供了丰富的 REST API；</li>      <li>系统对数据库的 IO 需求很低，并且是水平伸缩（horizontally scalable）的；</li>      <li>系统对数据的准确性要求不高（Fault-tolerant）；</li>     </ol>     <p> 然而随着公司规模的增长，随着越来越多的客户开始使用这一自动化测试平台，最初做出选型决策的前提条件已经发生了显著变化。首先，随着时间的推移，为了满足日益增长的用户量，系统需要按照用户对数据进行分区；而产品也开始逐渐依赖于数据库的 IO 性能。系统提供的服务对数据可靠性的要求远高于一般 Web 应用系统的平均水平。例如，一个单独的请求失败，就会影响到客户提交的一个测试，进而引起整个构建的失败。此时，使用 CouchDB 面临的数据可靠性就成了系统的关键问题。作者提到，虽然公司考虑过对一些硬件和软件的调整，并力图改变使用 CouchDB 的方式，但效果并不明显，最后还是决定改弦易辙，决定改用关系型数据库 MySQL。</p>     <p> Steven Hazel 在博客中介绍了他们使用 CouchDB 时所面临的问题。例如在可用性方面，在最初使用 CouchDB 时，缓慢的磁盘性能使得数据库在执行查询时，常常发生周期性失败。即使改为使用更加快速的 RAID，在随着负载增加后，这一问题依旧如幽灵般重现。而选用 MySQL 的 Percona，由于运行的 mysqld 进程很少访问 CPU，而数据库提供的 cache 非常有效，以至于可以达到最少的磁盘读取访问。CouchDB 常常会发生视图丢失索引的情况，除非删除视图文件并重启数据库，否则很难做到重新索引。有时候，一些被破坏的视图会导致所有视图无法正常工作，除非将这些被破坏的视图彻底移除。对数据的压缩有时候会失败，并且只有将这些失败的压缩文件删除后才能正常工作。</p>     <p> 在性能方面，Steven 也认为 CouchDB 与 MySQL 相比并无明显优势。而维护性方面带来的问题，更是困扰着他们。因为 CouchDB 一旦失败，就要终止所有正在运行的查询，甚至包括数据复制与压缩，这就使得他们还要编写脚本去检查这些进程，保证在必要时重启进程。视图索引只能在查询时更新，却无法在插入记录时更新索引。这意味着需要编写脚本定期运行所有的视图，否则就会影响到查询的性能。</p>     <p> 在决定放弃 CouchDB 时，Sauce Lab 的工程师也曾经考虑过选择 MongoDB 或其他 NoSQL 产品。然而经过对技术方案的分析与探索后，最终认为 MongoDB 存在与 CouchDB 相似的问题；而有的 NoSQL 产品与 CouchDB 的差异，甚至大于它与 MySQL 的差异，这会给整个架构迁移带来困难。考虑到工程师们都具有丰富的 MySQL 经验，并且它完全能够满足系统需要，因此这样的选择也就显得顺理成章。</p>     <p> 在这篇博客中，作者并不讳言 MySQL 自身存在的问题，例如在数据库配置，查询引擎以及基于 SQL 的特性；也没有故意贬低 CouchDB，并在博客中列举了 CouchDB 的诸多好处，例如非关系型，无样式（No schemas)，以及它提供的 HTTP API，数据一致性，支持 Javascript 作为查询语言等特性。</p>     <p> 作者还简要介绍了整个迁移的过程。他们对架构进行重新设计，抽取了抽象的数据层，并采用了逐步迁移数据库的形式。通过将 CouchDB 模型层导入到 MySQL 中，以降低迁移对代码库的影响。即使迁移到 MySQL 中，他们也避免使用外键，join 以及多语句的事务。这是出于水平伸缩的考虑。他们还为每个数据表提供了一个 TEXT 列，用以存储 JSON。虽然这并不能很好地与 MySQL 的特性结合，但带来的好处在于系统能够更好地使用 JSON，从而体会到无样式数据库带来的乐趣。</p>     <p> 无论 NoSQL 与关系型数据库的争执如何，我们都必须看到这两种类型的数据库各有其适用的场景，甚至可以看到二者互相融合的趋势。这篇博客结合现实的案例表达了另一种观察视角，理智地根据自身项目的需求，做出了最符合项目需要的技术决策。这种不浮躁、不盲目、不人云亦云的架构决策思想，才是值得我们认真思考和借鉴的。</p>     <div id="come_from">     来自:      <a id="link_source2" href="/misc/goto?guid=4958341389833707648" target="_blank">InfoQ</a>     </div>    </div>