MongoDB is a really versatile NoSQL data solution. There are some key features that really help it to stand out. First and foremost is its high performance. MongoDB is very fast and efficient at responding to queries, and this high performance is very desirable in a lot of environments. It also has high availability. Now, the way it accomplishes this is that MongoDB inherently supports replication and sharding. Certainly, you can install MongoDB on just a single standalone server; but it was really meant to work in a clustered environment, or even a cloud like environment, with sharding and replication – and that gives you high availability. That also gives you automatic scaling – when you’ve replicated it and sharded it, it’s very easy to simply add-in an additional server and scale up, when additional workload is needed. These three key features make MongoDB a really outstanding NoSQL data store.
Some of the key features of MongoDB are high performance, high availability, and automatic scaling.
Now, let’s take a look at the data modeling inside Mongo. First of all, it has a flexible schema. Now, what that means is, as you enter documents or records into a MongoDB database, they need not even have the same schema. If, for example, you’re entering items in an inventory, the first one might have item name, item number, retail price, wholesale price, so on and so forth. The next item could have those same items, plus maybe size and color, or maybe have fewer items. It’s flexible like that, so that each individual document can do whatever needs to be done with the data. Now, with a SQL database, you have to determine and declare a table’s schema before you insert data. With MongoDB, you don’t have to do that. As you’re inserting the data, you’re setting up the schema for each individual document. There are no tables to worry about. Now, you could have collections of documents – which I guess are analogous to a table – but those collections don’t enforce a particular document structure. That gives us that flexible schema.
Data in MongoDB has a flexible schema. With SQL, you must determine and declare a table’s schema before inserting data. Collections do not enforce document structure.
This facilitates you can map a document to any sort of entity or object. And we have an example just a moment ago of inventory items; there might be fields that simply aren’t relevant to certain items – okay, don’t put them in that item’s document. I mean, here is an example of a document structure. I have a user document. Now, what I’ve chosen to do here is to relate it to another document. This is just one option you have with MongoDB – references. These are relationships that link data between two different documents. So at runtime, when you’re running an application, the application will resolve those relationships to access the data. This is analogous to the normalization you see in SQL based databases. Now, you don’t have to do that. You can simply embed one document in the other. Here I have username, and I also have position information, all in a single document. The related data is stored all together, and you have sub-documents. Now, this means that the data is retrieved and manipulated in a single operation. This is analogous to relational databases’ denormalization.
The data model of MongoDB facilitates mapping of documents to an entity or object.
Examples of a user document and a department document are shown.
The user document contains the following code:
{
_id: <ObjectId1>,
username: “jdoe”
}
The department document contains the code
{
_id: <ObjectId3>,
user_id: <ObjectId1>,
Name:Sales,
Office: “Chicago”
}
The related user document line is
_id: <ObjectId1>,
The related department document line is
user_id: <ObjectId1>,
Relationships use links or “references” between data. Applications resolve the relationships to access the related data. This is considered a “normalized” model.
An example of embedded sub-documents is as follows:
{
_id: <ObjectId1>,
username: “jdoe”,
contact: {
phone: “555-555-1111”,
Cell: “555-555-222
email: jdoe@xyz.com
},
Position: {
department: “sales”,
manager: “vp of sales”
}
}
The first embedded sub-document section is
phone: “555-555-1111”,
Cell: “555-555-222
email: jdoe@xyz.com
The second embedded sub-document section is
Position: {
department: “sales”,
manager: “vp of sales”
Related data is stored in the same document as sub-documents. Data is retrieved and manipulated in a single operation. It is considered “denormalized.”
And here you see the embedded sub-documents. Now, write operations are atomic at the document level. What does that mean? Well, we either save the entire document, or we don’t. You can’t save part of a document. Documents are automatically relocated on disc when their size increases. So if you change a document, you begin to add things to it, the disc will be reallocated, so space is available for the document. And MongoDB does this for you automatically. Now, during design, you will have to consider how the applications are going to use the database, and what’s most important to them. And that will help you to decide whether you want to use the sub-documents method, or the relationship method. Either one works, but each one may be more appropriate for one type of application or another.
Write operations are atomic at the document level. Documents are automatically relocated on disk when their size increases. During design, it’s important to consider how applications will use a database.
Big Data Technologies 