We begin our journey by getting to know the basic mechanics of working with MongoDB. Obviously this is core to
understanding MongoDB, but it should also help us answer higher-level questions about where MongoDB fits.
To get started, there are six simple concepts we need to understand.
1. MongoDB has the same concept of a database with which you are likely already familiar (or a schema for you
Oracle folks). Within a MongoDB instance you can have zero or more databases, each acting as high-level containers for everything else.
2. A database can have zero or more collections. A collection shares enough in common with a traditional table that you can safely think of the two as the same thing.
3. Collections are made up of zero or more documents. Again, a document can safely be thought of as a row.
4. A document is made up of one or more fields, which you can probably guess are a lot like columns.
5. Indexes in MongoDB function mostly like their RDBMS counterparts.
6. Cursors are different than the other five concepts but they are important enough, and often overlooked, and are worthy of their own discussion. The important thing to understand about cursors is that when you ask MongoDB for data, it returns a pointer to the result set called a cursor, which we can do things to, such
as counting or skipping ahead, before actually pulling down data.
To recap, MongoDB is made up of databases which contain collections.
A collection is made up of documents. Each document is made up of fields. Collections can be indexed, which improves lookup and sorting performance. Finally, when we get data from MongoDB we do so through a cursor whose actual execution is delayed until necessary.
Why use new terminology
Is it just that we are making things more complicated by calling table as collection, row as document and column as field? The truth is that while these concepts are similar to their relational database counterparts, they are not
identical. The core difference comes from the fact that relational databases define columns at the table level whereas
a document-oriented database defines its fields at the document level. That is to say that each document within a
collection can have its own unique set of fields. As such, a collection is a dumbed down container in comparison
to a table, while a document has a lot more information than a row.
Although this is important to understand, don’t worry if things aren’t yet clear. It won’t take more than a couple of
inserts to see what this truly means. Ultimately, the point is that a collection isn’t strict about what goes in it (it’s
schema-less). Fields are tracked with each individual document.
If you find this interesting continue reading the free ebook from Karl Seguin’s The Little MongoDB Book
If you are still reading this, here are some bonus points from quora
- MongoDB is really just a twist on a typical SQL database.
- You lose joins but you reduce queries with nested objects and make sharding easier to accomplish.
- You lose easy aggregation in exchange for easier horizontally scalable aggregation.
- You lose the ability to do certain queries in exchange for the ability to do other queries very fast.
- You lose a certain amount of durability in exchange for really fast writes.