David Hows Peter Membrey Eelco Plugge - The definitive guide to MongoDB a complete guide to dealing with big data using MongoDB

The most important of the philosophies that underpin MongoDB is the notion that one size does not fit all . For many years, traditional relational (SQL) databases (MongoDB is a document-oriented database) have been used for storing content of all types. It didnt matter whether the data was a good fit for the relational model (which is used in all RDBMS databases, such as MySQL, PostgresSQL, SQLite, Oracle, MS SQL Server, and so on); the data was stuffed in there, anyway. Part of the reason for this is that, generally speaking, its much easier (and more secure) to read and write to a database than it is to write to a file system. If you pick up any book that teaches PHP, such as PHP for Absolute Beginners , by Jason Lengstorf (Apress, 2009), youll probably find that almost right away the database is used to store information, not the file system. Its just so much easier to do things that way. And while using a database as a storage bin works, developers always have to work against the flow. Its usually obvious when were not using the database the way it was intended; anyone who has ever tried to store information with even slightly complex data, had to set up five tables, and then tried to pull it all together knows what were talking about!

The MongoDB team decided that it wasnt going to create another database that tries to do everything for everyone. Instead, the team wanted to create a database that worked with documents rather than rows and that was blindingly fast, massively scalable, and easy to use. To do this, the team had to leave some features behind, which means that MongoDB is not an ideal candidate for certain situations. For example, its lack of transaction support means that you wouldnt want to use MongoDB to write an accounting application. That said, MongoDB might be perfect for part of the aforementioned application (such as storing complex data). Thats not a problem, though, because there is no reason why you cant use a traditional RDBMS for the accounting components and MongoDB for the document storage. Such hybrid solutions are quite common, and you can see them in production apps such as the New York Times website.

Once youre comfortable with the idea that MongoDB may not solve all your problems, you will discover that there are certain problems that MongoDB is a perfect fit for resolving, such as analytics (think a real-time Google Analytics for your website) and complex data structures (for example, blog posts and comments). If youre still not convinced that MongoDB is a serious database tool, feel free to skip ahead to the Reviewing the Feature List section, where you will find an impressive list of features for MongoDB.

Another key concept behind MongoDBs design is that there should always be more than one copy of the database. If a single database should fail, then it can simply be restored from the other servers. Because MongoDB aims to be as fast as possible, it takes some shortcuts that make it more difficult to recover from a crash. The developers believe that most serious crashes are likely to remove an entire computer from service anyway; this means that even if the database were perfectly restored, it would still not be usable. Remember: MongoDB does not try to be everything to everyone. But for many purposes (such as building a web application), MongoDB can be an awesome tool for implementing your solution.

So now you know where MongoDB is coming from. Its not trying to be the best at everything, and it readily acknowledges that its not for everyone. However, for those who do choose to use it, MongoDB provides a rich document-oriented database thats optimized for speed and scalability. It can also run nearly anywhere you might want to run it. MongoDBs website includes downloads for Linux, Mac OS, Windows, and Solaris.

MongoDB succeeds at all these goals, and this is why using MongoDB (at least for us) is somewhat dream-like. You dont have to worry about squeezing your data into a tablejust put the data together, and then pass it to MongoDB for handling.Consider this real-world example. A recent application co-author Peter Membrey worked on needed to store a set of eBay search results. There could be any number of results (up to 100 of them), and he needed an easy way to associate the results with the users in his database.

Had Peter been using MySQL, he would have had to design a table to store the data, write the code to store his results, and then write more code to piece it all back together again. This is a fairly common scenario and one most developers face on a regular basis. Normally, we just get on with it; however, for this project, he was using MongoDB, and so things went a bit differently.

Specifically, he added this line of code: