Database Reference
In-Depth Information
WHY NO TRANSACTIONS?
MongoDB was designed from the ground up to be easy to scale to multiple distributed
servers. Two of the biggest problems in distributed database design are distributed join
operations and distributed transactions. Both of these operations are complex to imple-
ment, and can yield poor performance or even downtime in the event that a server becomes
unreachable. By “punting” on these problems and not supporting joins or multidocument
transactions at all, MongoDB has been able to implement an automatic sharding solution
with much better scaling and performance characteristics than you'd normally be stuck
with if you had to take relational joins and transactions into account.
Using this approach, we introduce the possibility that Jenny could be removed from the
con-
tacts
collection buthavehernumbersremaininthe
numbers
collection. There'salsothepos-
sibility that another process reads the database after Jenny's been removed from the
contacts
collection, but before her numbers have been removed. On the other hand, if we use the em-
bedded schema, we can remove Jenny from our database with a single operation:
db
.
contacts
.
remove
({
'_id'
:
3
})
NOTE
One point of interest is that many relational database systems relax the requirement that
transactions be completely isolated from one another, introducing various
isolation levels
.
Thus,ifyoucanstructureyourupdatestobesingle-document updatesonly,youcangetthe
effect of the
serialized
(most conservative) isolation level without any of the performance
hits in a relational database system.
Referencing for Flexibility
In many cases, embedding is the approach that will provide the best performance and data
consistency guarantees. However, in some cases, a more normalized model works better in
MongoDB. One reason you might consider normalizing your data model into multiple collec-
tions is the increased flexibility this gives you in performing queries.
For instance, suppose we have a blogging application that contains posts and comments. One
approach would be to use an embedded schema:
