In the previous recipe, we saw how to set up an account on MongoLab and add users to the 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, Setting up and managing MongoLab account, 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 will need a mongo shell that comes only with the complete mongo installation or you can choose to use a programming language of your choice in order 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, https://mongolab.com/home, and click on the Create new button.
- Select a cloud provider, for this example, we choose Amazon Web Services (AWS):
- Click on the Single-node (development) and then, the Sandbox options. Do not change the location of the cloud server as the free sandbox instance is not available in all data centers. As this is a sandbox, we are okay with any location.
- Add any name for your database; the name that I chose is
mongolab-test. Click on Create new MongoDB deployment after entering the name. - This should take you to the home page, and the database should now be visible. Click on the instance name. The page here shows the details of the MongoDB instance selected. The instruction to connect in 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 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-testand the username and password istestUser:$ mongo <host-name>/mongolab-test –u testUser –p testUserOn connecting, execute the following in the shell and check whether 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, and we created one shared sandbox instance in the cloud. MongoLab themselves do not host the instances but use 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 IO is shared with other instances and thus the performance of our shared instance is not necessarily in our control. For a production use case, a 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 image in step 2, then we see another tab next to the Single-node (development) option. This is where you can choose the configuration for the machine in terms of RAM and disk capacity (and the price as well) and set up a replica set.
As you can see, you get to choose the version of MongoDB to use. Even if a new version of MongoDB gets released, MongoLab will not start supporting it immediately as they usually wait for a few minor versions to be rolled out before supporting them for production users. Additionally, when we choose a configuration, the default available option is two data nodes and one arbiter, which is sufficient for a majority of use cases.
The RAM and disk chosen depend completely on the nature of the data and how query- intensive or write-intensive it is. This sizing is something that we do irrespective of whether we are deploying on our own infrastructure or the cloud. The working set is something that is important to be known before we choose the RAM of the hardware. Proofing of concepts and experiments are done to deal with a subset of data and then the estimation can be done for the entire dataset. If IO activity is high and low IO latency is desired, you can even opt for SSD, as shown in the preceding image. Standalone instances are as good as replica sets in terms of scalability except for availability. Thus, we can 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, then 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, and see that they are both deployed on the same location in order to minimize latency and improve on performance. If you are starting fresh, then invest some time in choosing the cloud provider. Look at all the other services that the application would need, such as the storage, compute, other services such as mail, 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 can choose the provider to use accordingly in MongoLab. As far as the pricing goes, all the leading providers offer competitive pricing.