CouchDB的缺点

Question

我最近爱上了CouchDB。我对它的巨大好处和它的美丽感到非常兴奋。现在我想确保我没有错过任何停止表演的缺点。

你脑子里在想什么？随函附上我收集到的要点清单。有什么要补充的吗？

• 早在2010年，博客就宣称“不够成熟”(不管这有什么价值)。
• 比内存数据库管理系统慢。
• 就地更新需要服务器端逻辑(更新处理程序).
• 交换磁盘与速度:与其他DBMS相比，数据库可能变得巨大(尽管存在压缩功能)。
• “只有”最终的一致性。
• 大型数据集上的临时视图非常缓慢。
• 大型数据库的复制可能失败。
• 地图/约简范式需要重新思考(仅为了完整性)。

唯一让我担心的是#3 (就地更新)，因为它非常不方便。

Answer 1

• 数据在JSON中

这意味着文档相当大(BigData、网络带宽、速度)，并且具有描述性的密钥名实际上会造成伤害，因为它们加在一起会导致文档的大小。

• No内置全文搜索 尽管有一些方法：库切德-卢塞尼，弹性搜索

加http://wiki.fluidproject.org/display/fluid/Schema-less+Databases

• 它不支持事务

这意味着在所有文档中强制执行一个字段的唯一性是不安全的，例如，强制执行用户名是唯一的。CouchDB无法支持事务的典型概念的另一个后果是，像inc/递减一个值并将其保存回来这样的事情也是危险的。没有多少实例我们想简单地减少一些值，这样我们就不能单独地存储各个文档并将它们聚合到一个视图中。

• 关系数据

如果数据在第三范式中很有意义，并且我们试图在CouchDB中遵循这种形式，我们会遇到很多麻烦。解决这个问题的一个可能的方法是使用视图排序，但是我们可能会不断地与系统进行斗争。如果可以对数据进行重新格式化，使其更加非规范化，那么CouchDB就可以正常工作了。

• 数据仓库

这方面的问题是大型数据集上的CouchDB临时视图非常慢。使用CouchDB和永久视图可以很好地工作。然而，在大多数情况下，面向列的数据库是一个更好的工具，为数据仓库工作。

但CouchDB Rocks!

但是不要让它与您不一致:用Erlang编写的NoSQL DB (CouchDB，Riak)是最好的，因为Erlang是用于分布式系统的。和库奇玩得开心！

Answer 2

还有两件事，这让我在使用CouchDB时哭了(虽然它很棒)：

• 它不是为频繁更新的数据而设计的。
• 它没有内置全文搜索。

Answer 3

• 缺乏读者ACL(但作者确实存在)

作为一个老looking，我把CouchDB作为一个新项目的替代方案，我发现在Couchvs.Domino中，阅读器的局限性非常弱。在我的应用程序中，安全性是一个重要的考虑因素，Couch需要一个中间件层来处理读者安全。

如果您的数据库中所有定义的用户都可以查看所有文档，那么Couch就像是一个有趣的平台。

如果需要限制读取，那么您将需要寻找中间件解决方案，或者考虑另一种选择。

CouchDB开发人员注意:改进平台安全选项。我意识到当使用时，它们会降低性能，但请注意，并提供选项。

现在回到决定使用哪个数据库..。