Received: by 10.66.76.5 with SMTP id g5mr2597711paw.44.1349477367575;
        Fri, 05 Oct 2012 15:49:27 -0700 (PDT)
X-BeenThere: mongodb-user@googlegroups.com
Received: by 10.68.226.100 with SMTP id rr4ls16518355pbc.2.gmail; Fri, 05 Oct
 2012 15:49:10 -0700 (PDT)
Received: by 10.68.211.6 with SMTP id my6mr3610498pbc.15.1349477350268;
        Fri, 05 Oct 2012 15:49:10 -0700 (PDT)
Date: Fri, 5 Oct 2012 15:49:09 -0700 (PDT)
From: Brandon Black <brandonmbl...@gmail.com>
To: mongodb-user@googlegroups.com
Message-Id: <b2c3ef71-5be1-480c-818a-13f887829cd2@googlegroups.com>
In-Reply-To: <CAF75pB3SG9o2uQB94wkbF-FSv9zdOnqKwLu1L_3tAH5QXz4rVA@mail.gmail.com>
References: <CAF75pB3SG9o2uQB94wkbF-FSv9zdOnqKwLu1L_3tAH5QXz4rVA@mail.gmail.com>
Subject: Re: write lock
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_182_11674883.1349477349926"

------=_Part_182_11674883.1349477349926
Content-Type: multipart/alternative; 
	boundary="----=_Part_183_26998970.1349477349926"

------=_Part_183_26998970.1349477349926
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

So it's absolutely possibly for you to structure your data this way. 
Splitting each of your collections into their own database would definitely 
get you around DB-level write locks, but there would obviously be an 
additional cost incurred in disk space pre-allocation.

Additional disadvantages of putting every collection in its own database 
include:


   - Monitoring: Commands like listDatabases() become significantly slower 
   and services like MMS (10gen's monitoring service) will collect stats less 
   frequently for each database. If you have over 100 databases, MMS won't 
   work at all.


   - Preallocation: Even though this is a background process, it's still an 
   operation that competes with others for resources. As you add more 
   databases, the need for preallocation to run will become more common and as 
   a result demand more resources.

Considering the trade-offs, this approach is probably not too harmful on a 
small number of write-heavy collections, but its likely not suitable if 
you're looking at doing this for 100s of collections.

On Thursday, October 4, 2012 12:50:49 AM UTC-7, Raxit Sheth <Mobile 4 
Mumbai> wrote:
>
> Hi 
>
> Using mongodb 2.2.0, Write/Update heavy operations and mongod is 
> having lock per db (and not lock per collection). 
>
> Is it good to have one collection per db in this case? (provided we 
> are having manageable numbers of collections) 
>
> Anyone has tried, if yes any learning in doing so? 
>
> Thanks in Adv, 
> Raxit 
>

------=_Part_183_26998970.1349477349926
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

So it's absolutely possibly for you to structure your data this way. Splitt=
ing each of your collections into their own database would definitely get y=
ou around DB-level write locks, but there would obviously be an additional =
cost incurred in disk space pre-allocation.<div><br></div><div>Additional d=
isadvantages of putting every collection in its own database include:</div>=
<div><br></div><div><ul><li><span style=3D"line-height: normal;">Monitoring=
: Commands like listDatabases() become significantly slower and services li=
ke MMS (10gen's monitoring service) will collect stats less frequently for =
each database. If you have over 100&nbsp;databases, MMS won't work at all.<=
/span></li></ul><ul><li><span style=3D"line-height: normal;">Preallocation:=
 Even though this is a background process, it's still an operation that com=
petes with others for resources. As you add more databases, the need for pr=
eallocation to run will become more common and as a result demand more reso=
urces.</span></li></ul><div>Considering the trade-offs, this approach is pr=
obably not too harmful on a small number of write-heavy collections, but it=
s likely not suitable if you're looking at doing this for 100s of collectio=
ns.</div><br>On Thursday, October 4, 2012 12:50:49 AM UTC-7, Raxit Sheth &l=
t;Mobile 4 Mumbai&gt; wrote:<blockquote class=3D"gmail_quote" style=3D"marg=
in: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Hi
<br>
<br>Using mongodb 2.2.0, Write/Update heavy operations and mongod is
<br>having lock per db (and not lock per collection).
<br>
<br>Is it good to have one collection per db in this case? (provided we
<br>are having manageable numbers of collections)
<br>
<br>Anyone has tried, if yes any learning in doing so?
<br>
<br>Thanks in Adv,
<br>Raxit
<br></blockquote></div>
------=_Part_183_26998970.1349477349926--

------=_Part_182_11674883.1349477349926--