MongoDB or CouchDB - fit for production?

Question

I was wondering if anyone can tell me if MongoDB or CouchDB are ready for a production environment.

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.

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?

Solution 1

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

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

Solution 2

SourceForge uses MongoDB. See this presentation or read here.

Solution 3

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).

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"

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

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.

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.

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.

Solution 4

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.

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.

Solution 5

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.

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

View more solutions

Comments

[kiwicptn]

What are they using it for? Or how are they using it?

[J Chris A]

This is old news: Now the link says "Yes, see InTheWild for a partial list of projects using CouchDB. Another good overview is CouchDB Case Studies"

[Sasha Chedygov]

@J Chris A: Of course it's old, I posted this a year and a half ago. :)

[Industrial]

How reliable has mongoDB proven to be for you? + How well have replication worked in real life?

[Joshua Burns]

We implement the replica set topology running 1.6.(not sure what the minor version is off hand). So far the only issue we encountered is apparently when a disk runs out of space, even with save writes enabled, no flags are raised. So just make sure you have PLENTY of space!

[Joshua Burns]

Reliability however has been phenomenal, surprisingly as good as we had hoped. No problems with crashing as of yet- Although this is somewhat of a new implementation.

[o1iver]

I know this is an old question, but maybe someone will look at it again. Here is a presentation by a SourceForge dev about how they employ MongoDO: infoq.com/presentations/MongoDB-at-SourceForge

[johndodo]

Actually for me the major challenge is going back if you need to. Once you remove "relational constraints" from your mind it is difficult to go back. :)

[rizwan]

while you have not specified the exact issues with licensing, there is nothing wrong with MongoDB licensing mongodb.org/about/licensing It uses the AGPL license which may be the cause of concerns in your legald department, but they state that any DB client is separate work. "we promise that your client application which uses the database is a separate work. To facilitate this, the mongodb.org supported drivers (the part you link with your application) are released under Apache license, which is copyleft free."

[Erik Kaplun]

70 000 or 700 000 items per shop? also, has anything changed since you wrote the post? some missing features implemented maybe?

[Sergio Tulentsev]

Well, it didn't work out at all. I got rid of couchdb after a couple of months.

[Sergio Tulentsev]

@aetheria: It didn't handle the load. Plus we had so much writes that we'd need to compact it every hour or so. CouchDB is not for write-heavy apps.

[ᴇʟᴇvᴀтᴇ]

Thanks. Am I right that it's updates to existing documents that's the problem? i.e. writing new documents is OK, but updating leaves unused garbage in the file. Is that correct?

[Sergio Tulentsev]

IIRC, even new writes were not too performant. Too much disk seeks with this double-header approach.

[ᴇʟᴇvᴀтᴇ]

Argh. It's so hard to know what database to choose! Did you go back to MySQL or move to a different NoSQL?

[Sergio Tulentsev]

@aetheria: back to mysql and then to mongo. Had a fair share of problems everywhere. :)

[fernandopasik]

Added big part of the list to the post