CouchDB与MySQL的选择

CouchDB与MySQL的选择

作者 张逸 发布于 2012年5月24日

领域
企业架构,
架构 & 设计,
语言 & 开发
主题
CouchDB ,
Couchbase ,
MySQL ,
NoSQL ,
关系型数据库 ,
数据库 ,
架构

最近,一家提供云端运行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)关注我们,并与我们的编辑和其他读者朋友交流。

张逸 是一个怀揣梦想的架构师,沉迷于设计之美,著译作包括《软件设计精要与模式》、《WCF服务编程》等。


评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值