incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Candler <B.Cand...@pobox.com>
Subject Re: How do you handle multiple document groups?
Date Fri, 06 Nov 2009 08:49:57 GMT
On Thu, Nov 05, 2009 at 11:12:08AM -0800, Adam Wolff wrote:
> Can I ask what the advantage of this is? Is this for replication? I like
> having typed databases; it seems like that will be an easy way to solve
> scaling problems.

A database per type is only going to be a limited number: e.g. if you have
records of type X, type Y and type Z that's three databases. You could split
these across three servers but would likely end up with very unbalanced
load.

If you have a database per domain, and you have 10,000 domains, then having
a database per domain is going to give you a lot more options for scaling -
e.g. split the domains across N databases, 1/Nth per database.

Combining the two, so you have 30,000 databases, doesn't really give you any
more options for scaling. But it does make your application harder to write
- you can't have views which incorporate multiple types - and it will
probably make it perform less well, because couchdb will need to keep three
times as many filehandles open (or rather, for a given load it will discard
cached filehandles more early, so will have to open databases more often)

You can identify types within the doc _id if you want, e.g.
   user_xxxxxxx
   post_yyyyyyy
It's easy enough to split the _id within a view to identify the type. Or you
can just use an attribute within the doc.

Also: another reason for a separate database per domain is for security
purposes, as it makes it easy to virtualise your app and prevents data
leakage from one account to another. You can make the database name an
attribute of the user's session. Having separate databases per type within a
domain just makes access control more complex - you have to grant the user
access to three databases - without really giving any security benefit.

Just my 2c.

Brian.

Mime
View raw message