[rb2k_]

basically what robotadam said (http://news.ycombinator.com/item?id=1579212). To clarify: the database lock is actually for the whole process (-> all databases). I had an especially bad experience with it before they introduced the yielding for long running operations. But even with the yielding, write heavy parallel things still suffer. Especially if your indexes ever get too big and the the system decides to swap in/out part of the index. I've seen 5-6 second inserts with hundreds of writes and reads piling up in the mean time (even without the swap part).

If only they had an equivalent of innodb as a storage engine, it would be awesome

[mjs]

This is also pertinent:

http://www.mongodb.org/display/DOCS/How+does+concurrency+wor...

Note that whilst a write blocks all other writes, the time you need to wait is the time it takes for the in-memory data structure to be modified; you don't have to wait for the write to hit disk. (Writes are only persisted to disk every so often.)

[rb2k_]

Unless you actually don't have enough RAM and that data structure has to be paged in... that's a painfully long wait

[masomenos]

Interesting! Did not know that.

Any idea how replica sets / shards might fit into this picture?

[rb2k_]

It would help keeping the index size down (well... distribute it at least) and a lock on a shard will not influence the other shards. I asked a few months back if I could just run several shards on a single machine and keep the locked area smaller that way, but the general consensus was that it wasn't a good idea because of the overhead. Other than that, the lock is still there...