Re:Comparing Mongo DB and Couch DB
by mark242 on Wednesday August 10, 2011 @03:07PM
(#2869699)
Absolutely it would be great for logging. Assuming that you don't need atomicity for your logs (eg, I want to see that log line reflect in my reports _right_ _now_) Couch is a perfect way to dump a huge amount of data really quickly. For reporting, the map/reduce system of Couch is a great fit. There's an initial learning curve -- as with anything, really -- but you'll find that Couch would be a great way to get logged data (which can be pretty unstructured) and report on it easily and quickly.
[ Parent
| on HN ]
no, it wouldn't. It would be a horrible fit, imo.
You don't need versioning info for logging, and the extra compacting of the database is another aspect, since with logging heavy applications you will write all the time...
I love CouchDB but i definitely wouldn't use it for logging.
You don't need to worry about the versioning for a document that you never update. You can just blast the logfiles into the database and not worry about conflicts. Similarly, database compaction is really the biggest concern when you're updating documents, not just dumping new ones into the database. I would expect a very linear growth for a logging app.
The problem doesn't come with the inserts, it comes with the deletes, where CouchDB will keep some metadata and stubs around to support its replication use cases. In a pure logging setup this is perhaps less than ideal.
ok, my initial thought was one document per logfile, containing an increasing amount of loglines, but that's probably the worst approach possible. One document per logline which is appended to the database should be much better.
Couch's map-reduce is quite slow for ad-hoc stuff. It's excellent for frequently viewed data (as you can get stale views, and new views are sort of incrementally done), but it's slow to set up.
atomicity doesn't mean, or imply, instantaneous.
However, a document update in CouchDB is fully ACID (including the A of Atomicity). People often confuse transactions around multiple changes with ACID for reasons that I cannot fathom. CouchDB does not have support the former (they don't scale well in clusters) but absolutely supports the latter.