There is definitely a global write lock. It doesn't impact performance much because MongoDB doesn't force a write to disk when you write (unless you specifically ask for it).
You wind up with a bunch of threads trading an in-memory lock in order to write to a memory-mapped file. That's why it seems so fast. MongoDB leaves it up to the OS to flush out the file to disk periodically. What about reliability you say? Well just require that your write is committed to more than one MongoDB server and you *should* be ok as long as no one pulls the plug on your whole cluster at once. The 10gen folks have been trying to get more fine-grained locking in there for a while. My guess adding more locks slows the processing down quite a bit. Anyone remember GIL-less python? > 100% slower Erik On Wed, Jun 6, 2012 at 12:50 PM, Thomas Amsler <[email protected]> wrote: > MongoDB FAQ : How does MongoDB provide concurrency > http://docs.mongodb.org/manual/faq/developers/#how-does-mongodb-provide-concurrency > > 10gen folks are working hard on improving the locking process to > provide collection or even document level locking in future versions. > This was discussed quite a bit at the MongoSF conference a couple > weeks ago. > > > Best, > -- Thomas > > On Wed, Jun 6, 2012 at 9:01 AM, Chris Tweney <[email protected]> wrote: >> (This thread originated on oae-core, but is really meant for oae-dev.) >> >> If Mongo really has a global write lock [1] then it's got much the same >> problem that caused us to migrate away from Jackrabbit... >> >> Snip: >> >> "Global write lock - MongoDB (as of the current version at the time of >> writing: 2.0), has a process-wide write lock. Conceptually this makes no >> sense. A write on collection X blocks a write on collection Y, despite >> MongoDB having no concept of transactions or join semantics. We reached >> practical limitations of MongoDB when pushing a mere 200 updates per >> second to a single server. At this point, all other operations including >> reads are blocked because of the write lock. When reaching out to 10gen >> for assistance, they recommended we look into sharding, since that is >> their general scaling solution." >> >> [1] http://blog.engineering.kiip.me/post/20988881092/a-year-with-mongodb >> >> -chris >> >> On 6/6/12 8:46 AM, Zach A. Thomas wrote: >>> This link may have circulated already, but it's relevant here: >>> http://blog.engineering.kiip.me/post/20988881092/a-year-with-mongodb >>> >>> There's nothing like cold reality to blunt a fellow's enthusiasm! >>> >>> Zach >>> On Jun 6, 2012, at 10:36 AM, Ray Davis wrote: >>> >>>> I wonder what his team switched to? PostgreSQL is the fallback I've seen >>>> most often. >>>> >>>> Best, >>>> Ray >>>> >>>> On 6/6/12 8:29 AM, Lance Speelmon wrote: >>>>> FYI - might be a useful data point… >>>>> >>>>> http://www.zopyx.com/blog/goodbye-mongodb >>>>> >> _______________________________________________ >> oae-dev mailing list >> [email protected] >> http://collab.sakaiproject.org/mailman/listinfo/oae-dev > _______________________________________________ > oae-dev mailing list > [email protected] > http://collab.sakaiproject.org/mailman/listinfo/oae-dev _______________________________________________ oae-dev mailing list [email protected] http://collab.sakaiproject.org/mailman/listinfo/oae-dev
