What is MongoDb perfect for? Application examples where monga would be better than mysql?

Question

MongoDB

I read a bunch of habromysl and still want to ask? Can you give real examples when using mongo will be a more convenient and successful alternative to relational databases.
On Habré they wrote about a regular blog. But the discussion raised the issue of comments on blog entries, given that there are no relationships between tables in mongo,
help me understand)

Answer 1

I will tell you about personal experience, without claims to the ultimate truth ...

What is MongoDb perfect for? Application examples where monga would be better than mysql?

For a person who is used to working with relational databases, it is quite difficult to come to terms with logic and, in general, with similar databases. For those who work with relational databases professionally, it is even more difficult to do this...
When compared with relational databases and with an eye to MySQL specifically, monga fits perfectly where the data structure is not known in advance. Here I wanted to give an example, but I could not come up with a single practical example after I started working closely with PostgreSQL ... Let's try from practice. We once used mongu in a project where there are tens and hundreds of thousands of commodity items and each of them has its own unique set of different properties. Based on the already existing properties, "neighboring" products, the content creator was offered the most probable set of parameters that needed to be filled in, but at any moment he could remove or add any field and/or a set of values ​​for one of them, for example, "Color: black, gray , Violet". The whole thing fell under different dynamic filters and further along the chain ... At that time, As far as I remember, PostgreSQL did not yet have support for the JSONB format, so we settled on MongoDB. And of course, the desire to "plug an ultra new and fashionable database into the project" played its role...
What I definitely don't like about monge (and this is not my "idea", they even write about it in monge textbooks) is the total denormalization of data. Which in some cases can play a cruel joke. For example, all "post" comments are usually stored right in the post entity itself. It's very convenient and works quite fast, but... sometimes it leads to a complete collapse. Especially when you have cross-reference.
Of course, it is not uncommon to find projects in which even relational databases are not registered, for example, there are no foreign keys and data integrity control as such, but usually this happens for the following reasons:
1. Very low qualification of the project database administrator
2. In an attempt to squeeze out base more performance without finding other optimization methods
3. There is so much data that the database/keys start to “crumble”, this is often due to point 1.
Also, recent tests show that PostgreSQL is almost as good as MongoDB even in its native environment (at the data level in JSON format) . And in some aspects even surpasses it... You can see the details at some Postgres conferences (yes, at MongoDB conferences, you are unlikely to see someone say that [their favorite] monga is "worse" than some others engines...). By the way, support for the JSON format has been standardized (finally) at the level of the SQL standard (if I'm not mistaken) and in the very near future, I think we should expect full support for it in SQL databases, incl. support in binary form with the ability to index data (by the way, some SQL databases already know how to do this).
My understanding of the answer to the question "when is it really worth using MogoDB?" sounds something like this: Exclusively in those cases when you understand that it will be a really good solution for the task at hand both now and in the future. In my practice, such projects could be counted negligibly few, or rather, about zero, especially considering the development of some modern SQL databases and the direction of "JSON to SQL" in general. But, of course, such projects can and do exist (in this case, not for me). But, here it is worth paying attention to an extremely important fact - when such a project pops up, in order to adequately evaluate the most optimal database for it, you need to know at least a couple of SQL databases, with all their features, advantages and disadvantages ... and not just "to know", but it is good to know, "from within". And also to know all the characteristic features of Monga, as well as its features, advantages, etc. That is, if you're wondering "would monga fit well into Project N?" and you can not find a definite answer to it, most likely,
PS In conclusion, I want to remind once again that "JSON to SQL" is actively developing... With all the consequences.