写点什么

CouchDB 与 MySQL 的选择

  • 2012-05-24
  • 本文字数:1887 字

    阅读完需:约 6 分钟

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

2012-05-24 21:386204
用户头像

发布了 109 篇内容, 共 44.0 次阅读, 收获喜欢 14 次。

关注

评论

发布
暂无评论
发现更多内容

在Spring Bean实例过程中,如何使用反射和递归处理的Bean属性填充?

小傅哥

Java spring 小傅哥 反射调用 属性填充

中断Hwi:提高鸿蒙轻内核系统实时性及执行效率的秘密武器

华为云开发者联盟

鸿蒙 硬件 中断 鸿蒙轻内核 中断信号

五大新品+两大黑科技,看华为云如何升级基础设施让用户“躺平”

华为云开发者联盟

云原生 基础设施 实景三维建模 计算实例C7 分布式云

react源码解析4.源码目录结构和调试

全栈潇晨

React Hooks react源码

React Hooks - 如何安全地使用state

蛋先生DX

大前端 React React Hooks JavaScrip 6月日更

直击Huawei Mate 40产线背后的华为云IoT智能制造

华为云开发者联盟

IoT 数字化转型 数字孪生 华为云IoT

C 语言面向对象的封装方式(示例)

实力程序员

动态规划(详解矩阵连乘 案例+Java代码实现)

若尘

算法 动态规划 矩阵运算 java代码 6月日更

“盒模型“初探

编程三昧

CSS css3 大前端 盒模型

玩转容器存储QoS

焱融科技

云计算 容器 云原生 QoS 超融合

微博评论的高性能高可用计算架构设计

唐高为

面试系列-3 限流场景实践

李阿柯

php lua redis 面试 限流算法

GrowingIO 前端团队对于 GraphQL 的实践总结

GrowingIO技术专栏

大前端 graphql

致恰达耶夫,致鸿蒙

脑极体

Hello Python! 第一天学 Pyhton 语言

在即

6月日更

Redis数据结构

邱学喆

数据库 redis 跳跃表

SMT产线可视化管理,智能工业助力全渠道优化

一只数据鲸鱼

数据可视化 智慧工厂 SMT 智慧工业

《面试官:谈谈你对索引的认知》系列之磁盘I/O

架构精进之路

MySQL 索引结构 6月日更

详解Camtasia的注释功能

淋雨

视频剪辑 Camtasia 录屏

关于第四次财富狂潮的思考,区块链如猛虎出笼?

CECBC

【Flutter 专题】114 图解自定义 ACEProgressPainter 对比进度图

阿策小和尚

Flutter 小菜 0 基础学习 Flutter Android 小菜鸟 6月日更

一文了解预训练语言模型!

博文视点Broadview

BZZ算力挖矿系统开发功能丨BZZ算力挖矿源码设计

系统开发咨询1357O98O718

GrowingIO Design 组件库搭建之组件开发

GrowingIO技术专栏

组件

架构实战营 模块五作业

netspecial

架构实战营

有点难的 webpack 知识点:Dependency Graph 深度解析

范文杰

webpack 6月日更

vim 操作模式简介

编程三昧

vim 工具

深圳首辆数字人民币主题观光巴士亮相

CECBC

实现多级缓存架构设计方案

xcbeyond

缓存 缓存架构 6月日更

鸿蒙能成为世界第三的操作系统吗?

小智

华为 鸿蒙 操作系统

IPFS云算力挖矿系统开发(详情)丨IPFS云算力(源码)案例

系统开发咨询1357O98O718

CouchDB与MySQL的选择_数据库_张逸_InfoQ精选文章