我想知道是否有人可以告诉我MongoDB或CouchDB是否已经为生产环境做好了准备。

我现在正在研究这些存储解决方案(目前我更喜欢MongoDB),但是这些项目还很年轻,所以我预见到我将不得不非常努力地说服我的经理,我们应该采用这种新技术。

我想知道的是:

现在谁在生产环境中使用MongoDB或CouchDB ? 你如何使用MongoDB/CouchDB? 当你采用这种新的存储机制时,你遇到了什么问题(如果有的话)(你是如何克服它们的)? 你是如何处理你不得不面对的移民问题的? 你有任何好的或坏的经验,这些解决方案,你想分享吗?


当前回答

我们在生产中使用mongodb

www.beachfront.io -接近每秒5k的写请求 www.beachfrontbuilder.com -每秒500个读写请求,维护1000万用户数据和olap。

我们通过实现自定义组件克服了数据归档面临的唯一挑战。

其他回答

我对MongoDB一无所知,但从CouchDB常见问题解答:

CouchDB准备好投入生产了吗? 是的,请参阅InTheWild以获得使用CouchDB的部分项目列表。另一个很好的概述是CouchDB案例研究

还有一些链接:

回复:当前CouchDB状态? SimpleDB, CouchDB和其他“新”数据存储-反馈

我们在生产环境中使用couchdb,就在项目被纳入Apache保护伞之前。

我们用它来存储所有可能使用dbms的数据,以及各种非结构化数据。就我个人而言,我非常喜欢这样一种方式:您可以将各种数据放入其中,并使用视图根据情况剔除不需要的数据。

最难的部分是摆脱dbms的思维模式。为了安全起见,当存储格式改变时,我们编写了自己的迁移utils,所以这并不是真正的问题。

我们还没有任何负面的经历,但我们也没有在任何巨大的负载下进行设置。我认为事情会运行得很好,因为我们有两个从服务器,从一个主服务器复制所有的写操作。我很确定我们不需要这样做才能正确地进行复制,但这就是我们一开始设置的方式,它一直存在。

我们将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倍。 但我很确定它会好起来的。

SourceForge使用MongoDB。看这个演示或者阅读这里。