In the previous recipe, we saw how to set up an account on MongoLab and add users to your account. We still haven't seen how to fire up an instance on the cloud and use it to perform some simple operations. In this recipe, this is exactly what we will do.
Refer to the previous recipe to set up an account with MongoLab. We will set up a free sandbox instance. We will require some way to connect to this started Mongo instance, and thus, we will need a Mongo shell, which comes only with the complete Mongo installation, or you might choose to use a programming language of your choice to connect to the started Mongo instance. Refer to Chapter 3, Programming Language Drivers, for recipes on connecting and performing operations using a Java or Python client.
- Go to the home page at https://mongolab.com/home and click on the Create new button.
- Select a cloud provider; for this example, we chose Amazon Web Services.
- Click on Single-node (development) and then on the Sandbox option. Do not change the location of the cloud server, as the free sandbox instance is not available in all data centers. Since this is sandbox we are ok with any location.
- Add any name for your database. The name I chose is
mongolab-test. Click on Create new MongoDB deployment after entering the name. - This will take you to the home page, and the database will now be visible. Click on the instance name. The page here shows the details of the MongoDB instance selected. The instruction to connect from the shell or programming language is given at the top of the page, along with the public hostname of the started instance.
- Click on the Users tab and then on the Add database user button.
- In the pop-up window, add the username and password as
testUserandtestUser, respectively (or any of your choice). - With the user added, start the Mongo shell as follows, assuming that the name of the database is
mongolab-test, and the username and password istestUser:$ mongo <host-name>/mongolab-test –u testUser –p testUser - On connecting, execute the following command in the shell and check if the database name is
mongolab-test:> db - Insert one document in a collection as follows:
> db.messages.insert({_id:1, message:'Hello mongolab'}) - Query the collection as follows:
> db.messages.findOne()
The steps executed are very simple. We created one shared sandbox instance in the cloud. MongoLab itself does not host the instances but uses one of the cloud providers to do the hosting. MongoLab does not support sandbox instances for all providers. The storage with the sandbox instance is 0.5 GB and is shared with other instances on the same machine. Shared instances are cheaper than running on a dedicated instance, but the price is paid in performance. The CPU and I/O are shared with other instances, and thus, the performance of our shared instance is not necessarily in our control. For a production use case, shared instance is not a recommended option. Similarly, we need to set up a replica set when running in production. If we look at the screenshot in step 2, we will see another tab next to the Single-node (development) option. This is where you might choose the configuration for the machine in terms of RAM and disk capacity (and the price too) and set up a replica set.
As you can see, you get to choose which version of MongoDB to use. Even if a new version of MongoDB gets released, MongoLab will not start supporting it immediately, as it usually waits for a few minor versions to be rolled out before supporting the new version for production users. Also, when we choose a configuration, the default available option is two data nodes and one arbiter, which is sufficient for the majority of use cases.
The RAM and disk chosen depend completely on the nature of the data and how query/write intensive it is. This sizing is something we do irrespective of whether we are deploying on our own infrastructure or on the cloud. The working set is something that is important to be known before we choose the RAM of the hardware. POC and experiments are done to deal with a subset of data, and then, the estimation can be done for the entire dataset. Refer to the Estimating the working set recipe in Chapter 4, Administration, to estimate the working set on your sample dataset. If the I/O activity is high and low I/O latency is desired, you might even opt for SSD, as we saw in the preceding screenshot. Standalone instances are as good as replica sets in terms of scalability, but not in terms of availability. Thus, we might choose standalone instances for such estimation and development purposes. Shared instances, both free and paid, are good candidates for development purposes. Note that shared instances cannot be restarted on demand as we can for dedicated instances.
What cloud provider do we choose? If you already have your application servers deployed in the cloud, obviously, it has to be the same vendor as your existing vendor. It is recommended that you use the same cloud vendor for the application server and database. Also, they are both deployed on the same location to minimize latency and improve performance. If you are starting afresh, then invest some time in choosing the cloud provider. Look at all other services that the application will need, such as the storage, compute, and other services including e-mails, notification services, and so on. All this analysis is outside the scope of this book, but once you are done with this and finalized with a provider, you might accordingly choose the provider to use in MongoLab. As far as pricing goes, all the leading providers offer competitive pricing.