Account Options

  1. Sign in
The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Google Groups Home
« Groups Home
Message from discussion Indexing strategi

Received: by 10.236.151.39 with SMTP id a27mr6663459yhk.42.1349197859312;
        Tue, 02 Oct 2012 10:10:59 -0700 (PDT)
X-BeenThere: mongodb-user@googlegroups.com
Received: by 10.236.133.84 with SMTP id p60ls1079140yhi.5.gmail; Tue, 02 Oct
 2012 10:10:48 -0700 (PDT)
Received: by 10.236.110.67 with SMTP id t43mr660743yhg.6.1349197848298;
        Tue, 02 Oct 2012 10:10:48 -0700 (PDT)
Date: Tue, 2 Oct 2012 10:10:47 -0700 (PDT)
From: Emily S <emily.sto...@10gen.com>
To: mongodb-user@googlegroups.com
Message-Id: <2ac3b787-2d62-489e-873f-7d0961496733@googlegroups.com>
In-Reply-To: <65c06fa8-40fb-4c4f-a962-42ea1d935523@googlegroups.com>
References: <65c06fa8-40fb-4c4f-a962-42ea1d935523@googlegroups.com>
Subject: Re: Indexing strategi
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_1175_28483182.1349197847656"

------=_Part_1175_28483182.1349197847656
Content-Type: multipart/alternative; 
	boundary="----=_Part_1176_29324477.1349197847656"

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

Hi Andreas

MongoDB will only keep the right-most (or left-most, depending on whether 
the index is ascending or descending) values in RAM if the indexed field 
incrementally grows with every insert and most queries select recently 
added documents.
Given that you have 200 000 possible owners, evenly distributed across 15 
000 000 documents, and only 3 possible statuses, your compound index on 
Owner, then Status is the right way to go.  



On Tuesday, October 2, 2012 9:31:36 AM UTC-4, Andreas Bernhardsson wrote:
>
> I have some questions regarding the order of fields in indexes.
>
> I have a quite large collection of documents which each has an "Owner" and 
> "Status".
> At the moment I have a number of compound indexes on first "Owner" and 
> then "Status" and then some other fields that different queries use.
> This collection has about 15 000 000 entries, there are about 200 000 
> possible owners quite evenly distributed across the collection.
> Then we have a "Status" fields which basically tells if 
> the document should be a part of the search or not, this one would cut down 
> the amount entries to 1/3.
>
> I read in the MongoDB documentation about the database tries to hold the "right-most" 
> values in RAM, would creating the index on first "Status" and then "Owner" 
> (instead of the other way around) aid the database in doing this?
>
> A query mostly looks something like these:
> {
>  Owner:{'$in':{1,2,4,6, and so on with up to 1000 entries... }},
>  Status: 1,
>  etc: ...
> }
>
>
> Best Regards
> Andreas Bernhardsson
>
>
------=_Part_1176_29324477.1349197847656
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi Andreas<div><br></div><div>MongoDB will only keep the right-most (or lef=
t-most, depending on whether the index is ascending or descending) values i=
n RAM if the indexed field incrementally grows with every insert and most q=
ueries select recently added documents.</div><div>Given that you have 200 0=
00 possible owners, evenly distributed across 15 000 000 documents, and onl=
y 3 possible statuses, your compound index on Owner, then Status is the rig=
ht way to go. &nbsp;</div><div><br></div><div><br><br>On Tuesday, October 2=
, 2012 9:31:36 AM UTC-4, Andreas Bernhardsson wrote:<blockquote class=3D"gm=
ail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc soli=
d;padding-left: 1ex;">I have some questions regarding the order of fields i=
n indexes.<div><br></div><div>I have a quite large collection of&nbsp;docum=
ents&nbsp;which each has an "Owner" and "Status".</div><div>At the moment I=
 have a number of&nbsp;compound indexes on first "Owner" and then "Status" =
and then some other fields that different queries use.</div><div>This colle=
ction has about 15 000 000 entries, there are about 200 000 possible owners=
 quite evenly distributed across the collection.</div><div>Then we have a "=
Status"&nbsp;fields&nbsp;which basically tells if the&nbsp;document&nbsp;sh=
ould be a part of the search or not, this one would cut down the amount ent=
ries to 1/3.</div><div><br></div><div>I read in the MongoDB documentation a=
bout the database tries to hold the "<font color=3D"#000000" face=3D"helvet=
ica, arial, sans-serif"><span style=3D"font-size:14px;line-height:21.583333=
96911621px">right-most" values in RAM, would&nbsp;creating&nbsp;the index o=
n first "Status" and then "Owner" (instead of the other way around) aid the=
 database in doing this?</span></font></div><div><br></div><div>A query mos=
tly looks something like these:</div><div>{<br></div><div>&nbsp;Owner:{'$in=
':{1,2,4,6, and so on with up to 1000 entries... }},</div><div>&nbsp;Status=
: 1,</div><div>&nbsp;etc: ...</div><div>}</div><div><br></div><div><br></di=
v><div>Best Regards</div><div>Andreas Bernhardsson</div><div><br></div></bl=
ockquote></div>
------=_Part_1176_29324477.1349197847656--

------=_Part_1175_28483182.1349197847656--