Database Reference
In-Depth Information
The same can be applied to any multi-update. This forces the entire multi-update to
complete in isolation:
db.reviews.update({$atomic: true}, {$set: {rating: 0}}, false, true)
This update sets each review's rating to 0. Because the operation happens in isolation,
the operation will never yield, ensuring a consistent view of the system at all times.
10
6.4.6
Update performance notes
Experience shows that having a basic mental model of how updates affect a document
on disk helps users design systems with better performance. The first thing you should
understand is the degree to which an update can be said to happen “in-place.” Ideally,
an update will affect the smallest portion of a
BSON
document on disk, as this leads to
the greatest efficiency. But this isn't always what happens. Here, I'll explain how this
can be so.
There are essentially three kinds of updates to a document on disk. The first, and
most efficient, takes place when only a single value is updated and the size of the over-
all
BSON
document doesn't change. This most commonly happens with the
$inc
operator. Because
$inc
is only incrementing an integer, the size of that value on disk
won't change. If the integer represents an
int
it'll always take up four bytes on disk;
long integers and doubles will require eight bytes. But altering the values of these
numbers doesn't require any more space and, therefore, only that one value within
the document must be rewritten on disk.
The second kind of update changes the size or structure of a document. A
BSON
document is literally represented as a byte array, and the first four bytes of the docu-
ment always store the document's size. Thus, if you use the
$push
operator on a docu-
ment, you're both increasing the overall document's size and changing its structure.
This requires that the entire document be rewritten on disk. This isn't going to be hor-
ribly inefficient, but it's worth keeping in mind. If multiple update operators are
applied in the same update, then the document must be rewritten once for each oper-
ator. Again, this usually isn't a problem, especially if writes are taking place in
RAM
. But
if you have extremely large documents, say around 4
MB
, and you're
$push
ing values
onto arrays in those documents, then that's potentially lot of work on the server side.
11
The final kind of update is a consequence of rewriting a document. If a document
is enlarged and can no longer fit in its allocated space on disk, then not only does it
need to be rewritten, but it must also be moved to a new space. This moving operation
can be potentially expensive if it occurs often. MongoDB attempts to mitigate this by
dynamically adjusting a padding factor on a per-collection basis. This means that if,
within a given collection, lots of updates are taking place that require documents to
be relocated, then the internal padding factor will be increased. The padding factor is
10
Note that if an operation using
$atomic
fails halfway through, there's no implicit rollback. Half the docu-
ments will have been updated while the other half will still have their original value.
11
It should go without saying that if you intend to do a lot of updates, it's best to keep your documents small.
