couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Campbell <>
Subject Re: How do you handle multiple document groups?
Date Fri, 06 Nov 2009 09:07:32 GMT
Jan, Brian, those are all excellent points. Per your recommendations,
I've decided to keep it a single database-per-domain, with no "type"
databases or grouping by naming conversion. You've both enumerated
numerous important benefits, the greatest of which (for me) is:

> But it does make your application harder to write - you can't have views which incorporate
multiple types -

Not being able to write a view which incorporates documents of other
types would be a deal breaker.

Jan's comment that type databases feels too RDBMSy is correct - I come
from almost a decade of RDBMS-only modeling - so I'll definitely need
to "relax" a bit as suggested.

Thanks again everyone!

On Fri, Nov 6, 2009 at 9:56 AM, Jan Lehnardt <> wrote:
> On 6 Nov 2009, at 09:49, Brian Candler wrote:
>> 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.
> Good points! In addition to the self-contained and security points. A db per
> user allows you let the user replicate all his/her data for offline use
> which
> you may or may not like to support. But if not, you should think about it :)
> Cheers
> Jan
> --

View raw message