5 ms·

http://www.mongodb.org/display/DOCS/Atomic+Operations http://www.mongodb.org/display/DOCS/Atomic+Operations says: "MongoDB supports atomic operations on single

http://www.mongodb.org/display/DOCS/Atomic+Operations 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"?

robotadam 16y ago
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.
- ethangunderson 16y ago
  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.
rb2k_ 16y ago
basically what robotadam said (http://news.ycombinator.com/item?id=1579212 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
- masomenos 16y ago
  Interesting! Did not know that. Any idea how replica sets / shards might fit into this picture?
  - rb2k_ 16y ago
    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...
- mjs 16y ago
  This is also pertinent: http://www.mongodb.org/display/DOCS/How+does+concurrency+work 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_ 16y ago
    Unless you actually don't have enough RAM and that data structure has to be paged in... that's a painfully long wait

robotadam 16y ago

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.

ethangunderson 16y ago
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.

rb2k_ 16y ago

basically what robotadam said (http://news.ycombinator.com/item?id=1579212 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

masomenos 16y ago
Interesting! Did not know that. Any idea how replica sets / shards might fit into this picture?
- rb2k_ 16y ago
  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...
mjs 16y ago
This is also pertinent: http://www.mongodb.org/display/DOCS/How+does+concurrency+work 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_ 16y ago
  Unless you actually don't have enough RAM and that data structure has to be paged in... that's a painfully long wait