这些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:
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:
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:
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:
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:
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:
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:
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.