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

51–60 of 64 posts

Re: MongoDB 2.2.0 Released

#51

Post by _jmar777 »

mathias_10gen wrote: post #31
_jmar777 wrote: post #29

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,…

Out of curiosity, did you have an index on the ts field that you are matching with? By the way, if you (or anyone else for that matter) come up with useful benchmarks I'd love to get a copy of them at mathias@10gen.com. I have a few of my own, but I'd like to get some real-world workloads from the community to test potential optimizations against.

Update: already forwarded this to Mathias, but posting here in case anyone else wanted to see the full benchmark test: https://gist.github.com/3518344

Re: MongoDB 2.2.0 Released

#54

Post by prax2 »

There is one thing holding me back still from mongo or I'd be using it right now instead of Postgres: native decimal support [1].

There are a lot of proposed work arounds, and some surely work fine if you're only dealing with 2 decimal currency.

The solutions don't scale for arbitrary precision based on the field.

The new aggregation framework is a fantastic step forward and from my testing is relatively peppy, even at a 150k document collection.

Side note: Anyone know a nosql solution that doesn't treat decimals as floats?

[1] https://jira.mongodb.org/browse/SERVER-1393

Re: MongoDB 2.2.0 Released

#55

Post by thijsc »

prax2 wrote: post #54

There is one thing holding me back still from mongo or I'd be using it right now instead of Postgres: native decimal support [1]. There are a lot of proposed work arounds, and some surely work fine if you're only dealing with 2 decimal currency. The solutions don't scale for arbitrary precision based on the field. The new aggregation framework is a fantastic step forward and from my testing is relatively peppy, even…

A native decimal datatype would be awesome indeed.

Re: MongoDB 2.2.0 Released

#57

Post by nodesocket »

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…

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.

Re: MongoDB 2.2.0 Released

#58

Post by PommeDeTerre »

DonnyV wrote: post #33
Ricapar wrote: post #16

Still no support for Solaris on SPARC! :(

Isn't that system dead?

I think you'd be quite surprised if you ever found out just how much of the world, including your very own existence, depends heavily on platforms and systems that you consider to be "dead".

Re: MongoDB 2.2.0 Released

#59

Post by Ricapar »

crcsmnky wrote: post #41
Ricapar wrote: post #16

Still no support for Solaris on SPARC! :(

I'm not trolling you when I ask this, I'm simply curious. Of the open source projects you follow, how many still do builds for Solaris? How often do you have to build them yourself?

Legitimate question.

Not many do. There are quite a few things I build myself if I really really want to use it. A lot of the time it isn't worth it.

I would totally be using MongoDB for some projects (it fits the bill -perfectly-), but my resources for those are usually limited to Solaris on SPARC.

I do have an x86 desktop with Linux as my main PC at work, so I don't miss out on all the fun completely.

However, I do mostly sysadmin stuff, so a lot of the things I use come in the form of scripts, so it's often cross-platform.

Though I do come across some install scripts that just blatantly assume that everything is running Bash on Linux. Those are fun.

I have very little expectation that the MongoDB team will ever push a non x86 version. They do a lot of optimisations deep inside that rely on architecture specific things. But one can hope :)

Re: MongoDB 2.2.0 Released

#60

Post by 23david »

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

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.

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.

Post reply on HN