MongoDB, The Complete Guide [Part 1]
This is part 1 to the complete guide for MongoDB course. Course? Yes, you heard it right I am going to write the complete guide so that you will know everything about MongoDB and why they are the best in the world. So I have put down everything I know about MongoDB in parts so just go with the flow and enjoy the show.
First of all, you should know what is NoSQL Database and their types. Then we will jump to MongoDB.
NoSQL Databases
The term NoSQL originated as a Twitter hashtag for a meet-up back in 2009. It is sometimes translated as an acronym for Not Only SQL, or short-hand for No SQL.
This term is pretty loose and is used to cover a wide range of databases that try to tackle problems that relational databases have with newer applications. These include:
- Flexibility
- Scalability
- Performance
Nevertheless, in order to do so, these databases have sacrificed some of the good things that relational databases provided, such as:
- Expressive query language
- Secondary indexes
- Transactional mechanisms
- Strong consistency
Here are some examples of NoSQL databases:
Common NoSQL Characteristics
NoSQL databases have these common characteristics:
- They usually don’t use SQL. However, they do have their own querying languages which are often similar to SQL since SQL is easy to learn. For example, Cassandra’s querying language is called CQL, or Couchbase’s N1QL, and actually extends SQL for JSON.
- They are not relational databases; meaning that they don’t provide a set of formally described tables in which data should fit. Essentially, relational databases are named as they are because they are structured around tables and relations between those tables. NoSQL databases don’t have tables (at least not in the way that relational databases do) and, therefore, no relations.
- Most of them are cluster-friendly. The initial idea was to store databases on multiple machines; but, some NoSQL databases are Graph oriented just like many applications today (e.g. online social networks where people are nodes, who are connected to other nodes, with edges in a friendship, relationship, etc.).
- They don’t enforce a fixed scheme as strongly as relational databases do. Hence, it is possible to add a field into “record” without first making changes to the structure itself. Since, in the relational databases, you have to know in advance what you want to store, NoSQL databases make this process easier.
All the above are common characteristics, but certainly, by no means are they the definition of NoSQL. At this point, I don’t think we’ll ever have a full, proper definition of NoSQL databases. However, this may be for the best as it goes hand-in-hand with NoSQL’s “free spirit” identity.
Now that you’re familiar with NoSQL, we will learn about different types of NoSQL databases.
Types of NoSQL Databases
NoSQL databases use a different approach. Based on a data model, there are a few types of databases in the NoSQL world:
- Key-Value Stores
- Column Stores
- Graph Stores
- Document Stores
- Multi-Model Databases
Key-Value Stores
Key-Value Store is effectively an associative array stored on a disk; it is a single key lookup, a dictionary so to speak.
The good thing about these databases is that they can be read very quickly, but these databases are not so good for reverse lookups or additional analytics.
An example of this type of database is Redis.
Column Stores
Column Stores is the subset of NoSQL databases that kept, somewhat, to the tabular form.
So, what does this mean?
Column Stores vs Relational Databases
Relational Database Approach
Well, as you probably know, relational databases keep all their data in tabular form (where every row represents one entity). Since every row is saved separately on the disk, we could say that rows align the data.
When reading this kind of database, it always reads the whole row, even if not all of the data is necessary (i.e., if we only want one column of values).
Column Store Approach
Column stores, on the other hand, change this approach a bit: they store data in so-called columned families (i.e., in column order).
For example:
- First, the Ids of all records are saved.
- Then, all of their names, etc.
Why is this a big deal?
This is a big deal because it is possible to get the whole column in a more efficient manner than it was when you got all of the rows and had to pull specific values from each one
Basically, we can get more information from the database in a single seek. Also, these databases can be easily compressed and, it goes without saying that writes are very expensive.
A typical example of these databases is Cassandra.
Graph Stores
Graph stores use graph structures for queries, with nodes, edges, and properties, to represent and store data.
They are used for storing a network of connections or relationships (e.g., social networks).
Graph stores are a bit different from other NoSQL databases since they originated from a different problem with relational databases–they have a number of small records with a lot of relationships between them.
An example of such a database is AllegroGraph.
Document Stores
One of the most popular types of NoSQL databases is Document stores, which revolves around the concept of a document.
Documents are self-describing structures and usually similar to each other, but they don’t have to be the same.
Unlike the rows in relational databases, where every row has to follow the same schema, documents can vary from each other and still belong to the same collection.
MongoDB and Couchbase are examples of document stores.
Multi-Model Databases
Multi-model databases are designed to handle multiple data models against a single integrated backend.
They are a brand-new in the NoSQL world, and there will be much more buzz around this type of database in the future.
Yey! Hats off to your patience. My goal for part 1 was to make you understand about the NoSQL Database. In the next part, I will be covering Polyglot persistence and then we will quickly jump to specifically MongoDB. If you want to discuss anything about this part put your thought in the comment section below.
