MongoDB 1.4 Ready for Production

MongoDB
March 25, 2010
#Releases

The MongoDB team is very excited to announce the release of MongoDB 1.4.0.  This is the culmination of 3 months of work in the 1.3 branch and has a large number of very important changes.

Many users have been running 1.3 in production, so this release is already very thoroghly vetted both by our regressions systems and by real users.

Some highlights:

Core server enhancements

Replication & Sharding

  • better handling for restarting slaves offline for a while
  • fast new slaves from snapshots
  • configurable slave delay
  • replication handles clock skew on master
  • $inc replication fixes
  • sharding alpha 3 - notably 2 phase commit on config servers

Deployment & production

  • configure “slow” for profiling
  • ability to do fsync + lock for backing up raw files
  • option for separate directory per db
  • http://localhost:28017/_status to get serverStatus via http
  • REST interface is off by default for security (–rest to enable)
  • can rotate logs with a db command, logRotate
  • enhancements to serverStatus - counters/replication lag
  • new mongostat tool and db.serverStatus() enhancements

Query language improvements

Geo

Downloads: www.mongodb.org/display/DOCS/Downloads

Full Change Log: jira

Release Notes: http://www.mongodb.org/display/DOCS/1.4+Release+Notes

Thanks for all your continued support, and we hope MongoDB 1.4 works great for you.

As always, please let us know of any issues,

-Eliot and the MongoDB Team

← Previous

"Partial Object Updates" will be an Important NoSQL Feature

It’s nice that in SQL we can do things like UPDATE PERSONS SET X = X + 1 We term this a “partial object update”: we updated the value of X without sending a full row update to the server. Seems like a very simple thing to be discussing, yet some nosql solutions do not support this (others do). In these new datastores, the average stored object size (whether it be a document, a key/value blob, or a row) tends to be larger than the traditional database row. The data is not fully normalized, so we are packing more data into a single storage object than before. This means the cost of full updates is higher. If we have a 100KB document and want to set a single value within it, passing the full 100KB in both directions over the network for the operation is expensive. MongoDB supports partial updates in its update operation via a set of special $ operators: $inc, $set, $push, etc. More of these operators will be added in the future. There are further benefits to the technique too. First, we get easy (single document) atomicity for these operations (consider $inc). Second, replication is made cheaper: when a partial update occurs, MongoDB replicates the partial update rather than the full object changed. This makes replication much less expensive and network intensive.

December 30, 2009
Next →

Node.js and MongoDB

Visit the more recent post, Getting Started with VMware Cloud Foundry, MongoDB, and Node.js. Listen to the recorded Node.js Panel Discussion webinar. Node.js is turning out to be a framework of choice for building real-time applications of all kinds, from analytics systems to chat servers to location-based tracking services. If you’re still new to Node, check out Simon Willison’s excellent introductory post. If you’re already using Node, you probably need a database, and you just might have considered using MongoDB. The rationale is certainly there. Working with Node’s JavaScript means that MongoDB documents get their most natural representation – as JSON – right in the application layer. There’s also significant continuity between your application and the MongoDB shell, since the shell is essentially a JavaScript interpreter, so you don’t have to change languages when moving from application to database. Node.js MongodB Driver Especially impressive to us at 10gen has been the community support for Node.js and MongoDB. First, there’s Christian Kvalheim’s excellent mongodb-node-native project, a non-blocking MongoDB driver implemented entirely in JavaScript using Node.js’s system libraries. The project is a pretty close port of the MongoDB Ruby driver, making for an easy transition for those already used to the 10gen-supported drivers. If you’re just starting, there’s a helpful mongodb-node-native mailing list. Hummingbird Need a real-world example? Check out Hummingbird, Michael Nutt’s real-time analytics app. It’s built on top of MongoDB using Node.js and the mongodb-node-native driver. Hummingbird, which is used in production at Gilt Groupe, brings together an impressive array of technologies; it uses the express.js Node.js app framework and sports a responsive interface with the help of web sockets. Definitely worth checking out. Mongoose Of course, one of the admitted difficulties in working with Node.js is dealing with deep callback structures. If this poses a problem, or if you happen to want a richer data modeling library, then Mongoose is the answer. Created by Learnboost, Mongoose sits atop mongodb-node-native, providing a nice API for modeling your application. Node Knockout All of this just to show that the MongoDB/Node.js ecosystem thrives. If you need a good excuse to jump into Node.js or MongoDB development, be sure to check out next month's Node Knockout. It’s a weekend app competition for teams up to four, and registration is now open.

July 14, 2010