什么时候在MongoDB上使用CouchDB，反之亦然
我困在这两个NoSQL数据库之间。
在我的项目中，我将在数据库中创build一个数据库。 例如，我需要一个解决scheme来创builddynamic表。
所以用户可以创build列和行的表格。 我认为MongoDB或CouchDB都会对此有所帮助，但是我不确定哪一个。 我也需要高效的分页。
的C，A＆P（一致性，可用性和分区容忍）哪2更重要吗？ 快速参考， NoSQL系统视觉指南
- MongodB：一致性和分区容忍
- CouchDB：可用性和分区容差
Cassandra与MongoDB，CouchDB与Redis，Riak与HBase与Membase与Neo4j的比较等博客文章都比较了每种NoSQL数据库的“ 最佳使用情况”。 引用链接，
- MongoDB：如果你需要dynamic查询。 如果你喜欢定义索引，而不是map / reduce函数。 如果你需要在一个大的数据库上performance出色。 如果你想要CouchDB，但你的数据变化太大，填满磁盘。
- CouchDB：用于累积，偶尔会更改数据，在其上运行预定义的查询。 版本控制的地方很重要。
最近（2012年2月）和Riyad Kalla更全面的比较 ，
- MongoDB：主从复制只
- CouchDB：主 – 主复制
一个博客文章（2011年10月）由一个同时尝试的人， 一个MongoDB Guy学习CouchDB评论CouchDB的分页不是很有用。
由Kristina Chodorow （ MongoDB背后团队的一部分 ）的date（2009年6月） 基准 ，
我会去MongoDB。
希望能帮助到你。
上面的答案使这个故事复杂化了。
- 如果您计划使用移动组件，或者需要桌面用户脱机工作，然后将其工作同步到服务器，则需要使用CouchDB。
- 如果你的代码只能在服务器上运行，那么就使用MongoDB
而已。 除非需要CouchDB的（真棒）能力才能复制到移动和桌面设备，否则MongoDB目前具有性能，社区和工具优势。
非常古老的问题，但它是谷歌顶部，我不太喜欢我看到的答案，所以这是我自己的。
Couchdb比开发CouchApps的function还要多。 大多数人在经典的三层Web架构中使用CouchDb。
实际上，对于大多数人来说，决定性的因素是MongoDb允许使用类似于SQL的特殊查询，而CouchDb则不这样做（您必须创buildmap / reduce视图，即使创build这些视图是快速的应用程序开发友好 – 他们没有任何关系存储过程）。
为了解决在接受的答案中提出的观点：CouchDb有一个很好的版本系统，但这并不意味着它只适合（或更适合）版本是重要的地方。 而且，couchdb由于其追加特性而非常重写（写入操作在保证没有数据丢失的情况下立即返回）。
一个没有被任何人提及的非常重要的事情是CouchDb依赖于b-tree索引。 这意味着无论你有1“行”还是200亿，查询时间总是会保持在10ms以下。 这是一个游戏转换器，它使CouchDb成为一个低延迟和易读的数据库，这真的不应该被忽视。
为了公平而详尽，MongoDb对CouchDb的优势在于工具和市场营销。 他们拥有适用于所有主要语言和平台的一stream公民工具，使得入职变得轻松，并且添加到他们即席查询中使得从SQL转换变得更容易。
CouchDb没有这个级别的工具 – 尽pipe现在有很多库可用 – 但是CouchDb作为一个HTTP API公开，所以用你最喜欢的语言创build一个包装器来与之交谈是很容易的。 我个人喜欢这种方法，因为它避免了膨胀，并允许你只采取你想要的（接口隔离原则）。
所以我会说使用其中一个很大程度上是一个舒适和偏好的问题与他们的范例。 对某些人来说，CouchDb方法“恰到好处”，但是如果在了解了数据库特性之后（在详尽的官方指南中 ），你没有你的“地狱耶”时刻，你应该继续前进。
如果您只是想使用“正确的工具”，那么我就不鼓励使用CouchDb。 因为你会发现你不能用这种方式使用它，你最终会生气，写博客文章，如“CouchDb在哪里连接？ 和“交易pipe理在哪里？”。 事实上，Couchdb是自相矛盾的 – 非常透明，但同时需要一个范式转变，并改变你处理问题的方式，以真正发挥（真正的工作）。
但是一旦你完成了这一切，这真是有好处。 我个人需要非常有力的理由，或者在一个项目中select另外一个数据库，但是到目前为止我还没有遇到任何问题。
我总结了那篇文章中的答案：
MongoDB：更好的查询，BSON数据存储（更快的访问），更好的数据一致性，多个集合
CouchDB：更好的复制，通过master来掌握复制和冲突解决，JSON数据存储（通过REST服务进行人类可读，更好的访问），通过map-reduce查询。
所以总而言之，MongoDB更快，CouchDB更安全。
另外： http : //nosql.mypopescu.com/post/298557551/couchdb-vs-mongodb
请注意MongoDB中稀疏唯一索引的问题。 我已经打了，这是非常麻烦的解决方法。
问题是这样的 – 你有一个领域，这是唯一的，如果存在，你希望find所有的领域不存在的对象。 在Mongo中实现稀疏唯一索引的方式是缺less该字段的对象根本不在索引中 – 它们不能通过对该字段的查询进行检索 – {$exists: false}不起作用。
我唯一的解决方法是有一个特殊的空值家族，其中一个空值被转换为一个特殊的前缀（如null ：）连接到一个uuid。 这是一个非常头疼的问题，因为在写作/查询/阅读时，必须注意从空值转换到空值。 一个重大的麻烦。
我从来没有在MongoDB中使用过服务器端JavaScript执行（反正也不build议这样做），而且当只有一个Mongo节点时，他们的map / reduce性能非常糟糕。 由于所有这些原因，我现在正在考虑检查CouchDB，也许它适合我的特殊情况。
顺便说一句，如果有人知道链接到各自的Mongo问题描述稀疏的唯一索引问题 – 请分享。
自己问这个问题？ 你会决定你的数据库select。
- 你需要高手吗？ 然后CouchDB。 主要是CouchDB支持主 – 主复制，预测节点长时间断开连接。 MongoDB在这样的环境下做得不好。
- 你需要最大的R / W吞吐量吗？ 然后是MongoDB
- 你是否需要最终的单服务器耐久性，因为你只有一个数据库服务器？ 然后CouchDB。
- 你是否正在存储需要分片的MASSIVE数据集，同时保持疯狂的吞吐量？ 然后是MongoDB。
- 你需要强大的数据一致性吗？ 然后是MongoDB。
- 你需要数据库的高可用性吗？ 然后CouchDB。
- 你希望多数据库和多表/集合？ 然后是MongoDB
- 你有一个移动应用程序脱机用户，并希望将他们的活动数据同步到服务器？ 那么你需要CouchDB。
- 你需要大量的查询引擎？ 然后是MongoDB
- 你需要大型社区使用数据库吗？ 然后是MongoDB
我相信你可以和Mongo一起（更熟悉它），而且很确定你也可以用沙发。
两者都是以文档为导向的（基于JSON），所以不会有“列”，而是文档中的字段 – 但它们可以是完全dynamic的。
他们都这样做，你可能想看看其他因素使用：你关心的其他function，stream行等。谷歌的见解，确实是工作岗位将是方式来看待stream行。
你可以试试看，我认为你应该可以在5分钟之内运行mongo。
