Do you wash your hands with soap? Then tea without sugar

You may remember how several years ago the NoSQL-database began to gain popularity rapidly (MongoDB, DynamoDB and others). Many prophesied the death of classic relational databases, the triumph of new paradigms and universal happiness in the world. And you may be aware of how in the last year (or so) there is a rollback of this euphoria - there are articles like “Broken by Design: MongoDB Fault Tolerance” and Why You Should Never Use MongoDB . The people on Habré on the Toaster are interested in “And why did they criticize Mongu?” , To which he received the answers “re-advertised”, “there is no silver bullet”, “you need to choose a database of tasks”.

All 3 obvious options - “Use a relational database”, “Use NoSQL-database”, “Select database by project tasks” I don’t like for the reason stated in the title of the article.

I will give an example. Just imagine: the start of a new large project, the administration collects all the developers and says, “So, we need to sit down now and decide which containers we will use in the code - arrays, vectors, lists, well, or maybe trees.” Stop! What kind of question is this? The project has not started yet - how do we know? And in general - most likely, in different places of the code one or the other will be used - well, where what will be more effective. “No, no,” says the bosses, “you need to select and approve right now, for example, a single-linked list as the only container used in the code.” What kind of nonsense ?! What for ?! "Well, that's the way it should be." A curtain.
')
Have you already felt the absurdity of this example? And now let's go back to our databases. Classic relational databases such as MySQL have known advantages:

• Relationality (thanks, cap)
• Imperfect but familiar to all and supported by all SQL
• Honest transactions on updating multiple tables

And NoSQL databases (I'm talking about the document-oriented part of them now) have their advantages:

• Quick document search by key
• Flexibility in changing the structure of the document
• Easier replication and sharding

At the same time, it is clearly seen that the advantages of one type of database are disadvantages of another type. So tell me - why at the start of the project should I choose between “washing hands with soap or drinking tea with sugar”? I want both of them!

I have data that can not be spoiled or lost in any case - this is data about users, financial transactions, something specific to my service. This will be in MySQL, protected by transactions, backed up with proven utilities. Let the operations change these data will work a little longer - the user will wait the extra half a second, but in 100% of cases he will see his money credited to the account.

I have the data that you need to search \ display quickly and also flexibly change. These are some likes, comments, metadata. I will not die if instead of “4358” in the “likes of this photo” field, “4357” will suddenly be displayed, due to the fact that, in one case in a million, Mongi’s transactional nature was lazy. But all of these 4357 (8) people had this field displayed half a second earlier, due to the fact that the document describing this photo was in Mong and was found faster in the sample.

So why just when starting any project (larger than “my cat Vaska’s home page”), not to raise both types of databases? Is it long or expensive to raise both bases?

For each data set, you can decide on the fly where to put it. One of the bases is not useful at all? Well, extinguish it at the end of development. Wrongly decided where to put some kind of data? Well, shift - both bases are available at any time. You can store two copies of the data, getting, when needed, the advantage of speed, and when you need reliability.

I will not ascribe to myself the authorship of this idea (even in the above question on the toaster, this idea was expressed). I would just like to slightly reduce the fear of the complexity of this task, to show that two different bases are not so bad. In a modern project several programming languages ​​can be used, many libraries of different styles, a whole zoo of patterns - so why can not there be several types of databases?

In general, it seems to me that in the future we will invariably see a mixed use of different types of databases in projects of medium and large scale. Personally, I propose to stop suffering right now - take the best from both types, avoid the disadvantages of both types.