couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ara.t.howard" <ara.t.how...@gmail.com>
Subject Re: When to use CouchDB, when not to...
Date Tue, 14 Oct 2008 01:04:59 GMT

On Oct 13, 2008, at 5:50 PM, Mike Malone wrote:

>> 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.
>
> Mike

sure - i agreed totally.  by 'does not scale' i meant once you want to  
move beyond one machine - then it's such a royal PITA.  of course the  
schema is important at a high level, but a relationship here or there  
shouldn't make or break performance.

i'm working on a similar mixture of storage at the moment - but the  
thought of replication and scaling makes me a bit queasy.  the beauty  
of couchdb is the concept that everything talks http which should  
provide mechanisms for really novel scaling strategies to emerge.

cheers.

a @ http://codeforpeople.com/
--
we can deny everything, except that we have the possibility of being  
better. simply reflect on that.
h.h. the 14th dalai lama




Mime
View raw message