Avoid these Pitholes while using MongoDB

Hello everyone, before I begin I must say that with the rise of popularity of noSQL, so has risen my curiosity with this technology. This is primarily because of modern mobile apps and unstructured data such as text rich content and multimedia.

Daffodil Software has been an earnest contributor towards building beautiful mobile apps for clients across the globe, this only brought me closer to experiencing the noSQL humdrum. My experience has always been on SQL but as the sands of time shifted, so has my experience from SQL to noSQL.

Digging more into this, I got to know about a few misconceptions regarding noSQL, especially on one of its most used platforms MongoDB. We know MongoDB is a cross-platform document-oriented database. Classified as a NoSQL database, MongoDB keeps off the traditional table-based relational database structure in favor of JSON-like documents. MongoDB is a free and open-source software.

With all the ease stacked in its favor, a lot of developers and implementers consider MongoDB to be a very easy to maintain platform (which is true) but, in its heed, they forget a few basic practices that must be tended to.

Here is a small list of things that must be kept in mind while using MongoDB:

1.) Like any other database MongoDB also requires capacity planning, tuning, monitoring, and maintenance. Just because it’s easy to install and get started and it fits the developer paradigm more naturally than a relational database, do not misconceive that it doesn’t need proper care and feeding.

2.) We should not avoid best practices when designing schema; schema should be in accordance to user requirement. Combine objects into one document if you will use them together, otherwise separate them. Duplicate the data because disk space is cheaper than computing time. Basically avoid joints but do it while writing, not during reading. Don’t insert mixed data-type values into one common fields, it can degrade performance.

3.) Without good indexing strategy and the right hardware resources on real environment we cannot get good results for a very long time.

4.) MongoDB doesn’t know how secure our data is. As with any other database, we should operate on the “need to know/need to access” principle of least necessary privileges. We have to configure the security of our database ourself. The whole world doesn’t need to see your data.

5.) Data written has to be flushed to disk. If our disk is at 100% utilization, we won’t be able to process more writes any faster than we already are. We can see how long it takes to flush the dirty pages in data files to disk in the “Background flush average” chart in MMS(Mongodb monitoring system).

These are few things which can help us make our noSQL database deployment successful in any environment.

I hope you found this article helpful. For more of such posts around technologies that are leading the world, subscribe to our blog and stay posted.