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

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

我想知道的是:

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


当前回答

我在生产中使用CouchDB已经快2年了。没有迁移工作,因为项目直接从CouchDB实现开始。它作为一个数据库,存储单个电子产品从开始到包装的数据。

由于我们销售的传感器对精度有很高的要求,我们在不同的阶段做了大量的测试,所有这些都将存储在CouchDB上的一个文档中。

我从我的经验中学到了一些学习曲线,那就是充分利用视图(也称为永久视图)。视图应该是数据库中经常被调用的部分的“小过滤器”。

我的CouchDB数据库不像其他大公司那样疯狂。但到目前为止,我做得还不错。目前我有24000个700MB的文档。

我喜欢CouchDB的特性是“复制”,“存储文档的修订”。

我读了很多关于MongoDB的好评,如果有机会,我想尝试一下。

其他回答

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

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

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

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

CouchDB 0.11(发布于3月底)是1.0版本的特性冻结版。这意味着我们将保持与当前1.0版API的兼容性,所以现在是重新研究CouchDB的好时机(如果您很久没有研究过)。

CouchDB 0.11源代码发布在这里。这里链接了二进制安装程序和其他好东西。

我们使用CouchDB存储移动入站和出站消息,并通过我编写的一些自定义视图报告此流量。前端是用Python编写的。我们没有任何真正的技术问题,它自12月底以来一直在运行。我遇到的唯一障碍是最初从MapReduce的角度思考,但一旦我学会了如何做到这一点,其他一切都很顺利。

我在生产中使用CouchDB。目前它存储了所有不在原始DB模式中的“可选”字段。现在我正在考虑将所有数据转移到CouchDB。

我承认这一步很冒险。首先,因为它还不是1.0版本。其次,因为它需要大量的驾驶空间。根据我的计算,CouchDB文件(带索引)比具有相同行的MySQL数据库大30倍。 但我很确定它会好起来的。

就生产而言,无缝故障转移/恢复都需要一个保姆 1- Couchbase,没有无缝的故障转移/恢复,需要人工干预。重新平衡需要太多时间,如果丢失多个节点,风险也会很大。

2- Mongo与shards,数据恢复从松散的配置服务器,不是一个容易的任务