database MongoDB 或 CouchDB - 适合生产吗？

MongoDB or CouchDB - fit for production?

提问by Alan

I was wondering if anyone can tell me if MongoDBor CouchDBare ready for a productionenvironment.

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

I'm now looking at these storage solutions (I'm favouring MongoDB at the moment), however these projects are quite young and so I foresee that I'm going to have to work quite hard to convince my manager that we should adopt this new technology.

我现在正在研究这些存储解决方案（我目前偏爱 MongoDB），但是这些项目还很年轻，所以我预见我将不得不非常努力地说服我的经理我们应该采用这个新技术。

What I'd like to know is:

我想知道的是：

1. Who is using MongoDB or CouchDB today in a production environment?

2. How are you using MongoDB/CouchDB?

3. What problems (if any) did you come across when you adopted this new storage mechanism (and how did you overcome them)?

4. How did you deal with any migration issues that you had to deal with?

5. Do you have any good/bad experiences with either of these solutions that you'd like to share?

1. 现在谁在生产环境中使用 MongoDB 或 CouchDB？

2. 你如何使用 MongoDB/CouchDB？

3. 当您采用这种新的存储机制时，您遇到了哪些问题（如果有的话）（以及您是如何克服这些问题的）？

4. 您是如何处理必须处理的任何迁移问题的？

5. 您对这些解决方案中的任何一个有什么好的/坏的经验要分享吗？

采纳答案by Alan

I'm the CTO of 10gen (developers of MongoDB) so I'm a bit biased, but I also manage a few sites that are using MongoDB in production.

我是 10gen（MongoDB 的开发人员）的 CTO，所以我有点偏见，但我也管理一些在生产中使用 MongoDB 的站点。

businessinsiderhas been using mongo in production for over a year now. They are using it for everything from users and blog posts, to every image on the site.

businessinsider已经在生产中使用 mongo 一年多了。他们将它用于从用户和博客文章到网站上的每个图像的所有内容。

shopwikiis using it for a few things including real time analytics and a caching layer. They are doing over 1000 writes per second to a fairly large database.

shopwiki将它用于一些事情，包括实时分析和缓存层。他们每秒对一个相当大的数据库执行超过 1000 次写入。

If you go to the mongodb Production Deployments pageyou'll see some people who are using mongo in production.

如果您转到mongodb 生产部署页面，您会看到一些在生产中使用 mongo 的人。

If you have any questions about the scale or scope of production deployments, post on our user list and we'll be more than happy to help.

如果您对生产部署的规模或范围有任何疑问，请在我们的用户列表上发帖，我们将非常乐意为您提供帮助。

回答by Matt Aimonetti

The BBCand meebo.comuse CouchDB in production and so does one of my clients. Here is a list of other people using Couch: CouchDB in the wild

在BBC和meebo.com使用CouchDB的生产也是如此我的一个客户。这是使用 Couch 的其他人的列表：CouchDB in the wild

The major challenge is to know how to organize your documents and stop thinking in terms of relational data.

主要的挑战是知道如何组织文档并停止考虑关系数据。

回答by dormsbee

SourceForgeuses MongoDB. See this presentationor read here.

SourceForge使用 MongoDB。请参阅此演示文稿或在此处阅读。

回答by okurow

We are running CouchDB as a replacemant for MySQL for our shops (70.0000 items/shop, a total of 4 million attributes of all items, cross connections between items).

我们正在运行 CouchDB 作为我们商店的 MySQL 替代品（70.0000 件商品/商店，所有商品的总共 400 万个属性，商品之间的交叉连接）。

Our goals were:

我们的目标是：

1. Easy replication from a master-db to several clients with different documents.

2. Fast pre-calculated data like "how many parts do I have with this attribute and that filter, fitting to those conditions"

1. 轻松从主数据库复制到具有不同文档的多个客户端。

2. 快速预先计算的数据，例如“我有多少部分具有此属性和过滤器，适合这些条件”

facts:

事实：

1. Our shops are now running much faster than with MySQL (and mysql-database needed additionaly 1-3 days of pre-calculating (so updating was twice a month), making the data ready for product counting and filtering, CouchDB needs 5 hours, so we could update product data every night)
2. Setting up (filtered) data distribution & backups to the shop nodes is fast and easy

1. 我们的商店现在比 MySQL 运行得快得多（而且 mysql-database 需要额外 1-3 天的预计算（所以每月更新两次），使数据准备好进行产品计数和过滤，CouchDB 需要 5 小时，所以我们可以每晚更新产品数据）
2. 设置（过滤）数据分发和备份到商店节点既快速又简单

but also:

但是也：

1. Understanding map/reduce and the limits of not having joins is quite hard
2. No operation on data like "delete where" or "update where" without external programs
3. Replication works well, unless there is a problem; then it's really hard to find out what was the reason (for beginners)
4. 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.
5. 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.

1. 理解 map/reduce 和没有连接的限制是相当困难的
2. 在没有外部程序的情况下，不对数据进行诸如“删除位置”或“更新位置”之类的操作
3. 除非出现问题，否则复制效果很好；那么很难找出原因是什么（对于初学者）
4. 如果您不是 Linux 极客，安装没有二进制文件的 CouchDB（是的，有一些是在野外，但不是每个操作系统/版本）可能会很困难。但是 CouchDB 社区很有帮助 (#couchdb)，幸运的是有一些公司（cloudant、iriscouch）提供从免费到大型企业的服务。
5. CouchDB 正在向前发展，因此有很多变化（改进）正在进行，可能会改变他们的工作方式。但基本的东西保持稳定。

As a result: MySQL as a database for data creation and maintaining is reliable and easy to understand and handle. I think we will not change this. But I also don't want to miss the power of CouchDB views and the ease of replication setup.

结果：MySQL 作为用于数据创建和维护的数据库是可靠且易于理解和处理的。我认为我们不会改变这一点。但我也不想错过 CouchDB 视图的强大功能和复制设置的简便性。

Production couches sometimes caused trouble after months of work due to misconfiguration and forgotten logrotates (view building takes too long or hangs, replication stops), but never lost data, and always could be easily reset.

由于配置错误和忘记 logrotates（视图构建时间过长或挂起，复制停止），生产沙发有时会在几个月的工作后引起问题，但不会丢失数据，并且总是可以轻松重置。

回答by Sergio Tulentsev

I am using CouchDB in production. Currently it stores all those 'optional' fields that weren't in the original DB schema. And right now I am thinking about moving all data to CouchDB.

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

It's quite a risky step, I admit. Firstly, because it's not v1.0 yet. And secondly, because it is drivespace-hungry. By my calculations, CouchDB file (with indexes) is ~30 times larger than MySQL database with the same rows. But I am pretty sure it will work out just fine.

我承认这是一个相当冒险的步骤。首先，因为它还不是 v1.0。其次，因为它占用大量空间。根据我的计算，CouchDB 文件（带索引）比具有相同行的 MySQL 数据库大约 30 倍。但我很确定它会很好地工作。

回答by J Chris A

CouchDB 0.11 (released at the end of March) is a feature-freeze release for 1.0. This means we'll be maintaining compatibility with the current API for 1.0, so now is a good time to take another look at CouchDB if you haven't in a while.

CouchDB 0.11（3 月底发布）是 1.0 的功能冻结版本。这意味着我们将保持与 1.0 的当前 API 的兼容性，所以如果您有一段时间没有再看看 CouchDB，现在是个好时机。

The CouchDB 0.11 source code release is available here.There are binary installers and other goodies linked here.

该CouchDB的0.11源代码版本可以在这里找到。有二进制安装程序和链接在这里等好东西。

回答by Sasha Chedygov

I don't know anything about MongoDB, but from the CouchDB FAQ:

我对 MongoDB 一无所知，但来自CouchDB 常见问题解答：

Is CouchDB Ready for Production?

Yes, see InTheWildfor a partial list of projects using CouchDB. Another good overview is CouchDB Case Studies

CouchDB 准备好投入生产了吗？

是的，有关使用 CouchDB 的部分项目列表，请参阅InTheWild。另一个很好的概述是CouchDB 案例研究

Also, some links:

另外，一些链接：

• Re: Current CouchDB state?
• SimpleDB, CouchDB and Other "NEW" Data Stores - Feedback

• 回复：当前的 CouchDB 状态？
• SimpleDB、CouchDB 和其他“新”数据存储 - 反馈

回答by clintm

We use couchdb in production and have since just before the project went under the Apache umbrella.

我们在生产中使用 couchdb，并且在该项目归入 Apache 保护伞之前。

We use it to store everything that we might otherwise use a dbms, plus all sorts of unstructured data. Personally, I really like how you can just throw all sorts of data into it and use the views to cull what you don't need depending on the situation.

我们使用它来存储我们可能会使用 dbms 的所有内容，以及各种非结构化数据。就我个人而言，我真的很喜欢您可以将各种数据放入其中并使用视图根据情况剔除不需要的数据。

The hardest part was moving away from the dbms mindset. We wrote our own migration utils when the storage format changed just to be safe, so that wasn't really a problem.

最困难的部分是摆脱 dbms 的心态。为了安全起见，当存储格式发生变化时，我们编写了自己的迁移实用程序，所以这不是真正的问题。

We haven't had any negative experiences yet, but then again we haven't had the setup under any kind of huge load. I thinkthings would work pretty well since we have two slave type servers that replicate from a single master server that gets all of the writes. I'm pretty sure that we don't have to do it that way for replication to work correctly, but it's how we set it up in the beginning and it stuck.

我们还没有任何负面的经历，但话又说回来，我们还没有在任何类型的巨大负载下进行设置。我认为事情会很好，因为我们有两个从属类型的服务器，它们从一个获取所有写入的主服务器复制。我很确定我们不必这样做才能使复制正常工作，但是我们一开始就是这样设置的，但它卡住了。

回答by Ryan Duffield

We use CouchDB to store mobile inbound and outbound messages and to report on this traffic via some custom views that I wrote. The front-end is written in Python. We did not have any real technical issues, and it has been running since the end of December. The only hurdle I encountered was initially thinking in terms of MapReduce, but once I learned how to do that, everything else went smoothly.

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

回答by Joshua Burns

We are currently using MongoDB in production as the caching layer as well as storage engine for product importing and manipulating product data. We are an eCommerce company managing over two million products (100+ million attributes), spanning 10+ distributors and without MongoDB, this task would be nearing impossible.

我们目前在生产中使用 MongoDB 作为缓存层以及用于产品导入和操作产品数据的存储引擎。我们是一家电子商务公司，管理着超过 200 万种产品（100 多个属性），跨越 10 多个分销商，如果没有 MongoDB，这项任务几乎是不可能的。