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

21–30 of 64 posts

Re: MongoDB 2.2.0 Released

#23

Post by dkhenry »

In all this talk of locking were missing the real benefit to a heavy write environment, better yielding. this is going to be huge for those one off writes that in the past would have held the lock. Also I am looking forwards to playing with the new aggregation framework.

Re: MongoDB 2.2.0 Released

#24

Post by jiryu »

dmytton wrote: post #7
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…

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…

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.

Re: MongoDB 2.2.0 Released

#25

Post by jiryu »

itmag wrote: post #13
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?

None, almost certainly -- if you have enough RAM to fit your working data set, then MongoDB's writes are just changing memory. If it does need to read data from disk before changing it, the new yielding architecture that others have mentioned will help prevent lock contention.

Re: MongoDB 2.2.0 Released

#27

Post by efbenson »

For startup projects I love Mongo because we can get a product up and running very quickly. However I always feared in the back of my head we would have to move off of it if our service got too big. Maybe it is all the complaints from a small portion of heavy users. Regardless, big updates like this are going a long way to help make me feel content on continuing to use it as we grow.

Re: MongoDB 2.2.0 Released

#28

Post by tommoor »

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

Re: MongoDB 2.2.0 Released

#29

Post by _jmar777 »

I've been playing around with the Aggregation Framework lately (using the release candidate). The performance seems to be pretty reasonable, especially when compared to similar tasks with the old MR framework. A quick and dirty benchmark number in case anyone is interested:

* Obligatory unscientific, probably not meaningful, etc. disclaimer.

Mongo Version: 2.2.0-rc1

Hardware: MBP, Snow Leapord, 2.2 GHz Intel Core i7, 8 GB mem

Data: Single collection with 500k records (machine generated time-series event data)

Query Pipeline:

  [
      {
          $match: { ts: { $gte: 1293858000000, $lt: 1296536400000 } }
      },
      {
          $group: {
              _id: 'aggregations',
              sum: { $sum: '$foo' },
              num: { $sum: 1 },
              avg: { $avg: '$bar' }
          }
      }
  ]
Results: The time range matched against above matches 42,466 documents within the collection. The average response time over 50 runs is 419ms. Not exactly "Big Data OLAP" stuff just yet, but plenty fast enough for most use cases involving reasonably small sets of data. Great job to the MongoDB team!
Post reply on HN