50.Tips.and.Tricks.for.MongoDB.Developers

这些mongoDB tips全部来源于：50.Tips.and.Tricks.for.MongoDB.Developers 有兴趣可以读读这本书。

 

MongoDB tips#7: Pre-populate anything you can

 

当我们在设计mongodb的schema的时候，有些document在开始的时候它可能只包含几个fields，但是后面会继续添加更多的fields进去，这个时候一种推荐的方式就是预填充，这里主要是用过一个例子来说明这个问题，比如我们要统计用户访问某页每分钟的UV。

 

If you know that your document is going to need certain fields in the future, it is more

efficient to populate them when you first insert it than to create the fields as you go.

For example, suppose you are creating an application for site analytics, to see how many

users visited different pages every minute over a day. We will have a pages collection,

where each document represents a 6-hour slice in time for a page. We want to store

info per minute and per hour:

 

 

{ "_id" : pageId, "start" : time, "visits" : { "minutes" : [ [num0, num1, ..., num59], [num0, num1, ..., num59], [num0, num1, ..., num59], [num0, num1, ..., num59], [num0, num1, ..., num59], [num0, num1, ..., num59] ], "hours" : [num0, ..., num5] } } 

 

 

We have a huge advantage here: we know what these documents are going to look like

from now until the end of time. There will be one with a start time of now with an entry

every minute for the next six hours. Then there will be another document like this, and

another one.

Thus, we could have a batch job that either inserts these “template” documents at a

non-busy time or in a steady trickle over the course of the day. This script could insert

documents that look like this, replacing someTime with whatever the next 6-hour interval

should be:

 

 

{ "_id" : pageId, "start" : someTime, "visits" : { "minutes" : [ [0, 0, ..., 0], [0, 0, ..., 0], [0, 0, ..., 0], [0, 0, ..., 0], [0, 0, ..., 0], [0, 0, ..., 0] ], "hours" : [0, 0, 0, 0, 0, 0] } } 

 

 

Now, when you increment or set these counters, MongoDB does not need to find space

for them. It merely updates the values you’ve already entered, which is much faster.

For example, at the beginning of the hour, your program might do something like:

 

 

> db.pages.update({"_id" : pageId, "start" : thisHour}, ... {"$inc" : {"visits.0.0" : 3}}) 

 

 

This idea can be extended to other types of data and even collections and databases

themselves. If you use a new collection each day, you might as well create them in

advance.

 

MongoDB tips#8: Preallocate space, whenever possible

 

这个tips其实和上面的tip7一个意思，要先占足够大的地盘，免得后面越做越大地盘不够用了还要搬家，那就麻烦了。

 

This is closely related to both “Tip #6: Do not embed fields that have unbound

growth” on page 7 and “Tip #7: Pre-populate anything you can” on page 8. This is an

optimization for once you know that your documents usually grow to a certain size,

but they start out at a smaller size. When you initially insert the document, add a

garbage field that contains a string the size that the document will (eventually) be, then

immediately unset that field:

> collection.insert({"_id" : 123, /* other fields */, "garbage" : someLongString}) > collection.update({"_id" : 123}, {"$unset" : {"garbage" : 1}}) 

This way, MongoDB will initially place the document somewhere that gives it enough

room to grow

 

 

MongoDB tip #9: Store embedded information in arrays for anonymous access

 

这里说的就是在什么时候使用array还是subdocument，这里主要用两个例子来说明什么时候该使用什么，当你确定知道要查询哪个field的时候可以选择subdocument，但是当你不知道就选择array.

 

 

A question that often comes up is whether to embed information in an array or a subdocument.

Subdocuments should be used when you’ll always know exactly what you’ll

be querying for. If there is any chance that you won’t know exactly what you’re querying

for, use an array. Arrays should usually be used when you know some criteria about

the element you’re querying for.

 

 

 

Suppose we are programming a game where the player picks up various items. We

might model the player document as:

 

 

{ "_id" : "fred", "items" : { "slingshot" : { "type" : "weapon", "damage" : 23, "ranged" : true }, "jar" : { "type" : "container", "contains" : "fairy" }, "sword" : { "type" : "weapon", "damage" : 50, "ranged" : false } } } 

 

 

Now, suppose we want to find all weapons where damage is greater than 20. We can’t!

Subdocuments do not allow you to reach into items and say, “Give me any item with

damage greater than 20.” You can only ask for specific items: “Is items.slingshot.dam

age greater than 20? How about items.sword.damage?” and so on.

If you want to be able to access any item without knowing its identifier, you should

arrange your schema to store items in an array:

 

 

{ "_id" : "fred", "items" : [ { "id" : "slingshot", "type" : "weapon", "damage" : 23, "ranged" : true }, { "id" : "jar", "type" : "container", "contains" : "fairy" }, { "id" : "sword", "type" : "weapon", "damage" : 50, "ranged" : false } ] } 

 

 

Now you can use a simple query such as {"items.damage" : {"$gt" : 20}}. If you need

more than one criteria of a given item matched (say, damage and ranged), you can use

$elemMatch.

So, when should you use a subdocument instead of an array? When you know and will

always know the name of the field that you are accessing.

For example, suppose we keep track of a player’s abilities: her strength, intelligence,

wisdom, dexterity, constitution, and charisma. We will always know which specific

ability we are looking for, so we could store this as:

 

 

{ "_id" : "fred", "race" : "gnome", "class" : "illusionist", "abilities" : { "str" : 20, "int" : 12, "wis" : 18, "dex" : 24, "con" : 23, "cha" : 22 } } 

 

When we want to find a specific skill, we can look up abilities.str, or abili

ties.con, or whatever. We’ll never want to find some ability that’s greater than 20,

we’ll always know what we’re looking for.