First I ask you: have you done complex operations like Nosql? Have you properly measured performance in all situations?
Right tool
There is a popular expression that everyone knows: "If the only tool you know is a hammer, all problems look like nails".
No, this expression does not fit here, but it is adopted by many. It should be known another that fits in this situation: "When you have a Swiss Army knife, you’ll want to play with all the tools".
Nosql is an interesting technology and has its uses. It is certainly one of the tools of the Swiss Army knife that we have available. But he’s not a knife, a screwdriver or a corkscrew.
Nosql is that obscure tool that almost no one knows what it’s for (even the majority that use it). But even so people try to use, after all if it’s there, I should be forced to use it, right? If there are other people using it must be good.
Confusion of concepts
Nosql is a name that encompasses several very different technologies with a common feature. Knowing how to choose the most appropriate technology is also important.
To quote only the main variants:
- key pairs and value;
- columnists;
- document-based;
- graphs.
Even these have subtypes. Such are the variations that will hardly find two technologies with the same characteristics.
Others have given some hints that the subject is more complex and you will see wrong explanations everywhere.
Durability
You talk about a lack of availability. I’ll imagine you’re talking about lack of durability, because availability is one of the things that Nosql facilitates.
Durability is the property of the information remaining permanent after its execution. In general this is obtained by writing in mass memory (disk for example).
Availability is the property where the database is responding to darlings whenever requested. It does not mean that there will be no answer, but it may not happen now.
In fact some implementations do not facilitate durability, or at least it does not have it as a priority. But it is possible to have all durable data in one way or another.
Consistency
Technologies Nosql are usually great to get scalability.
Already the consistency is even problematic. Nosql basically accepts the thesis of eventual consistency. That is, at some point the database will be consistent. Even at some undefined time it will be durable, or available.
Not all problems require consistency to be absolute.
So Nosql trades one capacity for another.
Ease of use
This is not the best reason to choose a tool, especially when this facility is not absolute. You need general anesthesia to simply break the nose bone but you can remain conscious when you open the brain. It’s counterintuitive, but that’s how it works.
Where to use?
If you are Facebook, how will treat billions of transactions a day in a database?
With Nosql! If you are Facebook you need a technology like this. And if you’re Facebook, you won’t need absolute consistency in most cases. And in the cases you need, you will create an application that will handle it. This application will be complex, but it is the only way to do.
On Facebook also does not need relational features of the database. Part of this is by the application’s own feature. But also helped by the way it’s developed. When they think of adding some feature of the software that approaches the relational feature, or if it changes the way of developing the software, it refuses the functionality.
I’ve seen many "experts" in databases complain about the lack of a feature on Facebook or Gmail. According to them, it would be a trivial resource to implement. It would be... in a relational database.
No one will die or be harmed if it takes a while to receive a notification from a friend, if the number of Likes not 100% accurate at the exact moment you’re looking. The most vicious (or realistic?) will say that even permanent grotesque errors on this site will also make no difference to someone’s life :)
So if you’re not Facebook (of course it’s just an example), don’t worry so much about Nosql. Whoever says Nosql is not niche you’ll probably be behaving like fanboy. You may disagree with the size of the niche, but it’s not a solution to everything.
For default you should use a relational database. Most real problems where databases are used fit this paradigm either very well or at least minimally adequately. Most problems have related tabular data.
A surgery that cures a rare brain disease draws a lot of attention, but most people just need to take out the appendix. What’s in the media is not what everyone needs is just what draws attention.
Subject of the moment
You hear talk a lot because the media is like this, always has the subject of fashion. The most qualified professionals usually write a lot on the internet. Cutting-edge technologies (which are almost always only used in very specific cases) are more evident than mature technologies. When another more relevant subject comes up, everyone will talk about it and Nosql will not be spoken about until it is relevant. There are even other reasons for the subject to have so much repercussion, but it does not fit here.
Now the fashion is microservice which is an extension of Nosql. In this methodology Nosql makes a lot of sense, but a simple relational like Sqlite also does (there are other examples), in some cases. Microservice bears resemblance to Nosql in difficulties. To achieve one feature complicates all the rest.
Long live the relational
Several attempts of new database paradigms tried to overcome the hegemony of relational and failed. But almost all have survived in niches, some have had enough prominence. The problem is when you try to use for something beyond what it was made.
The biggest abuse is the document template. People think they can trade tables for documents. This model was made when it actually has documents and not related data. Most problems are not documents, people try to change the problem to fit this way.
Relational databases are well known, meet the requirements of what is done, perhaps, in 99.9% of the "real world applications", and have an immense amount of professionals who dominate their use. Someone must think of him before any other alternative. First think of the knife, or perhaps the screwdriver. If they don’t solve the problem properly, then you’ll think of another tool.
I’m not saying you shouldn’t study new database paradigms. If you don’t study you won’t know when to use them. Just like with languages, knowing different ways to solve a problem not only helps to know when to use a different tool, but also to know how to solve the problem in a different way with the same tool.
The problem is that most learn wrong.
And in fact almost all relevant relational databases are creating different ways to solve certain problems that are more suited to a Nosql. All the more reason not to abandon the relational ones. 10 years later some relational are able to handle all problems well, just are not very small. Others are small but deal only more or less with this type of problem.
After seeing many people working with it I see that they use it the wrong way. They do everything too simple and only works because they didn’t need it. When they need it all gets too complicated or else it doesn’t work right. As in general it was not necessary these problems appear little.
Note that one technology does not exclude the other. Stack Exchange itself uses both. And it has the advantages of each. But at first it only used SQL. And when it changed, nobody noticed the difference. So it’s just an implementation detail. The change was relatively simple.
Just don’t think that the financial system of a company will have the same benefit. It may even have harm. I’ve seen them do it, but the trouble that comes.
We still have a immensity of problems that require complex relationships. Why avoid a relational database? I have seen disasters where the relational is the right one but the person opted for Nosql (or Norel which is what this technology really is).
In fact, the correct name for this type of technology should be Noconsistency because that’s what it doesn’t really have. Increasingly they are using relations and even SQL.
In some cases, in order to achieve consistency, it gives up availability.
As most often want consistency and availability one should avoid partitioning. All this is part of the CAP. You think it doesn’t, but it works.
This site is one of the 30 most accessed sites in the world and has consistency, and availability, no partitioning. And serves well without bumps. You think you need more than that?
Stack Overflow (the big guy) can run on a server if you want.
OS traffic in Brazil is similar to one of the largest and best known Brazilian websites that has a very similar access pattern. A descriptive page that all read a lot, and very eventually someone comments something or more eventually does some writing operation, and this site needs thousands of servers, precisely because it has adopted wrong tools. And it needs a lot more IT people to handle everything, especially development. Many of these fashions are sold as facilitators, it is insane.
Completion
The best way to learn all this is to make one serious, thorough and consistent study on the subjects. In the process you may even discover that you didn’t know a lot about relational databases (I saw a lot of Nosql fans - people who are references - who didn’t know how to use relational right and made the decision because of it). If you cannot conduct these studies properly you will have to rely on random people telling you what is good for you. : P
If you need absolute consistency, yes, it is problematic, although it is not unfeasible. The problem is that there you will be using the wrong tool, will have a lot of work to achieve what is "easy" with another tool.
The big question that needs to be asked: why does "hell" someone choose to use Nosql when it needs absolute consistency? The same goes for availability that you can get one or the other, or both if you give up partitioning, which is why Nosql was created.
Remember that Nosql does not apply to any case and it seems to me that it really gives up certain aspects to favor others precisely to contemplate applications like Redes Socias, SQL Magazine published a good article recently on this.
– Motta