MongoDB 0.9.9 Released | Hacker News Reader

MongoDB 0.9.9 Released

blog.mongodb.org

32 pointsmcxx22 comments

Is anyone here using/considering MongoDB? I'm want to try it out on a new project I'm starting, a real-time web analytics app. Should be fun.

I strongly considered using MongoDB for an internal project at work. I eschewed it for my project though. I simply didn't have time to fully investigate it.

I looked at using John Nunemaker's MongoMapper library to integrate MongoDB into my application (see http://github.com/jnunemaker/mongomapper/tree/master). It looks great!

I am getting ready to use it for a very similar purpose, the ability to quickly increment a counter seems to make it perfect for this kind of use case.

I built a simple Twitter client on my laptop against MongoDB - persistently storing every tweet from everyone I follow. I found it to be stable, flexible, quick to build with and extremely high performance - but I'll probably move the app over to MySQL or PostgreSQL simply because I want to do queries with joins in them!

We forked our app to give it a try. It's definitely an interesting contender, but in our case, we didn't see any significant performance gains and so it wasn't worth moving away from MySQL. It did help us simplify our MySQL schema a lot though and i wouldn't be surprised if we revisit it when it hits v1. For someone getting started with it, the google group is quite useful [http://groups.google.com/group/mongodb-user] and the project team was pretty responsive.

I am using it to store binary data (images) instead of regular DB, it looks pretty fast so far!

Just started using it 2 weeks ago after a month of reviewing various options. So far its been great. Currently, I'm writing a lightweight wrapper util for models in ruby. There is mongomapper, but its an ActiveRecord-like thing and I really want something much simpler.

My current concerns are with tiny little nits in the API. But these are minor and there seems to be a way to do everything I need.

I am currently using it in production; I love it. Highly recommended.

I'm using it in production for a large bayesian filter. Amongst other things. Works great.

SourceForge are using it heavily in production: http://compoundthinking.com/blog/index.php/2009/07/16/turbog...

We are using it for our server monitoring application with a database size currently around 150GB. We migrated from MySQL and wrote up the details at http://blog.boxedice.com/2009/07/25/choosing-a-non-relationa...

I read that. How is the master-master replication working for you? Also, why didn't you rather do shrading and replication considering m-m replication is experimental?

The only replication we're doing is master-slave which works extremely well. The slave comes back in sync after about 10 hours and then stays up to date.

The replication pairs are very interesting as it allows automated failover. WIthin your code you specify a list of the servers and it will automatically set one as the master. If that fails then the others will negotiate which one will become the master and take over without any need to change your code.

Sharding is experimental and isn't documented or recommended for use at the moment so I can't comment on that.

We're also using the commercial support option to guarantee us 24/7 response if something goes wrong and to get bug fixes quickly, which we have used once so far.

I'm building a bug tracker with MongoDB at the moment. Nothing but good things to say. First incarnation I used CouchDB but found the whole 'must know your queries before-hand' stuff didn't really fit the project. MongoDB is blazing fast with custom (runtime) queries.

antirez (the author of Redis) says good things about MongoDB, but like him, I found Redis suits my needs better (as a high-performance log server; 60k writes per second, trivial replication, etc.)

The problem with Redis is its insane memory consumption. Memory space taken by data is inflated over an order of magnitude compared to its "natural" size on-disk. I'm not sure if this is inherent or is something that can be fixed (eg with some sort of compression) but it makes the DB pretty much unusable for me at the moment. Pity because I really like it!

I second that.

I'm hoping this will be a valid replacement for Berkeley DB - the 1.86 version I'm using is free (and old), but fails on >2GB databases.

You need a 64-bit OS to get >2GB db's with Mongo, just fyi.

That's silly - I can ftell_i64 on this 32-bit machine, so it's not the OS, it's them not coding in the 64-bit file access APIs that are available, at least in Windows XP.

MongoDB database files are memory mapped, it has something to do with that... Never looked into it closer, all my servers are running 64-bit distros.

Also of note: they released a winx64 distributable in the past couple weeks. Previously only linux and mac had 64 bit distributables.

Reply on news.ycombinator.com