CouchDB 的缺点

Question

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

你想到了什么？ 附上我收集的点数清单。 有什么要补充的吗？

• 迟至 2010 年的博客文章声称“不够成熟”（无论这值多少钱）。
• 比内存 DBMS 慢。
• 就地更新需要服务器端逻辑（更新处理程序） 。
• 交换磁盘与速度：与其他 DBMS 相比，数据库可能变得巨大（尽管存在压缩功能）。
• “仅”最终一致性。
• 大型数据集的临时视图非常慢。
• 大型数据库的复制可能会失败。
• Map/Reduce 范式需要重新思考（仅出于完整性考虑）。

唯一让我担心的是#3（就地更新），因为它很不方便。

Answer 1

• 数据为 JSON

这意味着文档非常大（大数据、网络带宽、速度），并且具有描述性的键名实际上是有害的，因为它们加起来等于文档大小。

• 没有内置的全文搜索

  虽然有办法： couchdb-lucene ， elasticsearch

再加上一些：

• 它不支持交易

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

• 关系数据

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

• 数据仓库

问题在于 CouchDB 中大型数据集的临时视图非常慢。 使用 CouchDB 和永久视图可以很好地工作。 然而，在大多数情况下，某种类型的面向列的数据库对于数据仓库工作来说是一个更好的工具。

但是 CouchDB 太棒了！

但是不要让它让您失望：用 Erlang（CouchDB、Riak）编写的 NoSQL DB 是最好的，因为 Erlang 是为分布式系统设计的。 有沙发的乐趣！

Answer 2

还有两件事让我在使用 CouchDB 时哭了（虽然它很棒）：

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

Answer 3

• 缺少读者 ACL（但是对于作者来说确实存在）

作为一名老 Lotus Domino 专家，我希望将 CouchDB 作为我正在启动的新项目的替代方案，但发现 Couch 与 Domino 对读者的限制非常弱。 在我的应用程序中，安全性是一个重要的考虑因素，Couch 需要一个中间件层来处理阅读器的安全性。

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

如果需要限制读取，那么您需要寻找中间件解决方案或考虑其他替代方案。

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

现在回到确定要使用的数据库......

Answer 4

• 目前不支持即席查询（可能会随着 UnQL 的出现而改变）
• 缺乏二进制协议支持以加快通信速度

Answer 5

1. 缺乏对数据归档的支持——没有官方对数据的支持
   归档是随 couch db 开源分发提供的。
2. 从 db 中删除记录并不简单
3. 没有为文档设置过期 (TTL) 标志的选项

Answer 6

这与 CouchDB 本身无关，但是作为一个相对较新的人，大多数系统管理员仍然不熟悉它，并且不会允许它靠近“他们的”数据中心。 如果您处于部署到无法控制自己的环境的情况，这可能是一场战斗。