Instant MongoDB: Get up to speed with one of the the world's most popular NoSQLdatabase

While it may vary for various implementations of different Document Oriented Databases available, as far as MongoDB is concerned it is a BSON document, which stands for Binary JSON. JSON (JavaScript Object Notation) is an open standard developed for human readable data exchange. Though a thorough knowledge of JSON is not really important to understand MongoDB, for keen readers the URL to its RFC is http://tools.ietf.org/html/rfc4627. Also, the BSON specification can be found at http://bsonspec.org/. Since MongoDB stores the data as BSON documents, it is a Document Oriented Database.

Consider the following example where we represent a person using JSON:

{
  "firstName":"Jack",
  "secondName":"Jones",
  "age":30,
  "phoneNumbers":[
    {fixedLine:"1234"},
    {mobile:"5678"}
  ],
  "residentialAddress":{
lineOne:"…", 
lineTwo:"…", 
city:"…", 
state:"…", 
zip:"…", 
country:"…"
  }
}

As we can see, a JSON document always starts and ends with curly braces and has all the content within these braces. Multiple fields and values are separated by commas, with a field name always being a string value and the value being of any type ranging from string, numbers, date, array, another JSON document, and so on. For example in "firstName":"Jack", the firstName is the name of the field whereas Jack is the value of the field.

Many of you would probably be wondering why we need another database when we already have good old relational databases. We will try to see a few drivers from its introduction back in 2009.

Relational databases are extremely rich in features. But these features don't come for free; there is a price to pay and it is done by compromising on the scalability and flexibility. Let us see these one by one.

Ease of development

MongoDB doesn't have the concept of creation of schema as we have in relational databases. The document that we just saw can have an arbitrary structure when we store them in the database. This feature makes it very easy for us to model and store relatively unstructured/complex data, which becomes difficult to model in a relational database. For example, product catalogues of an e-commerce application containing various items and each having different attributes. Also, it is more natural to use JSON in application development than tables from relational world.

Ok, it looks good, but what is the catch? Where not to use MongoDB?

To achieve the goal of letting MongoDB scale out easily, it had to do away with features like joins and multi document/distributed transactions. Now, you must be wondering it is pretty useless as we have taken away two of the most important features of the relational database. However, to mitigate the problems of joins is one of the reasons why MongoDB is document oriented. If you look at the preceding JSON document for the person, we have the address and the phone number as a part of the document. In relational database, these would have been in separate tables and retrieved by joining these tables together.

Distributed/Multi document transactions inhibit MongoDB to scale out and hence are not supported and nor there is a way to mitigate it. MongoDB still is atomic but the atomicity for inserts and updates is guaranteed at document level and not across multiple documents. Hence, MongoDB is not a good fit for scenarios where complex transactions are needed, such as in an OLTP banking applications. This is an area where good old relational database still rules.

To conclude, let us take a look at the following image. This graph is pretty interesting and was presented by Dwight Merriman, Founder and CEO of 10gen, the MongoDB company in one of his online courses.

As we can see, we have on one side some products like Memcached which is very low on functionality but high on scalability and performance. On the other end we have RDBMS (Relational Database Management System) which is very rich in features but not that scalable. According to the research done while developing MongoDB, this graph is not linear and there is a point in it after which the scalability and performance fall steeply on adding more features to the product. MongoDB sits on this point where it gives maximum possible features without compromising too much on the scalability and performance.

Following are the three steps you need to know or check before you start the MongoDB installation:

The installation of MongoDB is very simple. Once the binaries are downloaded, the server can be up and running in a matter of seconds.

The first step is to visit the site http://www.mongodb.org/downloads to download MongoDB. Always prefer the latest stable build, download the right set of binaries based on your platform. 32 bit version should only be used for development purpose only use 64 bit for production deployments. Since MongoDB uses memory mapped files for data files, the database size is restricted to a total of 2 gigabytes on 32 bit machines. The steps and screenshots I will be giving are for 32 bit Windows platform. For other platforms the steps for installation will remain same.

On Windows you can get the architecture of your platform by typing in the following command into the command prompt:

wmic os get osarchitecture.

Once the binary archive is downloaded and saved to your local disk, we need to extract it. On Windows use any file for archiving. On extracting the archive, go into the bin folder. You should see the content as shown in the following screenshot on a Windows platform. The names of the executables would be same on other platforms. mongo and mongod are the only executables we are interested in for now.

Next, we need to start the MongoDB server by executing the mongod executable from the shell. You may add the bin folder of the extracted folder in your operating system's path variable. Let's us start by typing in the following command:

> mongod

The server didn't start as we didn't provide the path for the database files on startup. By default the path used is /data/db and we don't have that folder on our file system. We can either create this directory or provide a custom location for the database.

Let's provide a custom path. Say we use c:\Mongo\Database as our database and try to start the MongoDB server once again. This time around we however provide the --dbpath parameter. So type in the following command (in your case provide the appropriate path you have chosen for the database) to start the MongoDB server:

> mongod --dbpath C:\Mongo\Database

If all goes well, the server now must have started and should be listening for connections on port 27017. This is the default port on which the mongod process listens for new connections.

To stop the server you can press Ctrl + C. This will stop the server in a clean manner.

We should not be too worried about the warning related to journaling. Since we have started the server for development purposes, we do not need journaling. Journaling is a means to ensure that the data files of the database don't go in an inconsistent state even if there is an improper shutdown of the server such as in cases of power failures. In the absence of journaling and unclean shutdown, there are bright chances that your data files will be inconsistent on restart. To know more about journaling, refer to the link http://docs.mongodb.org/manual/administration/journaling/, but don't worry if some of those things don't make much sense for now.

To know all the possible options you can provide while starting the Mongo server, use the --help option as follows:

> mongod --help 

Assuming that most of us have some familiarity with the relational databases, a quick comparison of various terminologies of these two should help. Following is a table of various terms used in Relational world and Mongo world. The terms Mongo and MongoDB will be used interchangeably (I personally prefer saying Mongo over MongoDB and save the effort of typing two extra characters).

As we can see, except for Table, Record, and Column in relational databases, everything else means the same in Mongo.

Another big difference in relational model and Mongo is, unlike the create table for tables in relational databases, Mongo doesn't need the user to create the collections explicitly. A collection will automatically be created when the first document is inserted in it. Collections in Mongo are schema less. They can contain documents with disparate fields (so there is nothing stopping you from putting a document of a bicycle and a book in the same collection, one might actually do it for maintaining a product catalogue of an online store and that's the beauty of Mongo). The only field mandatory for all documents is the _id, which if not provided in the document inserted, will be automatically generated by the Mongo Server. So unlike relational databases, we simply insert documents in the collections without creating it. Inserting documents in a collection implicitly creates one. Ironically, even though Mongo is schemaless, schema designing is a crucial aspect. We will see in a later section what thought needs to be put into schema design.

Now having laid a foundation for our work and compared the relational model and Mongo, let us import some sample data into our database. This is the test data on which we would be performing various query operations. You need to download the files IndiaCitiesPopulation.csv and IndiaStates.json from http://www.packtpub.com/support/13523. These files contain all the cities in India whose population is above 100,000 as per 2011 census and states of India with various cities in each state respectively. There are 495 records in the CSV and 29 documents in the JSON file, not a lot of data but good enough for us to practice. You may open the files in your favorite editor and take a look at its content; the CSV file has a header and each of these headers (which are comma separated) will be used as the name of the field for each document (we have already seen in the first section how a document looks like). When we import the file, each line in the file excluding the header line, will be one document and hence we shall have 495 documents inserted in the collection. The JSON file will be imported as is with each line in the file as a separate document in the collection. You'll have to open a new terminal to execute these imports.

We shall call our database census and the collections in which the data will be imported as cities and states. Use the following command to import the data in the cities collection:

> mongoimport -d census -c cities --file IndiaCitiesPopulation.csv --type csv --headerline

The command was executed with the .csv file to be imported in the current directory. You can provide the absolute path of the file name too. On executing the import command the data gets imported within no time and you see the output as shown in the preceding screenshot.

Let us first see what those various command line arguments are to the mongoimport utility:

Now that we know what those command line arguments mean, we will try to import documents in the states collection. This is a .json file and the command is slightly different.

> mongoimport -d census -c states --file IndiaStates.json

This time we skip the --type argument as the default is JSON (so is our file) and the --headerline which is irrelevant for JSON files. After the import, you should have 29 objects in the states collection.

For our import to work, we need to have the Mongo server we started after the installation up and running. Let us connect to the database from the shell. The shell is a client application that ships with Mongo installation and will let you connect to the database and perform various operations, such as execute queries, update or insert documents, perform database administration operations, and so on. You need to execute mongo executable to start the shell. This executable is present in the bin directory of our Mongo installation. On executing Mongo, it would by default connect to the Mongo server running on localhost and would connect to the port 27017, which is the default port on which Mongo listens for new connections. On executing the command you should see a prompt which will be a >.

Type in db and hit Enter, we shall see the name of the database to which it is connected. The shell has a JavaScript engine and you can execute any valid JavaScript in Mongo shell. The shell has an implicit variable db that references the current database, test by default. We have our data in the census database. We will switch to that database by typing in the following command:

> use census

This will change the current active database to census. This means that any queries now executed from the shell will be executed on the database census. Typing in db and hitting Enter will confirm that the current database in use is indeed census. Next we will see what all collections are present in the current database (census that is). The command to do that is show collections (similarly to show all the databases you can use the show dbs command).

As we see from the preceding screenshot, there are three collections in the database. The two collections cities and states, which we have created by importing the documents and a third is the system.indexes, which is a system generated collection used to store information about all the indexes on various collections in the database. The first operation will find the number of documents in the cities collection; we know it should be 495, let us check by executing the code.

> db.cities.count()

We should see 495 as the count which we expected. This is similar to the select count(*) query in a relational database. Remember, all the queries we will be executing will begin with db.<name of the collection> and then the function we would like to perform such as count, find, update, insert, remove, and so on. Easy, isn't it? The shell does offer us a good help. To see what possible operations we can execute on a collection, Execute the following command on the Mongo shell:

> db.cities.help()

Let us take a look at all the documents in the cities collection. As you must have guessed (and must be waiting to execute this), it is synonymous to executing a select * on a relational table without a where condition.

> db.cities.find()

Following is the result on executing the find:

It is not difficult to guess what the query structure is. The query again starts with db.cities which tells that the function to be executed will be on the cities collection in the current database. The find function here does not accept any parameter and hence selects (finds) all the documents.

A couple of things to note here:

What we saw in this section is some comparison between the Relational world and Mongo world. We also imported the data in our census database, started the Mongo shell, connected to the running Mongo server and queried the collection to find the data. This process of finding the data is not powerful unless we add various conditions to it to fetch the limited set of data we wish to query. In the next section we will see a variety of operators and its combination to write powerful queries to retrieve data from Mongo. We will also see how to insert, update, and delete documents from the collection. Stay tuned for more interesting things coming up.