Kyle Banker - MongoDB in Action: Covers MongoDB version 3.0

This chapter covers

MongoDBs history, design goals, and key features

A brief introduction to the shell and drivers

Use cases and limitations

Recent changes in MongoDB

If youve built web applications in recent years, youve probably used a relational database as the primary data store. If youre familiar with SQL, you might appreciate the usefulness of a well-normalized data model, the necessity of transactions, and the assurances provided by a durable storage engine. Simply put, the relational database is mature and well known. So when developers start advocating alternative datastores, questions about the viability and utility of these new technologies arose. Are these new datastores replacements for relational database systems? Whos using them in production, and why? What are the trade-offs involved in moving to a nonrelational database? The answers to those questions rest on the answer to this one: why are developers interested in MongoDB?

MongoDB is a database management system designed for the need to rapidly develop web applications and internet infrastructure. The data model and persistence strategies are built for high read and write throughput and the ability to scale easily with automatic failover. Whether an application requires just one database node or dozens of them, MongoDB can provide surprisingly good performance. If youve experienced difficulties scaling relational databases, this may be great news. But not everyone needs to operate at scale. Maybe all youve ever needed is a single database server. Why then would you use MongoDB?

Perhaps the biggest reason developers use MongoDB isnt because of its scaling strategy, but rather because of its intuitive data model. MongoDB stores its information in documents rather than rows. Whats a document? Heres an example:

This is a pretty simple document; its just storing a few fields of information about a user (he sounds cool). So whats the advantage of this model? Consider the case where youd like to store multiple emails for each user. In the relational world, you might create a separate table of email addresses and the user to which theyre associated. MongoDB gives you another way to store these:

And just like that, youve created an array of email addresses and solved your problem. As a developer, youll find it extremely useful to be able to store a structured document like this in your database without worrying about fitting a schema or adding more tables when your data changes.

MongoDBs document format is based on JSON, a popular scheme for storing arbitrary data structures. JSON is an acronym for JavaScript Object Notation. As you just saw, JSON structures consist of keys and values, and they can nest arbitrarily deep. Theyre analogous to the dictionaries and hash maps of other programming languages.

A document-based data model can represent rich, hierarchical data structures. Its often possible to do without the multitable joins common with relational databases. For example, suppose youre modeling products for an e-commerce site. With a fully normalized relational data model, the information for any one product might be divided among dozens of tables. If you want to get a product representation from the database shell, youll need to write a SQL query full of joins.