Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

MongoDB 2.2.0 Released

mongodb.org

Post reply on HN
Print view View original

11–20 of 64 posts

Re: MongoDB 2.2.0 Released

#12

Post by cmer »

lusr wrote: post #10
cmer wrote: post #5

My experience with MongoDB hasn't been the most pleasant in a write-heavy environment. Until they fix the write lock properly, MongoDB is pretty much useless for many high throughput applications in my opinion... The new DB level locking introduced in this release is a joke. There's not much difference between that and the old global write lock unless you split your database in dozens of smaller ones. What a pain. I…

DB Level Locking ( https://jira.mongodb.org/browse/SERVER-4328 ) is a dependency of Collection Level Locking ( https://jira.mongodb.org/browse/SERVER-1240 ). For a critical, tricky core piece of functionality like this it makes sense to tackle one major concurrency issue at a time, do a release, stabilise the code and verify there are no issues introduced by the new locking code and only then release the next step in…

They were certainly pretending like it wasn't an issue when I contacted their support some time ago.

Re: MongoDB 2.2.0 Released

#13

Post by itmag »

cmer wrote: post #5

My experience with MongoDB hasn't been the most pleasant in a write-heavy environment. Until they fix the write lock properly, MongoDB is pretty much useless for many high throughput applications in my opinion... The new DB level locking introduced in this release is a joke. There's not much difference between that and the old global write lock unless you split your database in dozens of smaller ones. What a pain. I…

I have used Mongodb a bit, but only for applications that mostly need to read a lot. What issues might I run into if I need to do lot of writing as well?

Re: MongoDB 2.2.0 Released

#14

Post by dmytton »

cmer wrote: post #9
dmytton wrote: post #7

Earlier quoted context omitted.

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/go…

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.

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.

Re: MongoDB 2.2.0 Released

#20

Post by comerford »

taterbase wrote: post #18

Does anyone know if Collection level locking is in the pipeline?

It is, it's next in fact, but it was decided to make sure DB level locking worked first (and gets the bugs shaken out of it) before moving on to the next level of locking. Dwight gives a decent description of the thinking in this presentation:

http://www.10gen.com/presentations/concurrency-internals-mon...

Post reply on HN