couchdb_couchdb android_couchdb couchbase

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

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

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

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

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

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

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

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

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

可能出错的地方

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

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

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

我们真心喜欢CouchDB的一些事

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

本文来自电脑杂谈，转载请注明本文网址：
https://www.pc-fly.com/a/jisuanjixue/article-37082-1.html