Hacker News Reader

Comment by masomenos | Hacker News Reader

http://www.mongodb.org/display/DOCS/Atomic+Operations says:

"MongoDB supports atomic operations on single documents. MongoDB does not support traditional locking and complex transactions for a number of reasons. . ."

What made you think that it was "locking all databases when a write is occurring"?

View on HN

MongoDB has a single, global read/write lock for the entire database. So when a write is actually processing, nothing else can happen. In a moderately write-heavy environment, a single slow write can result in pretty bad performance in my experience. Reads can happen at the same time, although there have been problems with not yielding the lock on scans, although there are changes in 1.6 to address that.

This used to be the case in earlier versions, but now it only issues a server level write lock for atomic updates, reads can still happen.

It's not ideal, but it is an improvement.

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

Interesting! Did not know that.

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

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

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

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

Reply on news.ycombinator.com