CouchDB really sucks at doing some things. That should come as no surprise, as every technology has its advantages and its drawbacks. The thing is, when a new technology comes out that looks really promising and cool, everyone writes about all of its advantages, and none of its drawbacks. Then, people start to use it for things it isn't very good at, and they are disappointed. In that spirit, I would like to talk about some of the things that (in my experience) CouchDB is absolutely not good at, and that you shouldn't try to use it for.
First, it doesn't support transactions in the way that most people typically think about them. That means, enforcing uniqueness of one field across all documents is not safe. A classic example of this would be enforcing that a username is unique. You can check whether a username exists, and if not, create a new one. There is no guarantee, however, that between the time that your app has checked for its existence, and the time that you write the new user to the database, that some other instance of your app hasn't beat you to that write.
Another consequence of CouchDB's inability to support the typical notion of a transaction is that things like inc/decrementing a value and saving it back are also dangerous. Fortunately there aren't many instances that you would want to simply inc/decrement some value where you couldn't just store the individual documents separately and aggregate them with a view.
Secondly, CouchDB sucks at dealing with relational data. If your data makes a lot of sense to be in 3rd normal form, and you try to follow that form in CouchDB, you're going to run into a lot of trouble. Yes, it's probably possible with tricks with view collations, but you're constantly going to be fighting with the system. If your data can be reformatted to be much more denormalized, then CouchDB will work fine.
Thirdly, CouchDB sucks at being a data warehouse. In every data warehouse that I've ever run into, people have all kinds of different requests for how to slice the data. And they all want it to be done, yesterday. The problem with this is that temporary views in CouchDB on large datasets are really slow, because it can't use any of its normal indexing tricks. If you by some chance have a very rigid way of looking at your data, using CouchDB and permanent views could work quite well. But in 99% of cases, a Column-Oriented Database of some sort is a much better tool for the data warehousing job.
So does CouchDB suck? No, it's by far my favorite new database technology on the block. What it's good at doing, it's great at doing, but that doesn't mean that it should be used for everything. With the kinds of scaling issues that we're seeing with today's highly-interactive web applications, we need to make use of a broad range of technologies, and use each one for its greatest strengths. That's called using the right tool for the job, and that's never gone out of style.
All Content
You can ensure the uniqueness of the username by using it in the Document id. Set the document id as User_<username> and the uniqueness will be guarantied. Of course, if you use several distributed instances, that wouldn't work too well but then again, uniqueness in a distributed environment just doesn't work.
Good point, but there's still the race condition, though. You check if the document with that key exists, then another thread does, so both threads see that it's available, then both threads try to write.
Couchdb checks documents ID automatically for you, no need to start new threads. I guess you mean checking uniqueness in a decentralized set up with various instance. In that case you are right, however in a master to master environment, there is no other way I guess.
This is the same as a normal relational database: you insert the new user and use the login as key. If there is already a user with that name, the relational database will through a "referencial integrety" exception that you catch and deal with.
Its the same with CouchDB: create the document and use the login as the key (maybe with a small prefix). If it fails, you get the error back and deal with it.
I agree with your other points, but this one you can deal with.
Best regards,
About the data warehouse, you should be able to do pretty cool stuff once Map/Reduce/Merge is implemented, which should add joins and more relational goodness into CouchDB http://portal.acm.org/citation.cfm?doid=1247480.1247602
Can't wait to see what the map/reduce implementation brings to the table. It should in theory make CouchDB very scalable and fast. Which could in turn make a very good data warehouse.
Map/Reduce is already there, it's Map/Reduce/Merge that's still not there.
Yeah CouchDB doesn't do all of these things but its a *different* kind of database. It's not a relational DB in the first place, so why mention that being a deterrent?
Like all technologies it has its place, and couchDB is exciting because its a new kind of DB that can scale across many servers. So yeah, it requires people to learn how to do things in a new way, but comparing CouchDB to a traditional RDBMS like MySQL or Postgresql is unfair at best.
That was the point of the post as I saw it -- it outlined what CouchDB is and why it's good at it, and how it is NOT like those systems and shouldn't be used like them. A comparison is not unfair, it's necessary because a lot of people might see this as an evolution of databases, not a different approach.
Interesting post. I felt in a similar way when I started learning App Engine a few months ago. You're right, this a tool that -- like any other -- has its use cases that it serves well and other where it is not as good. However, one thing I've learned is that the restrictions are often not as bad as they originally seem. Lots of things where I thought "I cannot do this here" turned out to be more like "I have to do this in a different way". Over time, new idioms and recipes emerged for these use cases. If you feel passionate enough about this database, searching for and documenting these tidbits on your blog will help making the product more mature and broadly useable. Keep up the great work :-)
"Why CouchDB Sucks [...] So does CouchDB suck? No, it's by far my favorite new database technology on the block."
Hmm.
Peace
-Stephan
The chaps using a device to illustrate a point. Just go with it, and forget he used the word "suck".
Interesting article, and thanks.
"If you feel passionate enough about this database" ... why would anyone feel passionate about a database? It's just a tool and doesn't require cheerleading.
I am passionate about many of my tools.
My chef's knife, bicycle, programming language, and audio system.
What is wrong with being passionate about something you care about?
would you care to have a comparative look at dedomenon? it's the engine behind http://myowndb.com and available at http://dedomenon.org.
thanks. :-)
@trevor while you're right in that it's not a relational DB in the first place, i still think it's worth mentioning because I've seen a lot of people try to treat it as one.
In the ruby community at least, there seems to be this unholy obsession with emulating activerecord-style associations on top of couchdb, which in my mind is just plain stupid.
@mattly
It's not worth mentioning because it's on the CouchDB site:
"What it is Not
* A relational database.
* A replacement for relational databases."
Quite ininteresting point of view. Why the hell do you want tjhis database does those things ??? When i red about couchDB, the first idea was that is a document database. Nothing more but it sounds very good for this perpose.
So start reading the doc and then install and try it's good for what you want to do.
I'll use couchDB for my website whith a relationnal DB cause each of them are good for what they do
I think that you can increment/decrement a value quite safely with couchdb. There is the _rev-field that makes the update fail if someone has updated the document between your GET and PUT.
As far as the concerns regarding relational structures are concerned, CouchDB clearly declares that it's not a relational database system at all. All what it is a flat collection of documents having fields of various types.
Could you please share any benchmarks regarding this?
Or do you have a REST client for it?
Thanks for this post. The "What it is Not" section in the CouchDB site is very generic and I had been looking for specific use cases when it's really stupid to use CouchDB. On reading each of the points mentioned, the concepts were more solidified in my brain. I can now play with this tool more responsibly.
Thanks again.