弃用NoSQL数据库 CouchDB再见了

　　【导读】

　　2012年5月10日，Sauce Labs公司的首席架构师Steven Hazel，写了一篇关于弃用NoSQL数据库CouchDB产品，介绍他们将Couch数据库的数据迁移到MySQL数据库平台中。

　　在Sauce Lab(酱油实验室)里，我们刚刚庆祝完成一个重大项目—将最后的CouchDB数据库转变为MySQL数据库，以提高服务正常运行时间和可靠性。 由于大部分无故停机的是由于CouchDB数据库宕机引起的，因此完成这种迁移是我们一个重要的里程碑。

　　CouchDB数据库开始时，是一个非常宝贵的经验，在1.2版本时它的可靠性还是可以的。 但我们的服务对可靠性要求非常高，于是最终决定：这种转变是前进中最有效的方式。

　　一旦决使用MySQL(具体而言，是Percona的基于InnoDB存储引擎的XtraDB存储引擎，)，我们就重构了数据库抽象层，并迁移了所有各种类型的数据库。 在过去几个月，迁移完成后，我们的服务正常运行时间大大提高了。

　　这篇文章介绍了我们使用CouchDB数据库的经验，以及在哪里遇到了麻烦。我也谈了这方面的经验，如何影响了我们对NoSQL数据库的整体观点，以及在熟悉了NoSQL数据库后，如何积极权衡对MySQL数据库的安装配置。

　　首先，我们是如何陷入困境?

　　所有的事情都在变的伟大。

　　自2008年开始我们第一次启动Sauce Lab，我们认为我们正在建立与当今运行的服务非常不同的东西。我们高兴地尝试NoSQL数据库，使用MySQL关系数据库的设计者多年来从来没有想过的方式。CouchDB的似乎很适合我们的需要。

　　我们原来的产品为客户的利益着想而设计了一个有特色的用于存储数据的REST API，该计划彻底废弃了曾有的CouchDB的RESTful API。 这让我们得到了一个原型并匆忙的运行。 CouchDB是新鲜事物且尚未有过什么实际使用，但这并不重要，因为我们数据库I / O需求很少，应用程序自然具有水平扩展性，且产品是容错的。只要保持复制正常且在出错时重试就可以很容易地弥补稳定性的鸿沟。这样难道会出问题吗?

　　可能出错的地方

　　随着这家小公司的成长，我们逐渐了解到客户所面临的问题，我们的产品也经历了几个重大变化.随着时间的推移严格按照用户对数据进行分区意义不大。我们变得越来越依靠数据库的I/O性能。通常，我们觉得自己使用CouchDB与最初设想非常不同，更与大多数web应用程序使用数据库的方式不同。虽然这仍是一种合理的使用方式，但我们曾经相信的附加安全性正随着产品的升级而慢慢消失，而那恰恰是我们所需要的。

　　Sauce Lab比一般web应用程序对可靠性要求更高。 如果我们对一个单一请求处理失败，就代表了对一个客户检验的失败，并影响他们的整个架构。 随着时间的推移，CouchDB数据库的可靠性越来越糟糕。 我们不停的更换硬件设备，改变使用CouchDB数据库的方式。 我们改变了软件架构，使其对数据库和数据库I / O操作减少。不过， 最后我们决定，最好的方法还是更换数据库产品。

　　到此为止我都没有讲CouchDB的具体缺点， 这是一个年轻的数据库，可靠性和性能问题是可以预期的。 因为我们对传统的关系型数据库没有偏爱，但在某种程度上，CouchDB数据库还是太糟糕了。 我们深信，NoSQL数据库是未来。 只是我们不相信NoSQL数据库是现在。

　　我们真心喜欢CouchDB数据库的一些事

　　无模式。 这是美妙的 。，模式甚至有何用? 他们只是毫无理由的把事情变复杂。 有时你需要对数据增加约束，数据库模式改变非常难。 然后CouchDB数据库对文档，增加新的字段非常简单。

　　非关系型。 关系型数据库发展出解决问题的原则是：数据的完整性是至关重要的，而可用性则无关紧要。 在很多在现代Web应用程序数据库层中毫无意义的功能。有6种连接方式的事务查询起初是很吸引人的，但是当你需要扩展(scale)时就会令你陷入困境。从一开始阻止这些发生通常是很容易的。

　　No SQL。 这是2012年，大多数查询从代码运行，而不是由坐在控制台的人类。为什么我们仍在用非常接近奇怪的COBOL语言构建的代码查询我们的数据库呢?且这些被组建的代码不得不在每一次查询时重新解析。像SQL注入攻击这样的东西根本不应该存在。 他们是将你的数据库API看作编程语言而不是一个协议的后果，它是这个自20世纪70年代起经深思熟虑设计的漏洞的核心;

　　HTTP API。 无论在任何地方，只要符合HTTP(或者run curl)协议，就可以方便的查询数据库;

　　始终一致性，只追加文件格式。 这样做数据库备份仅作文件复制，简单且无后顾之忧;

　　JavaScript是作为一个视图/查询语言，被人熟知且广泛使用;

　　任意计算出的值上的索引似乎是一个有巨大潜能的功能。 我们从来没有找到一个真正智慧的方式使用它们，虽然它只是简单的通过电子邮件的域名做用户索引。

　　最后值得指出，即使在挑战其查询和维护索引能力的压力之下，CouchDB数据库从未丢失任何数据。

　　使用CouchDB时我们遇到的问题

　　可用性：

　　在我们最初的设置中，磁盘缓慢的性能使CouchDB正在运行的查询周期性的失败。 后来用更快的RAID配置后性能会有所改善，但随着负荷的增加，问题回来了。 相比而言，Percona在这一负荷水平完全胜任：mysqld使用CPU资源非常少，几乎没有任何慢查询，cache使用效率足够高以至于几乎没有磁盘读写，在RAID 10下我们的写负载是一个非常舒适的小百分比。

　　视图有时会丢失索引，而且在正常工作前还有几次重加索引失败的情况。 偶尔他们会进入一种无休止重加索引的状态，直到我们彻底删除视图文件并重新启动CouchDB。 而对此我们非常痛苦。 最后一件事重新编制索引的惊喜是，我们作为一个小团队已经采取一个巨大的任务列表和战斗力，以打动潜在的大客户的需要。Surprise reindexing exercises were the last thing we needed as a small team already taking on a giant task list and fighting to impress potential big customers.

　　损坏的视图(Views)有时会阻止所有工作的视图，直到这个视图文件已被删除，在这个时候，视图索引消耗时间做重启和一些不可靠的工作。 不知道多少次我们中的一员在凌晨4点被监控系统唤醒，因为数据库未经许可因突然变成一个简单的键/值存储而当掉。

原文转自：http://blogread.cn/it/article/5356