Performing operations on MongoDB from MongoLab GUI

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 build on it and see what services MongoLab provides you with, from the management, administrative, monitoring, and backups perspectives.

Getting ready

Refer to the previous recipe, Setting up a sandbox MongoDB instance on MongoLab, on how to set up a sandbox instance in the cloud using MongoLab.

How to do it…

  1. Go to https://mongolab.com/home; you should see the list of databases, servers, and clusters. If you have followed the last recipe, you should see one standalone database, mongolab-test (or whatever name you chose for the database). Click on the database name, which should take you to the database details page.
  2. After clicking on the Collections tab, which should be selected by default, we should see the list of collections present in the database. If the previous recipe was executed before this one, you should see one collection, messages, in the database.
  3. Click on the name of the collection and we should get navigated to the collection details page as follows:
    How to do it…
  4. Click on the Stats option to view the stats of the collection.
  5. In the Documents tab, we can query the collection. By default, we see all the documents with 10 documents shown per page, which can be changed from the records/page drop-down menu. A maximum value of 100 can be chosen.
  6. There is another way to view the documents, as a table. Click on the table radio button in the Display mode and click on the link to create/edit table view. In the popup that is 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:

    How to do it…
  7. From the --Start new search-- dropdown, select the [new search] option, as shown in the following image:
    How to do it…
  8. With the new query, we see the following fields that let us enter the query string, sort order, and projections. Enter the query as {"_id":1} and fields as {"message":1, "_id":0}:
    How to do it…
  9. You can choose to save the query by clicking on the Save this search button and giving a name to the query to be saved.
  10. Individual documents can be deleted by clicking on the cross next to each record. Similarly, the Delete all button at the top will delete all the contents of the collection.
  11. Similarly, clicking on + Add document will pop up an editor to type in the document that would 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.
  12. Go to https://mongolab.com/databases/<your database name> (mongolab-test, in this case), which can also be reached by clicking on the database name from the home page.
  13. Click on the Stats tab next to the Users tab. The content shown here in the table is the result of the db.stats() command.
  14. Similarly, click on the Backups tab at the top next to the Stats tab. Here, we have options to take a recurring or one-time backup.
  15. When you click on Schedule recurring backup, you get a pop-up window that lets you enter the details of the scheduling, such as the frequency of the backup, time of the day when the backup needs to be taken, and the number of backups to keep.
  16. The backup location can be chosen as either MongoLab's own S3 bucket or the Rackspace cloud file. You can choose to use your own account's storage, in which case you will have to share the AWS access key/secret key or UserID/API key in case of Rackspace.

How it works…

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 of the name of the field in the actual document whose value will be shown as the value of this column. To get a clear understanding, look at the document defined for the messages collection, and then take a look at the displayed tabular data. The following is the JSON document that we provided, which 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"
}

Note that the field name and values of the JSON documents here are enclosed in quotes. The Mongo shell is lenient in this sense, where it allows us to give field names without quotes.

If we visit step 16 about backups, we see that the backups are stored either in MongoLab's AWS S3/Rackspace cloud file or your custom AWS S3 bucket /Rackspace cloud files. In the 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 can 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 as 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 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 a language driver is if the client is connecting to the MongoDB server over a public network. The shell that we started on our local machine connecting 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 the communication between the client and server in future, but as of the writing of this book, this is not available. If the application and database are in the same data center of the cloud provider, you are safe and can depend on the security provided by the cloud provider for their local network, which generally is not a concern. However, there is nothing that 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 be running on your own instance of a virtual machine rather than one chosen by MongoLab or we want the application to be in a virtual private cloud. Cloud providers do provide services such as Amazon VPC, where 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.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset