> 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
