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
