Database Reference
In-Depth Information
The MongoDB team decided that it wasn't 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 wouldn't 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). That's not a problem, though,
because there is no reason why you can't 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 you're 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 you're 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.
■
the lack of transactions and other traditional database features doesn't mean that MongodB is unstable or
that it cannot be used for managing important data.
Note
Another key concept behind MongoDB's 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. It's not trying to be the best at everything, and it readily
acknowledges that it's not for everyone. However, for those who do choose to use it, MongoDB provides a rich
document-oriented database that's optimized for speed and scalability. It can also run nearly anywhere you might
want to run it. MongoDB's 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 don't have to worry about squeezing your data into a table—just 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:
request['ebay_results'] = ebay_results_array
collection.save(request)
In this example,
request
is Peter's document,
ebay_results
is the key, and
ebay_result_array
contains the
results from eBay. The second line saves the changes. When he accesses this document in the future, he will have
the eBay results in exactly the same format as before. He doesn't need any SQL; he doesn't need to perform any
conversions; nor does he need to create any new tables or write any special code—MongoDB just worked. It got out
of the way, he finished his work early, and he got to go home on time.
