最近，一家提供云端运行Selenium测试的公司Sauce Lab在其官方博客上发表了一篇博客《告别CouchDB》，根据自身云平台的案例，介绍了为何在当初选择CouchDB，而又在现在转而选择MySQL的详细过程。在如今NoSQL大行其道的时候，Sauce Lab为何又要告别NoSQL，转而投入传统关系数据库的怀抱呢？ 在这篇博客中，作者Steven Hazel首先介绍了在项目开始之初，决定选择CouchDB的原因。一方面，他们广泛认同NoSQL在将来的前景，并对此充满了投身其中的技术热情；另一方面，则主要是从技术角度进行了选型决策。原因包括：
然而随着公司规模的增长，随着越来越多的客户开始使用这一自动化测试平台，最初做出选型决策的前提条件已经发生了显著变化。首先，随着时间的推移， 为了满足日益增长的用户量，系统需要按照用户对数据进行分区；而产品也开始逐渐依赖于数据库的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与关系型数据库的争执如何，我们都必须看到这两种类型的数据库各有其适用的场景，甚至可以看到二者互相融合的趋势。这篇博客结合现实 的案例表达了另一种观察视角，理智地根据自身项目的需求，做出了最符合项目需要的技术决策。这种不浮躁、不盲目、不人云亦云的架构决策思想，才是值得我们 认真思考和借鉴的。 转载请保留固定链接： https://linuxeye.com/database/501.html |