Hacker News Reader

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

View on HN

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.

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

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

The lock matters, as anyone can tell you who ever tried to perform a bulk-update on a production mongo.

Is that with your entire working data set loaded in memory?

Reply on news.ycombinator.com