我想知道是否有人可以告诉我MongoDB或CouchDB是否已经为生产环境做好了准备。
我现在正在研究这些存储解决方案(目前我更喜欢MongoDB),但是这些项目还很年轻,所以我预见到我将不得不非常努力地说服我的经理,我们应该采用这种新技术。
我想知道的是:
现在谁在生产环境中使用MongoDB或CouchDB ?
你如何使用MongoDB/CouchDB?
当你采用这种新的存储机制时,你遇到了什么问题(如果有的话)(你是如何克服它们的)?
你是如何处理你不得不面对的移民问题的?
你有任何好的或坏的经验,这些解决方案,你想分享吗?
我们将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视图的强大功能和复制设置的便利性。
在工作了几个月之后,生产沙发有时会因为错误配置和忘记日志(视图构建花费太长时间或挂起,复制停止)而造成麻烦,但从未丢失数据,并且总是可以轻松重置。
我是10gen (MongoDB的开发者)的CTO,所以我有点偏见,但我也管理一些在生产中使用MongoDB的网站。
Businessinsider已经在生产中使用mongo一年多了。从用户和博客文章,到网站上的每张图片,他们都在使用它。
Shopwiki正在使用它做一些事情,包括实时分析和缓存层。它们每秒对一个相当大的数据库进行超过1000次的写入。
如果你进入mongodb生产部署页面,你会看到一些人在生产中使用mongodb。
如果您对生产部署的规模或范围有任何疑问,请在我们的用户列表中发帖,我们将非常乐意提供帮助。
我在生产中使用CouchDB已经快2年了。没有迁移工作,因为项目直接从CouchDB实现开始。它作为一个数据库,存储单个电子产品从开始到包装的数据。
由于我们销售的传感器对精度有很高的要求,我们在不同的阶段做了大量的测试,所有这些都将存储在CouchDB上的一个文档中。
我从我的经验中学到了一些学习曲线,那就是充分利用视图(也称为永久视图)。视图应该是数据库中经常被调用的部分的“小过滤器”。
我的CouchDB数据库不像其他大公司那样疯狂。但到目前为止,我做得还不错。目前我有24000个700MB的文档。
我喜欢CouchDB的特性是“复制”,“存储文档的修订”。
我读了很多关于MongoDB的好评,如果有机会,我想尝试一下。