Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of karel.minarik@gmail.com
 designates 209.85.214.52 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:from:to:in-reply-to:content-type
         :content-transfer-encoding:mime-version:subject:date:references
         :x-mailer;
        b=rTy4xJo/Xp1KDR+SMVsIaSYvd5x/k41Ta+dewK0pHknRMxohyiKhaLwSQ3B8S+mU8O
         AfX4OnXHMvDM6PJCP5zQ1fWncJjQ+7wqMuksGY8DhsbUWDwW+G9lb41eiufT2N7bnf3y
         cMvA6oEEGUyMy8xIN2ecUAMWxPSEtd5v+arJ8=
Message-Id: <173F866C-8CB5-41A3-B823-7C99F5CD58FB@gmail.com>
From: =?UTF-8?Q?Karel_Mina=C5=99=C3=ADk?= <karel.minarik@gmail.com>
To: user@couchdb.apache.org
In-Reply-To: <AANLkTi=wTLG9CNWnU_XGoc1FCJ8fOPmes2A0bgQN3TZq@mail.gmail.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Subject: Re: Why use multiple databases ?
Date: Sat, 6 Nov 2010 11:30:33 +0100
References: <AANLkTi=wTLG9CNWnU_XGoc1FCJ8fOPmes2A0bgQN3TZq@mail.gmail.com>

Hello,

kinda late, but better then never :)

> (1) What kind of issues do you take into consideration when deciding
> if certain types of documents should go into their own database ?

Mainly the impossibility of map/reduce views to work accross  
databases. If you split data into separate dbs, and you need some  
reporting accross all those "accounts", you have to do some  
replication (of a subset of docs) into some "common" database. The  
same applies to fulltext indexing such as CouchDB-Lucene.

> (2) Are your decisions based on performance, security or some other
> considerations ?

We have a media monitoring application and have decided to put data  
for every application account into a separate database, mainly because:

* It simply much cleaner this way :) (NB: you can name your dbs like  
"someprefix/dbname", and this is also the path on the disk.)
* We are able to make the db accesible to the account _directly_ by  
mapping in a frontend webserver. So they are able to use the "raw  
data", not only the application API. We consider this to be the main  
benefit.
* We earn an additional layer of security for free with this setup,  
which is nice.
* We are able to very quickly and easily check sizes of dbs, view  
files, etc of accounts, eg. just by looking int Futon for the most cases
* It would be rather easy (or so we think :) to "manually shard" the  
data accross different machines (eg. accounts A-M go to machine S1, N- 
Z to machine S2, etc)

> (3) What else should I be asking you - if I was not a noob ;?)

Well, maybe just providing the context of your app. I'd say anywhere  
where you have something like "user inboxes", or something like "every  
user/account has their own data and we don't need to query accross  
them" (our case) is a good candidate for separate dbs.

Karel