couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Malone" <>
Subject Re: When to use CouchDB, when not to...
Date Mon, 13 Oct 2008 23:50:19 GMT
> i'd contend, however that you'd really have to structure you app in a very
> bad way to have any the db schema be of consequence.  there are indexes and
> there is caching at many levels.  hitting the app and db for ever request
> doesn't scale period.  in fact, rdbms don't scale well anyhow - not if you
> count 'easily' in your criteria that is.  anyone who has every tried tried
> to setup high-availability db backends knows this.  again though, this is a
> point where couchdb could really shine - they look to have addressed this
> from the get go.

I'm not sure I follow... seems like you're contradicting yourself here a
bit. I agree with the second part - RDBMSs don't scale well. At a high
level, for most web applications they're more or less a single "thread,"
creating a bottleneck in a system that can otherwise scale horizontally. Of
course you can shard, creating additional "threads," but that's not a at all
a straightforward process.

With that in mind, I'd say that you have to structure your application very
carefully in order for the DB layer to scale. The DB schema is critical
here, you must denormalize and carefully shard your data in order to scale.
Normalizing your schema to the extent you described earlier, in order to
allow "dynamic properties," would destroy performance on a highly trafficed
web application. Sure, you can cache, but you still need to read from the DB
for new or invalidated items.

The sort of architecture I've been contemplating is one where certain
heavyweight entities in the application would be stored in CouchDB while
other lighter weight/more relational entities would remain in the RDBMS.
Suppose I were designing a messaging system, for instance. I may store basic
User information in an RDBMS, along with social graph information, and an
"inbox" table that stores the id of each Message sent to each User (some of
these tables would still need to be sharded at some point). The Messages
themselves I'd store in CouchDB. I may also put certain extended Profile
information for Users in CouchDB.

Anyways, I'm fairly new to document-based databases and my intuition may be
wrong here (please correct me if it is) but it seems to me that CouchDB can
be used alongside a more traditional RDBMS in this way.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message