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

31–40 of 64 posts

Re: MongoDB 2.2.0 Released

#31

Post by mathias_10gen »

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

Re: MongoDB 2.2.0 Released

#32

Post by encoderer »

eranation wrote: post #8

The Aggregation Framework is a great feature, already in production...

This does look cool. Aggregation previously was a joke with its collection size limitation.

I haven't used Mongo in a year. Are Map Reduce jobs still single threaded?

Re: MongoDB 2.2.0 Released

#34

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.

Yes, I had a single index:

  db.events.ensureIndex({ ts: 1 });
I'll try to clean up my benchmark code a little, throw it in a gist, and then I'll send it your way.

Re: MongoDB 2.2.0 Released

#36

Post by cheap »

cmer wrote: post #12
lusr wrote: post #10

Earlier quoted context omitted.

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.

Support? Pretending something isn't an issue? Must be entirely unique to this technology company alone.

Re: MongoDB 2.2.0 Released

#37

Post by rgnitz »

efbenson wrote: post #27

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.

With MongoDB, you are able to shard your system. This means you can grow your databases horizontally. This is not something you can easily (or cheaply) do in the world of RDBMS. You will see much better scalability with MongoDB than with something like MySQL.

Re: MongoDB 2.2.0 Released

#38

Post by rogerbinns »

efbenson wrote: post #27

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.

> However I always feared in the back of my head we would have to move off of it if our service got too big

I like to call that "nice problem to have" territory. There is nothing to fear from being too successful, or from having the problems of success. Success problems can be solved by the application of people, time and money. And like all optimization you measure first to make sure you really have the problems you think you do, Amdahl's law etc.

Far more likely you'll have the problems of not being successful, such as no attention or money from customers and investors. Or not being in the business you think you are in. There isn't really that much point putting in infrastructure just in case you get successful, if that same infrastructure takes time to develop, and slows development.

I'd be delighted having a service "too big" for MongoDB! After all it would mean being more successful than the companies listed at http://www.mongodb.org/display/DOCS/Production+Deployments

Re: MongoDB 2.2.0 Released

#40

Post by rademi »

rgnitz wrote: post #37
efbenson wrote: post #27

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.

With MongoDB, you are able to shard your system. This means you can grow your databases horizontally. This is not something you can easily (or cheaply) do in the world of RDBMS. You will see much better scalability with MongoDB than with something like MySQL.

You can shard RDBMS relatively easily -- basically you wind up pushing a part of your database structure into your clients, so your clients can decide which shard to use.

The cost, though, is that you wind up having a difficult time doing some things that MongoDB can't do. (For example: Renormalizing your database... Does that even mean anything for MongoDB?)

There's something to be said, of course, for simplifying your design. But it's probably a good idea also to make sure your design reflects your requirements.

Post reply on HN