From time to time we, at Mobile Jazz, receive questions from clients in regards to NoSQL. During the past years, there has been a lot of talk about big widely-known tech companies embracing the latest database technologies to cope with their high volume data necessities. So no surprise here, when brand new start ups think the same approach will fulfill their needs.
Don’t get me wrong, I believe that thinking about NoSQL for your project is legitimate. I truly think that non-relational databases sometimes fit nicely in small projects, and that not only big data can take advantage of it.
What can NoSQL offer?
NoSQL databases were born to fix the problems that relational databases (RDBMS) presented when having to manage huge amounts of data. The main goal was to improve performance, scalability and availability.
When RBDMS are partitioned into many nodes, data access times tend to get higher because of the latency introduced by server synchronization. Not only times are higher but to create this distributed systems is a big pain for developers. Besides, when one server is unreachable, the whole system is generally affected.
NoSQL on the contrary fits nicely in those scenarios of big data and scalability. What is more, they were born to ease the pain of horizontally scaling. In non relational systems, data access times can still be very good in distributed systems.
So how does NoSQL achieve its goals? By reducing the number of features that RDBMS offer.
Myths about NoSQL
Maybe you have read that NoSQL databases are inconsistent. That data is not the same for all users. That they don’t work with transactions, and updates can’t be rolled back if needed. Well, that is true, but not that scary as you might think.
First of all, not all NoSQL databases are equal, nor they share the same characteristics. Document oriented databases for instance, are always consistent as long as your database is well designed. You may want to work with models that are not dependent on other entities. If your data unit fits in a single document you are good to go, since changes in one document are atomic (all changes are done or none, no intermediate scenarios here). And there are Graph oriented databases for instance, which are fully consistent as well. So in this case inconsistency is not a real problem.
But what about different data for different users? I admit that could happen, but only if it is the desired behaviour. When scaling databases one approach is to replicate data in different servers to decrease reading times. So in that case, one user could read data which has not been yet updated, but that eventually will.
In summary, inconsistency could just well be a business decision.
Is NoSQL only for big companies then?
Not at all. These are some reasons to decide going for a NoSQL database:
1. Big data: Sure this is the most typical case. But when we say big data, we are talking about very big numbers. We have some clients that would fit into this categories at Mobile Jazz, but big data is not the only reason why you would want to go for non-relational solutions.
2. Prototypes and iterations: Mainly what this means is that NoSQL offers fast development in certain cases. Prototypes are a good example. Validating an idea doesn’t require a complete bullet-proof architecture. Going for a light-weight solution could be recommended for a later easier iteration over your product.
3. Easier development: So not only working faster could be a reason. NoSQL can also be a good fit for mature well established projects. If the data you are working with is always managed as a whole, why not go for a document oriented database? Think for example about blog or newspaper articles, why break your model into multiple entities when you always work with one single type of information?
In summary, NoSQL doesn’t fit in all kinds of projects, but not only Google and Amazon alike companies can take advantage of their features. It is always something to be considered.