我想知道是否有人可以告诉我MongoDB或CouchDB是否已经为生产环境做好了准备。
我现在正在研究这些存储解决方案(目前我更喜欢MongoDB)，但是这些项目还很年轻，所以我预见到我将不得不非常努力地说服我的经理，我们应该采用这种新技术。
我想知道的是:
现在谁在生产环境中使用MongoDB或CouchDB ? 你如何使用MongoDB/CouchDB? 当你采用这种新的存储机制时，你遇到了什么问题(如果有的话)(你是如何克服它们的)? 你是如何处理你不得不面对的移民问题的? 你有任何好的或坏的经验，这些解决方案，你想分享吗?
当前回答
CouchDB 0.11(发布于3月底)是1.0版本的特性冻结版。这意味着我们将保持与当前1.0版API的兼容性，所以现在是重新研究CouchDB的好时机(如果您很久没有研究过)。
CouchDB 0.11源代码发布在这里。这里链接了二进制安装程序和其他好东西。
其他回答
我们将CouchDB作为MySQL的替代品运行在我们的商店(70.0000个商品/商店，所有商品的属性总数为400万个，商品之间的交叉连接)。
我们的目标是:
从master-db轻松复制到具有不同文档的多个客户端。 快速预计算数据，比如“这个属性和那个过滤器有多少部分符合这些条件”
事实:
我们的商店现在运行得比使用MySQL快得多(MySQL数据库需要额外的1-3天的预计算(因此每月更新两次)，使数据为产品计数和过滤做好准备，CouchDB需要5个小时，所以我们可以每晚更新产品数据) 设置(过滤)数据分布和备份到商店节点是快速和容易的
但也:
Understanding map/reduce and the limits of not having joins is quite hard No operation on data like "delete where" or "update where" without external programs Replication works well, unless there is a problem; then it's really hard to find out what was the reason (for beginners) The installation of CouchDB without binaries (yes there are a some in the wild, but not for every OS/version) could be hard, if you are not a Linux geek. But the CouchDB Community is helpful (#couchdb), and luckily there are companies out there (cloudant, iriscouch) that offer services from free to big business. CouchDB is moving forward, so there are a lot of changes (improvements) going on that might change they way you work. But basic things remain stable.
结果是: MySQL作为数据创建和维护的数据库是可靠的，易于理解和处理。我认为我们不会改变这一点。 但我也不想错过CouchDB视图的强大功能和复制设置的便利性。
在工作了几个月之后，生产沙发有时会因为错误配置和忘记日志(视图构建花费太长时间或挂起，复制停止)而造成麻烦，但从未丢失数据，并且总是可以轻松重置。
我在生产中使用CouchDB。目前它存储了所有不在原始DB模式中的“可选”字段。现在我正在考虑将所有数据转移到CouchDB。
我承认这一步很冒险。首先，因为它还不是1.0版本。其次，因为它需要大量的驾驶空间。根据我的计算，CouchDB文件(带索引)比具有相同行的MySQL数据库大30倍。 但我很确定它会好起来的。
就生产而言，无缝故障转移/恢复都需要一个保姆 1- Couchbase，没有无缝的故障转移/恢复，需要人工干预。重新平衡需要太多时间，如果丢失多个节点，风险也会很大。
2- Mongo与shards，数据恢复从松散的配置服务器，不是一个容易的任务
BBC和meebo.com在生产中使用CouchDB，我的一个客户也是如此。 下面是在野外使用Couch: CouchDB的其他用户的列表
主要的挑战是知道如何组织文档，并停止从关系数据的角度思考问题。
我们在生产中使用MongoDB的移动后端服务，即Netmera。我们使用它来存储所有用户和内容数据。
