你的想法是什么？附上的是我收集的积分列表.有什么要补充的吗？
>博客帖子从2010年以前的索赔“不够成熟”(无论什么值得).
>比内存DBMS慢.
>就地更新需要服务器端逻辑(update handlers).
>交易磁盘与速度：与其他DBMS相比,数据库可能变得巨大(虽然压缩功能存在).
>“只”最终一致.
>大型数据集的临时观点非常慢.
>复制大数据库may fail.
>地图/减少范式需要重新思考(仅为了完整性).
令人担忧的唯一的一个问题就是#3(就地更新),因为它很不方便.
这意味着文档相当大(BigData,网络带宽,速度),并且描述性密钥名称实际上受到伤害,因为它们加起来为文档大小.
>没有内置全文搜索
虽然有办法：couchdb-lucene,elasticsearch
>它不支持交易
这意味着在所有文档中强制执行一个字段的唯一性是不安全的,例如强制用户名是唯一的. CouchDB无法支持交易的典型概念的另一个后果是像增加/减少值并将其保存回来也是危险的.没有多少例子,我们只想简单地放弃/减少一些值,我们不能单独存储单个文档,并用视图聚合它们.
>关系数据
如果数据在第三种正常形式中有很大的意义,而我们试图在CouchDB中遵循这种形式,我们将遇到很多麻烦.解决这个问题的一个可能方法是查看整理,但我们可能会不断地与系统进行战斗.如果数据可以重新格式化得更加非正规化,那么CouchDB就可以正常工作了.
>数据仓库
这样做的问题是CouchDB在大型数据集上的临时视图真的很慢.使用CouchDB和永久性的视图可以运行得很好.然而,在大多数情况下,某种类型的面向列的数据库是数据仓库作业更好的工具.
但是CouchDB Rocks！
但不要让它炫耀你：Erlang(CouchDB,Riak)写的Nosql DB是最好的,因为Erlang是分布式系统的.用沙发玩乐！