Database Reference
In-Depth Information
multiplied by the size of each inserted document to get the amount of extra space to
create beyond the document itself. This may reduce the number of future document
relocations.
To see a given collection's padding factor, run the collection stats command:
db.tweets.stats()
{
"ns" : "twitter.tweets",
"count" : 53641,
"size" : 85794884,
"avgObjSize" : 1599.4273783113663,
"storageSize" : 100375552,
"numExtents" : 12,
"nindexes" : 3,
"lastExtentSize" : 21368832,
"paddingFactor" : 1.2,
"flags" : 0,
"totalIndexSize" : 7946240,
"indexSizes" : {
"_id_" : 2236416,
"user.friends_count_1" : 1564672,
"user.screen_name_1_user.created_at_-1" : 4145152
},
"ok" : 1 }
This collection of tweets has a padding factor of 1.2, which indicates that when a 100-
byte document is inserted, MongoDB will allocate 120 bytes on disk. The default pad-
ding value is 1, which indicates that no extra space will be allocated.
Now, a brief word of warning. The considerations mentioned here apply especially
to deployments where the data size exceeds
RAM
or where an extreme write load is
expected. So, if you're building an analytics system for a high-traffic site, take the
information here with more than a grain of salt.
6.5
Summary
We've covered a lot in this chapter. The variety of updates may at first feel like a lot to
take in, but the power that these updates represent should be reassuring. The fact is
that MongoDB's update language is as sophisticated as its query language. You can
update a simple document as easily as you can a complex, nested structure. When
needed, you can atomically update individual documents and, in combination with
findAndModify
, build transactional workflows.
If you've finished this chapter and feel like you can apply the examples here on
your own, then you're well on your way to becoming a MongoDB guru.
