Database Reference
In-Depth Information
1.2.5
Speed and durability
To u n d e r s t a n d M o n g o D B 's a p p r o a c h t o d u r a b i l i t y, i t p a y s t o c o n s i d e r a f e w i d e a s f i r s t .
In the realm of database systems there exists an inverse relationship between write
speed and durability.
Write speed
can be understood as the volume of inserts, updates,
and deletes that a database can process in a given time frame.
Durability
refers to level
of assurance that these write operations have been made permanent.
For instance, suppose you write 100 records of 50
KB
each to a database and then
immediately cut the power on the server. Will those records be recoverable when you
bring the machine back online? The answer is, maybe, and it depends on both your
database system and the hardware hosting it. The problem is that writing to a magnetic
hard drive is orders of magnitude slower than writing to
RAM
. Certain databases, such
as memcached, write exclusively to
RAM
, which makes them extremely fast but com-
pletely volatile. On the other hand, few databases write exclusively to disk because the
low performance of such an operation is unacceptable. Therefore, database designers
often need to make compromises to provide the best balance of speed and durability.
In MongoDB's case, users control the speed and durability trade-off by choosing
write semantics and deciding whether to enable journaling. All writes, by default, are
fire-and-forget
, which means that these writes are sent across a
TCP
socket without
requiring a database response. If users want a response, they can issue a write using a
special
safe mode
provided by all drivers. This forces a response, ensuring that the write
has been received by the server with no errors. Safe mode is configurable; it can also
be used to block until a write has been replicated to some number of servers. For
high-volume, low-value data (like clickstreams and logs), fire-and-forget-style writes
can be ideal. For important data, a safe-mode setting is preferable.
In MongoDB v2.0, journaling is enabled by default. With journaling, every write is
committed to an append-only log. If the server is ever shut down uncleanly (say, in a
power outage), the journal will be used to ensure that MongoDB's data files are restored
to a consistent state when you restart the server. This is the safest way to run MongoDB.
Transaction logging
One compromise between speed and durability can be seen in MySQL's InnoDB.
InnoDB is a transactional storage engine, which by definition must guarantee
durability. It accomplishes this by writing its updates in two places: once to a
transaction log and again to an in-memory buffer pool. The transaction log is
synced to disk immediately, whereas the buffer pool is only eventually synced by
a background thread. The reason for this dual write is because, generally speak-
ing, random
I/O is
much slower that sequentia
l I/O.
Since writes to the main data
files constitute rando
m I/O, it'
s faster to write these changes t
o RAM
first, allow-
ing the sync to disk to happen later. But since some sort of write to disk is nec-
essary to guarantee durability, it's important that the write be sequential; this is
what the transaction log provides. In the event of an unclean shutdown, InnoDB
can replay its transaction log and update the main data files accordingly. This
provides an acceptable level of performance while guaranteeing a high level of
durability.
