MongoDB is one of the more popular NoSQL databases available. NoSQL databases do not use typical relational database structure, nor do they typically rely on SQL for queries. MongoDB stores data in JSON-style documents (which themselves can be stored within collections) and allows for dynamic storage of data. For example, we do not need to create a schema, configure relations between tables, and so on. We just create our database and populate it with data on the fly. The data can be as complex or as simple (just key/value pairs) as our requirements dictate. MongoDB is also highly-scalable via the use of shard-based clustering.

I am a strict wearer of an RDBMS hat, and this is my first foray into the world of NoSQL. This first article on MongoDB will cover initial installation, configuration and testing. I’ll also dabble with authentication. Further articles will cover the configuration of replica sets and other administrative features. I’m a sysadmin, not a developer, so I’ll be looking more at how to administer MongoDB rather than how to actually use it.

Let’s get on with the installation.

Installation

Whilst source code is provided, it is far simpler to download the appropriate MongoDB distribution for your operating system and architecture. From the downloads page, I fetched the latest version (2.2.3 at time of writing) for Linux 64-bit. I downloaded, as always, to /usr/local/src.

Installation is as simple as uncompressing/untarring and creating a symlink:

Next, create a group and user to run MongoDB as. I don’t like applications charging around as root without good reason, especially applications that I am unfamiliar with:

Finally, create a directory for MongoDB data, a directory for logs, and apply the appropriate ownership over all related directories:

Installation was easy enough. Now we can configure MongoDB.

Configuration

Create a configuration file at /etc/mongodb.conf as follows:

Let’s step through these configuration items.

fork - This has been set to true to enable mongod to run as a daemon.

bind_ip - Which IP address(es) mongod should bind to. I specified 0.0.0.0, which is the default, but I prefer to be explicit within configuration files even if it is to specify the default.

port - Which port mongod should bind to. I specified an unused port on my server - 1234.

quiet - I set this to true, so that only critical events and errors are logged.

logpath - The path to the log file to which mongod should write its log messages.

logappend - I set this to true so that the log is not overwritten upon restart of mongod.

journal - I set this to true as it’s a GoodThing(TM). It ensures write durability and data consistency much as any journaling scheme would be expected to do. Only set this to false if you don’t really care about your data (or more so, the loss of it).

With the configuration in place, we can start the MongoDB daemon (mongod) for the first time.

Starting the Daemon

Let’s start up mongod as the mongodb user we created previously:

We can see that our explicit declaration of 0.0.0.0 is unnecessary, but I don’t care. We also see the daemon PID and a few other messages. We can now use the MongoDB shell (mongo) to connect to the database and test things out.

You should also take this opportunity to write the appropriate control script (SMF/upstart/init.d, depending upon your operating system).

Testing it Out

Let’s connect to our mongod instance:

As you can see, when you first connect, you’ll connect to the test database by default. You can use the db command to show which database you’re currently using, and the use command to select another database. If the database doesn’t exist, it’ll be created. Observe:

We now have a new database called mynewdb. Next, I’ll create a document called j and insert it into a collection called stuff. I can then search the collection using the find() method and lo-and-behold the document is returned:

It looks like our MongoDB installation is doing exactly what it is supposed to.

Shutting Down

To shutdown mongod, use the mongo shell to connect to the instance, and use the admin database. The admin database is a special database used for administering MongoDB. Using the shutdownServer() method will shut the server down. The error messages are obviously the result of mongod being down, and are expected. quit() will quit the mongo shell:

Excellent. We now know how to install, (basically) configure and shutdown MongoDB. You’ve probably noticed that we’ve not been prompted for any credentials as of yet. By default, connections require authentication when connecting from anywhere other than localhost. We need to add a user so that we can authenticate and connect to our servers public IP address.

Configuration of Authentication

Add the following line to /etc/mongodb.conf

and restart mongod:

Once running, attempt a find() in our stuff collection via the public interface (where mongod is also listening):

Good - we are denied access. Not very useful for our application though. Let’s configure authentication. Connect again via localhost (where authentication is not required). Use mynewdb, and then add a user via db.addUser( username, password ) as follows:

Now, reconnect via the mongo shell to the public interface of the server, and attempt a find() again on the collection:

Uh-oh! But that’s expected. Let’s now use db.auth() to authenticate using our newly created testuser credentials, and try the find() again:

Much better - our object is returned!

Conclusion

This has been my first hands-on experience with a NoSQL database, and from my intial experiments it all seems rather straightforward. Later articles will cover the configuration of replica sets, as well as pulling statistics and other operational metrics out of MongoDB. As explained earlier, these articles will cover MongoDB from an administrative/operational standpoint rather than the persepctive of a developer.

Stay tuned to tokiwinter.com for NoSQL, actual SQL, and all other database-related ramblings.