In the previous recipe, we saw how to set up a simple sandbox instance for MongoDB in the cloud using MongoLab. In this recipe, we'll build on it and see what services MongoLab provides from the perspectives of management, administration, monitoring, and backup.
Refer to the previous recipe to know how to set up a sandbox instance in the cloud using MongoLab.
- Go to https://mongolab.com/home; you should see a list of databases, servers, and clusters. If you have followed the previous recipe, you would see one standalone database,
mongolab-test(or whatever name you chose for the database). Click on the database name; this will take you to the database details page. - On clicking on the
Collectionstab, which should be selected by default, we will see a list of collections present in the database. If the previous recipe was executed before this one, you would see one collection message in the database. - Click on the name of the collection, and we will be navigated to the collection details page as follows:
- Click on the Stats option to view the stats of the collection. Except for whether the collection and the maximum number of documents in a collection are capped or not, the contents come as a result of the following command:
db.<collectionName>.stats() - In the Documents tab, we can query the collection. By default, we will see all the documents with 10 documents shown per page, which can be changed from the records/page drop-down list. A maximum value of 100 can be chosen.
- There is another way to view the documents, which is as a table. Click on the table radio button in Display mode and click on the (edit table view) link to create/edit the table view. In the popup shown, enter the following document for the messages collection and click on Submit:
{ "id": "_id", "Message Text": "message" }On doing this, the display will change as follows:
- From the ---Start new search--- drop-down list, select the [new search] option, as shown in the following screenshot:
- With the new query, we will see the following fields to let us enter the query string, sort order, and projections. Enter the query as
{"_id":1}and fields as{"message":1, "_id":0}.
- You might choose to save the query by clicking on the Save this search button and give a name to the query to be saved.
- Individual documents can be deleted by clicking on the cross next to each record. Similarly, the Delete all button will delete all the contents of the collection.
- Similarly, clicking on + Add document will display an editor to type in the document that will be inserted into the collection. As MongoDB is schemaless, the document need not have a fixed set of fields; the application should make sense out of it.
- Go to
https://mongolab.com/databases/<your database name>(mongolab-testin this case), which can also be reached by clicking on the database name from the home page. - Click on the Stats tab next to the Users tab. The content shown in the table is the result of the
db.stats()command. - Similarly, click on the Backups tab at the top, next to the Stats tab. Here, we can select options to take a recurring or one-time backup.
- When you click on Schedule recurring backup, you will get a pop-up window that will let you enter the details of the scheduling, such as the frequency of the backup, the time of the day when the backup needs to be taken, and the number of backups to keep.
- The backup location can be chosen to be either MongoLab's own Simple Storage Service (S3) bucket or the Rackspace cloud file. You might choose to use your own account's storage, in which case, you will have to share the AWS access key/secret key or user ID/API key in case of Rackspace.
Steps 1 to 5 are pretty straightforward. In step 6, we provided a JSON document to show the results in a tabular format. The format of the document is as follows:
{
<display column 1> : <name of the field in the JSON document> ,
<display column 2> : <name of the field in the JSON document> ,
<display column n> : <name of the field in the JSON document>
}The key is the name of the column to display, and the value is the name of the field in the actual document whose value will be shown as the value of that column. To get a clear understanding, look at the document defined for the messages collection, look at the document in the messages collection, and then take a look at the displayed tabular data. The following is the JSON document we provided; it states the name of the column as the value of the key and the actual field in the document as the value of the column:
{
"id": "_id",
"Message Text": "message"
}Also, note that the field name and values of the JSON documents here are enclosed in quotes. The Mongo shell is lenient in the sense that it allows us to give field names without quotes.
If we see step 16, we will see that the backups are stored either in MongoLab's AWS S3/Rackspace Cloud Files or in your custom AWS S3 bucket/Rackspace Cloud Files. In latter cases, you need to share your AWS/Rackspace credentials with MongoLab. If this is a concern and the credentials can potentially be used to access other resources, it is recommended that you create a separate account and use it for backup purposes from MongoLab. You might also use the backup created to create a new MongoDB server instance from MongoLab. Needless to say, if you have used your own AWS S3 bucket/Rackspace Cloud Files, storage charges are additional; they are not a part of MongoLab's charges.
There are some important points worth mentioning. MongoLab provides a REST API for various operations. The REST API too can be used in place of the standard drivers to perform CRUD operations. However, using MongoDB client libraries is the recommended approach. One good reason to use the REST API right now over the language driver is if the client is connecting to the MongoDB server over public network. The shell we started on our local machine that connects to the MongoDB server on the cloud sends unencrypted data to the server, which makes it vulnerable. On the other hand, if REST APIs are used, the traffic is sent over a secure channel as HTTPS is used. MongoLab plans to support a secure channel for communication between the client and the server in future, but at the time of writing this book, it is not available. If the application and database are in the same data center of the cloud provider, you are safe and depend on the security provided by the cloud provider for their local network, which generally is not a concern. However, there is nothing you can do for secure communication other than ensuring that your data doesn't go over public networks.
One more scenario where MongoLab doesn't work is when you want the instances to run on your own instance of a virtual machine rather than on the one chosen by MongoLab or when we want the application to be in a virtual private cloud. Cloud providers provide services such as Amazon VPC, where a part of the AWS cloud can be treated as a part of your network. If you intend to deploy your MongoDB instance in such an environment, MongoLab cannot be used.