The When, Where and Why to Use NoSQL

There are many instances of when, where and why one should use NoSQL. The two major attributes of NoSQL is the flexibility and scalability and has drawn a lot of attention and experimentation recently.

Relational databases and SQL Server have been the go-to databases for more than twenty years. Nonetheless, the rising need to process higher varieties and volumes of data at a fast pace has changed the nature of data storage needs for app developers. To enable this scenario, NoSQL databases which enable unstructured and heterogeneous data at scale storing have gained in popularity. NoSQL is a databases category that distinctly differs from SQL databases. NoSQL often is used to mean data management systems that are ‘Not SQL’ or an approach to data management which includes ‘Not only SQL’.

There are many instances when, where and why NoSQL should be used. A general use of NoSQL is if data structures are not defined clearly at the time of making the system. If the model structure is centered largely on one or few model objects and most relationship actually are child objects of the major model objects. In this scenario, there is a fairly little need for actual joins. When it comes to caching, even if one would want to stick with an RDBMS as the main database, it could be useful to utilize a NoSQL database for query results caching or to keep data, like counters.

The two key attributes of NoSQL databases are scalability and flexibility. Although NoSQL databases have not quite reached the hype of Hadoop data management framework, they are drawing a lot of experimentation and attention. It’s important to choose wisely among the various NoSQL options, or trade-offs required to acquire flexibility and scalability. The databases are simple and affordable than their relational counterparts. The simplicity contributes to rapid development and performance at scale. Most, although not all NoSQL databases are open source, thus one could begin with a community software and adding a commercial support and also helpful commercial add-on modules as the deployment progresses. Since the biggest dissatisfaction with existing, databases arise from licensing terms and costs, open and free would look appealing to most Information Technology teams, particularly those that bootstrap a pilot project.

Typically, NoSQL is good for unstructured or schema-less data. NoSQL typically favors a denormalized schema because of no support for JOINS per the RDBMS environment. Thus, one would normally have a denormalized, flattened data representation. NoSQL use does not mean potentially losing data. Various DBS have different strategies, one could choose what level to trade off performance against a possible loss of data. Often, it’s very easy to scale-out NoSQL solutions. The system is seen as a key part of a new data stack supporting. When something is so massive that it should be distributed massively, NoSQL is the answer, although not all systems are targeting big. Bigness could be across a lot of dimensions, not only using plenty of disk space.

NoSQL provides fast key-value access. When latency is paramount, it is difficult to beat hashing on a key and reading value direct from memory or in as little as a single disk seek. Not every NoSQL product is about rapid access, there are some that are more about reliability, for instance. Nonetheless, what people wanted for a long time was a better cached and a lot of NoSQL systems provide this. NoSQL products support an array of new types of data. This is a major area of innovation of the system. Objects that are complicated could be stored easily with no need for plenty of mapping. Developers love to avoid complex schemas as well as ORM frameworks. Lack of structure enables more flexibility.

The schema-less-ness makes it easier dealing with schema migrations without much worry. Schemas are in a way dynamic, as they are imposed by the app at run-time, thus various parts of an app could have another view of the schema. Easier administration, maintainability, and operations are very product specific. However, a lot of NoSQL vendors try acquiring adoption through making easy for easy for developers to adopt them. They spend a lot of effort on usage ease, minimal administration and operations that are automated. This could lead to lower costs of operations since special code need not be written to scale a system that was never meant to be used that way.

NoSQL systems, since they have focused on scale, have the tendency to exploit partitions, not to use heavy stringent consistency protocols, and thus are well-positioned in operating in distributed instances. Generally, NoSQL systems are the only products with a ‘slider’ for selecting where they want to land on the CAP spectrum. Relational databases choose strong consistency, meaning that they could not tolerate a partition failure. In the end, this is a business decision and must be decided on a case to case basis.