CouchDB 的缺点

Question

I've very recently fallen in love with CouchDB . I'm pretty excited by its enormous benefits and by its beauty. Now I want to make sure that I haven't missed any show-stopping disadvantages.

What comes to your mind? Attached is a list of points that I have collected. Is there anything to add?

• Blog posts from as late as 2010 claim "not mature enough" (whatever that's worth).
• Slower than in-memory DBMS.
• In-place updates require server-side logic (update handlers) .
• Trades disk vs. speed: Databases can become huge compared to other DBMS (compaction functionality exists, though).
• "Only" eventual consistency.
• Temporary views on large datasets are very slow.
• Replication of large databases may fail .
• Map/reduce paradigm requires rethinking (only for completeness).

The only point that worries me is #3 (in-place updates), because it's quite inconvenient.

Answer 1

• The data is in JSON

Which means that documents are quite large (BigData, network bandwidth, speed), and having descriptive key names actually hurts, since they add up to the document size.

• No built in full text search

  Although there are ways: couchdb-lucene , elasticsearch

plus some more :

• It doesn't support transactions

It means that enforcing uniqueness of one field across all documents is not safe, for example, enforcing that a username is unique. 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. There aren't many instances that we would want to simply inc/decrement some value where we couldn't just store the individual documents separately and aggregate them with a view.

• Relational data

If the data makes a lot of sense to be in 3rd normal form, and we try to follow that form in CouchDB, we are going to run into a lot of trouble. A possible way to solve this problem is with view collations, but we might constantly going to be fighting with the system. If the data can be reformatted to be much more denormalized, then CouchDB will work fine.

• Data warehouse

The problem with this is that temporary views in CouchDB on large datasets are really slow. Using CouchDB and permanent views could work quite well. However, in most of cases, a Column-Oriented Database of some sort is a much better tool for the data warehousing job.

But CouchDB Rocks!

But don't let it discorage you: NoSQL DBs that are written in Erlang (CouchDB, Riak) are the best, since Erlang is meant for distributed systems. Have fun with Couch!

Answer 2

2 more things, which make me cry when using CouchDB (though it's awesome):

• It is not designed for frequently updated data
• It doesn't have built-in fulltext search

Answer 3

• Lack of reader ACLs (does exist for writers, however)

As an old Lotus Domino pro I was looking to CouchDB as an alternative for a new project I'm kicking off and found the limits on readers to be very weak in Couch vs. Domino. In my app security is an important consideration and Couch would require a middleware layer to handle reader security.

If you have database in which it's okay that all defined users can see all the documents, then Couch looks like an interesting platform.

If restricting reads is needed then you'll need to look to a middleware solution or consider another alternative.

Note to CouchDB developers: Improve the platform security options. I realize they will diminish performance when used but note that and make the option available.

Now back to determining which database to use...

Answer 4

• currently no support for ad-hoc queries (might change with advent of UnQL)
• lack of binary protocol support for faster communication

Answer 5

1. Lack of support for data archiving - No official support for data
   archiving is provided with couch db open source distribution.
2. Deleting records from db is not straightforward
3. No option to set a expire (TTL) flag for documents

Answer 6

It's nothing to do with CouchDB itself, but being a relative newcomer on the scene means that most sysadmins are still unfamiliar with it and won't allow it anywhere near "their" data centers. If you're in a situation where you're deploying to an environment you don't control yourself, this can be quite the battle.