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]
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.
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.
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.
