

MongoDB Architecture - lnmx
http://horicky.blogspot.com/2012/04/mongodb-architecture.html

======
jhaile
Unlike RDBMS's, MongoDB has a single, shared database-wide write lock when you
write to any collection.

~~~
dkhenry
Which they will tell you doesn't matter as their ease of sharding means you
should scale by going to multiple machines not getting one super huge database
server.

Also in practice the limiter is not the global write lock but page faults that
cause the largest performance impacts. [1]

1: <http://blog.pythonisito.com/2011/12/mongodbs-write-lock.html>

~~~
spf13
The write lock does matter. We at 10gen won't say otherwise. A good amount of
work in the current and upcoming releases are adding more granularity to the
write lock. See current progress in jira
<https://jira.mongodb.org/browse/SERVER/component/10055>

That said, as that blog post clearly demonstrates, the write lock is a red
herring in a vast majority of circumstances. In practice it is historically
rarely been an issue and even less so with the yielding improvements in 2.0
(which is what that blog post is about). Typically issues are manifested in
lack of adequate ram, lack of IO and poor schema design.

~~~
dinedal
Can we please have collection level locking so writes to unrelated collections
won't grab the shard's write lock?

~~~
andypants
If you click his link you will see that collection level locking is being
worked on.

------
ndcrandall
This is a great article in that it helps lead into a technology that has the
capabilities of scaling your applications.

I'll be the first to admit that I haven't been as comfortable making the
transition to NoSQL. I've only ever used RDBMS and was taught by a database
professor that would scorn de-normalization, transactionless operations, and
other things that makes NoSQL different.

Hopefully I'll get more comfortable with it as I develop my web application
that will rely heavily on the advantages of NoSQL.

~~~
spf13
It can be a bit dangerous to group all NoSQL databases together as they differ
from each other as much as they do from relational.

In some ways MongoDB sits in between relational databases and other NoSQL
databases. While MongoDB doesn't have SQL transactions, it does have atomic
operations similar to relational databases.

Normalization is an interesting term that really has been defined or redefined
to fit into a relational mindset. Denormalized often implies unstructured
mess, while that could be the case in any database (relational included). It
is certainly not the norm for MongoDB.

In MongoDB a properly designed schema is very structured and 'normalized'. In
truth these schemas don't mirror relation schemas, they could, but it would
ignore beneficial additions the document model provides. It is very easy to
use the same ERD diagram for both relational and MongoDB. What you will find
in both is very structured accessible data. In MongoDB you will find that the
ability to have a given fields value be an array or object permits your schema
to more accurate map to your actual use of the data. The schema will be
simpler as you no longer need things like many to many join tables.

Not to say that MongoDB is better than relational, just different. Sometimes
MongoDB is a better fit, and sometimes relational is a better fit, just
depends on the situation.

