4 ms·

It's inaccurate that there's no difference between the global lock and database level locking. Whilst it's true that locking is now down at the database level a

by dmytton 14y ago

It's inaccurate that there's no difference between the global lock and database level locking. Whilst it's true that locking is now down at the database level and you get benefits from splitting into multiple databases, the real benefit is from the new PageFaultException architecture. Even using a single database you will see significant performance improvements. I benchmarked this at http://blog.serverdensity.com/goodbye-global-lock-mongodb-2-0-vs-2-2/ http://blog.serverdensity.com/goodbye-global-lock-mongodb-2-... and there is a video explaining how this works at http://www.10gen.com/presentations/concurrency-internals-mongodb-2-2 http://www.10gen.com/presentations/concurrency-internals-mon...

cmer 14y ago
That's good to know. It still feels like an half-assed solution to a very serious problem, however. I definitely won't be looking at MongoDB again until this is fixed for good, and until I know replication is more reliable. Had terrible problems that that too unfortunately.
- dmytton 14y ago
  It might "feel" like a bad solution not granular enough but if you actually test the implementation then locking is no longer a real concern. There are still improvements to be made and this is the first step towards that. Changing from a global to database lock required huge amounts of work which sets the foundations for the next releases with collection and document level locking. In my experience replication has been extremely stable and reliable for several point releases so I'm not sure what problems you had.
- tommoor 14y ago
  It's not half-assed so much as a first step. 10gen have previously stated that the plan is to gradually increase the granularity or write-locks over successive releases.
  - eckyptang 14y ago
    Until they end up with MVCC...
    - mh- 14y ago
      aggregation and then MVCC.. the circle is complete.
jiryu 14y ago
One of the reasons DB-level locking is actually quite important is that the replication oplog is on the 'local' database and your data is on other databases -- so your application is no longer fighting with replication for the write lock.
nodesocket 14y ago
David knows what he is talking about, they use MongoDB in really high scale. Also, getting database level locking was like 90% of the work according to the CEO. Doing collection and finally document level locking should be somewhat trivial now. 10Gen just want's to take it slow, and make sure database level locking is working 100% correct before moving onto more granular locking.
- 23david 14y ago
  Yep they sure are taking it nice and slow... at this pace, collection-level locking is probably only 2 more years away. Other nosql databases are nipping at their heels. David may use MongoDB at really high scale, but since when is that a reason to call someone an expert.
  - rgnitz 14y ago
    Moving fast and breaking things in the database world is not a good thing. That said... I highly doubt collection level locking will take too long. I don't see anyone nipping at their heels. They have some competition in the key/value space, but there are a few different KV paradigms. MongoDB is a complete replacement for most RDBMS apps and they are way ahead of the pack.

by dmytton 14y ago

cmer 14y ago

That's good to know. It still feels like an half-assed solution to a very serious problem, however. I definitely won't be looking at MongoDB again until this is fixed for good, and until I know replication is more reliable. Had terrible problems that that too unfortunately.

dmytton 14y ago
It might "feel" like a bad solution not granular enough but if you actually test the implementation then locking is no longer a real concern. There are still improvements to be made and this is the first step towards that. Changing from a global to database lock required huge amounts of work which sets the foundations for the next releases with collection and document level locking. In my experience replication has been extremely stable and reliable for several point releases so I'm not sure what problems you had.
tommoor 14y ago
It's not half-assed so much as a first step. 10gen have previously stated that the plan is to gradually increase the granularity or write-locks over successive releases.
- eckyptang 14y ago
  Until they end up with MVCC...
  - mh- 14y ago
    aggregation and then MVCC.. the circle is complete.

jiryu 14y ago

One of the reasons DB-level locking is actually quite important is that the replication oplog is on the 'local' database and your data is on other databases -- so your application is no longer fighting with replication for the write lock.

nodesocket 14y ago

David knows what he is talking about, they use MongoDB in really high scale. Also, getting database level locking was like 90% of the work according to the CEO. Doing collection and finally document level locking should be somewhat trivial now. 10Gen just want's to take it slow, and make sure database level locking is working 100% correct before moving onto more granular locking.

23david 14y ago
Yep they sure are taking it nice and slow... at this pace, collection-level locking is probably only 2 more years away. Other nosql databases are nipping at their heels. David may use MongoDB at really high scale, but since when is that a reason to call someone an expert.
- rgnitz 14y ago
  Moving fast and breaking things in the database world is not a good thing. That said... I highly doubt collection level locking will take too long. I don't see anyone nipping at their heels. They have some competition in the key/value space, but there are a few different KV paradigms. MongoDB is a complete replacement for most RDBMS apps and they are way ahead of the pack.