CODEWITHSUNDEEP
couchdb
user86847
user86847

Reputation: 149

When is it appropriate to use couchDB?

I'm currently writing an app with quite a few different data persistence needs at very different layers and I keep wondering... when is it appropriate and when is it not appropriate to use couchDB to satisfy my persistence needs?

Upvotes: 7

Views: 1926

Answers (4)

Teemu Ikonen
Teemu Ikonen

Reputation: 11929

After implementing two production systems on top of nonrelational db, I came to conclusion that nonrelational dbs need to step little bit closer to sql to be really "alternative" to it. I understand alternative as "you get same functionality without huge difference in quality, effort or cost."

Short answer: Not that often

Long answer. Main benefit for non relational databases are high availability, schemaless and scalability. All of of this comes with significant price. If your application needs query flexibility (and / or, sort order, ..) and doest have large data or performance requirements you're better off with traditional DB like mysql or better postgres. Main challenge with non-relational database is that if you need new way to combine data (like all posts liked by user in time order) you'll need new document to insert and view to implement the query. Couchdb is document based that is good for flexibility, as you don't need to maintain schema in the database and can just "forget" old data that is missing the new fields. Document databases do not live up to full potential with statically typed languages though as you anyway have to more or less fix the data structure in your code.

Non-relational db requires push architecture. All data for all possible queries ( even rare admin ones ) needs to pushed when you insert or update data. This costs as cpu and disk but you get fast queries. In SQL based db you can just insert the row and pay the price as slow queries. CouchDB builds indexes on the first query, some other databases on insert (MongoDB, Google App Engine)

Couchdb queries are defined as javascript views that are powerful but pretty difficult to write, maintain and debug. View change means that couchdb needs to reindex all documents that is really slow if you have million or more documents. The error messages from couchdb can not be deciphered by usual admin.

Couchdb maintanance needs some manual effort to compact datafiles and indexes, new versions have automatic compaction though but using it requires some care. Compactions need to be scheduled off-peaks etc.. This can scripted pretty easily though. Db dump, backup and such tools are still pretty infant.

In short, it's not worth the effort if you're not going to need the performance or scalability of the couchdb. Personally I think its possible to "emulate" most non relational db performance benefits with sql db, redis and memcache stack. At least as long as the there is not too much data.

Upvotes: 4

rfunduk
rfunduk

Reputation: 30432

It's really a case-by-case thing, I'd say. CouchDB is simply a type of database, depending on your project it might be a perfect fit or it might be painfully limiting -- just like an RDBMS can be a perfect fit or a nightmare.

More details?

Upvotes: 1

JasonSmith
JasonSmith

Reputation: 73712

See:

Upvotes: 4

Brian Agnew
Brian Agnew

Reputation: 272217

Do you have a relational requirement ? CouchDb (as you know) doesn't have the relational structure of a normal database.

Is the RESTful nature of CouchDb important for what you're doing ?

Perhaps most importantly, who's going to support this going forward, and will they be capable of handling CouchDb? It's a fairly niche tool, and finding people experienced with it will not be easy.

Upvotes: 2

Related Questions