CouchDB与MySQL的选择

jopen 12年前
   <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>