couchdb_couchdb android_couchdb couchbase(2)

非关系型。 关系型发展出解决问题的原则是：数据的完整性是至关重要的，而可用性则无关紧要。在很多在现代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使用效率足够高以至于几乎没有磁盘读写，在RAID10下我们的写负载是一个非常舒适的小百分比。

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

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

压缩(Compaction)有时会没有任何提示的终止，有时还不得不被删除残留的文件使其重新运行。这在我们提高了磁盘容量报警上线之前导致了一些可怕的情况，因为我们发现这一点时，由于做压缩，磁盘仅剩下非常小的空间。

在早期版本中，我们遇到了有关文件句柄使用的三、四个错误。 Bug reports快速修复了他们，并在1.0.2版本中更新了有关代码。

性能：

真的还有一件事要在这里说，那个CouchDB的视图查询的性能问题，并没有达到我们曾经期望的与MySQL索引查询大致相等的性能级别。这不是一个巨大的惊喜或者一个巨大的问题，但是哇塞(but wow)，现在很多事情更快了，我们的机器是负担减少了许多。

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