couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Candler <B.Cand...@pobox.com>
Subject Re: struggling with couchdb in production
Date Tue, 26 May 2009 08:05:35 GMT
On Tue, May 26, 2009 at 09:52:08AM +0200, Jurg van Vliet wrote:
> i think replication is not the solution for the specific problem i tried 
> to sketch. i am talking about simple aggregate information (10 most 
> recent documents per user, for example) over potentially thousands of 
> different databases. if i have to replicate all my databases into one big 
> database i would start with a big one and replicate out to handle load. 
> that feels like 'missing the point'. (though i am still struggling which 
> point exactly :) )

Possibly, having thousands of different databases isn't the right map to
your problem domain, since you can't have a view spanning multiple
databases.

Multiple databases make sense where the data is entirely self-contained
(data belonging to one user), especially for virtual hosting where it's a
benefit that data cannot leak from one database to another.

In an application I'm working on at the moment, I have one database per user
- but a separate global login database holding the usernames and passwords
and pointers to each user's database, so at login time I only need to query
one view.

> yes and no, it all depends on how you regard your users. i think in an  
> environment where many people create something together the conflicts  
> have meaning. i choose to expose the conflict, meaningfully, and 'help' 
> the user resolve it herself.

Yes of course; I don't mean that automated conflict resolution is required.
What I mean is - CouchDB *hides* the conflicts, whereas you and I want them
*exposed*. It is not easy even to say "give me all conflicting versions of
this document".

Regards,

Brian.

Mime
View raw message