One of our biggest issues with CouchDB is currently the lack of compaction of our database, and by lack of, I don’t mean that CouchDB doesn’t support it, I mean that we are unable to actually run it.
Compaction in a nutshell
Compaction in a nutshell is pretty cool.
As you know, CouchDB is not very space-efficient. For once, CouchDB saves revisions of all documents. Which means, whenever you update a document a new revision is saved. You can rollback any time, or expose it as a nifty feature in your application — regardless, those revisions are kept around until your database is compacted.
Think about it in terms of IMAP - emails are not deleted until you hit that magic “compact” button which 99% of all people who use IMAP don’t know what it’s for anyway.
Another thing is that whenever new documents are written to CouchDB and bulk mode is not used, it’ll save them in a way which is not very efficient either. In terms of actual storage and indexing (so rumour has it).
Compaction woes
Since everything is simple with CouchDB, compaction is a simple process in CouchDB too. Yay!
When compaction is started, CouchDB will create a new database file where it stores the data in a very optimized way (I will not detail on this, go read a science book or google if you are really interested in this!). When the compaction process finished, CouchDB will exchange your old database file with the new database file.
The woes start with that e.g. when you have 700 GB uncompacted data, you will probably need another 400 GB for compaction to finish because it will create a second database file.
The second issue is that when you have constant writing on your database, the compaction process will actually never finish. It kind of sucks and for those people who aim to provide close to 100% availability, this is extremely painful to learn.