Comments on: Watch out for CouchDB

By: Damien Katz

Damien Katz — Fri, 07 Sep 2007 16:26:51 +0000

Daniel, CouchDb can support multi-document commit transactions. It’s trivial to implement, but doesn’t work with the distributed model. If you only think relationally, CouchDb doesn’t help you.

CouchDb is transactional. Documents, when saved, are either all or nothing. You cannot have a half saved document, or a file attachment partially updated. File attachments are written concurrently, and then committed. If there is a conflict, the update is aborted. Compare this to regular updating a file on the file system read by multiple users.

For, for acid compliance, CouchDb has all the properties:
Atomic - Commits are all or nothing
Consistent - Documents and views are always a complete representations of a point in time.
Isolated - Writes by multiple concurrent updates aren’t seen by others until completely commited.
Durable - the disk design of CouchDb is append-only storage which emoves the need for shutdown logic of fixup logic.

By: Jan

Jan — Fri, 07 Sep 2007 09:01:27 +0000

@aranwe CouchDb handles distribution, replication, conflict-detection, fast reporting, fulltext search, authentication, quick (as in concurrent) storage and a lot more. I don’t see where HTML or XML files give you all this. Above all, just convert your XML documents to JSON and dump them into CouchDb and you’re all fine. JSON is just waht CouchDb uses internally. This is a good thing because it keeps our code smaller an cleaner since we don’t have to do all the XML handling in the DB. You can still do that, though and JSON is an easy, yet complete, enough format to do so.

By: Jan

Jan — Fri, 07 Sep 2007 08:57:03 +0000

@Daniel CouchDb doesn’t use Mnesia or Dets but a custom storage module. Your view of the data remains consistent during you fetching or adding. Not having permanent connections doesn’t mean you don’t have connections. CouchDb’s storage module does all that is promised by ACID and there’s no way, other than disk failure, that CouchDb loses your data after it reports a safe write. Also, you’re the first to mention transactions here or anywhere in the CouchDb documentation.

By: aranwe

aranwe — Wed, 05 Sep 2007 23:54:58 +0000

I realize this may be a pretty stupid point to make, but how is this any different than just creating static html or using xml with xquery? I’m having a hard time seeing the point of building ‘yet another document storage format.’ Don’t we have enough to choose from yet?

Also, while the openness of the format may work well with only one or a few people updating the documents, trying to help a large number of people create views into an undefined schema would be a nightmare. I am sure this will find a small following, but I can’t imagine this making huge waves.

By: Daniel Lyons

Daniel Lyons — Wed, 05 Sep 2007 18:16:46 +0000

It doesn’t seem entirely fair to me to claim ACID compliance when you do not support connections. If I cannot stay connected, in what sense is my view of the data consistent and in what sense are my changes isolated to my connection? Furthermore, durability is a matter of implementation (is there any way that you could lose the data after you tell me my transaction is complete?) If compound operations of my devising cannot be bundled into atomic transactions, a claim of transaction support is extremely misleading. So I’d like to know in what sense CouchDB is ACID compliant, or even transactional. These properties are not automagically inherited from merely using Mnesia or Dets as your storage backend.

By: Jan Lehnardt

Jan Lehnardt — Mon, 03 Sep 2007 19:16:29 +0000

@Sam excellent. Damien, CouchDb’s author worked on the Notes core server. Go figure :-) And getting data out _is_ easy.

By: Sam

Sam — Mon, 03 Sep 2007 18:28:03 +0000

Sounds kind of like Lotus Notes. Notes was fine for getting data into it and working with it. However when you wanted to get the data out it was a massive pain.

By: Jan Lehnardt

Jan Lehnardt — Mon, 03 Sep 2007 15:36:25 +0000

@Mike CouchDb is not meant to replace relational databases. It uses just a different approach to storing and retrieving data that might or might not suit your requirements, beliefs or preconceptions.

…and I bet this will work much faster than with CouchDb …

is not much of an argument either, sorry :-)

CouchDb is just another tool in your workbench.

By: Mike Borozdin

Mike Borozdin — Sun, 02 Sep 2007 13:40:21 +0000

I see no point in this. Document management can still be done with any relational databases and I bet this will work much faster than with CouchDb that seems to be more a technology prospect now than an actual implementation, because if the idea proves valuable it will be takenover by huge databases producers.

The need for de-normalisation, particularly in document management is due to volume more than anything else. I work with a few DB’s that are several terabytes in size each, and the only way to get the performance increases we need is to de-normalise data by splitting it into tables of similarly grouped data (eg. date based).

This doesn’t prove that it will work any faster with CouchDB at least with this implementation.

By: Smith

Smith — Fri, 31 Aug 2007 19:01:17 +0000

Very cool idea