Explain why we need document-oriented databases (MongoDB)?

Question

MongoDB

Subject. That's what I don't understand. Please provide more practical application solutions. For the business sector, for example.

Answer 1

The point of relational databases was once only to give an answer to _any_ question in _any_ amount of time. Those. for example, there is some kind of database in the company and you need to make some kind of report.
In Internet applications, things are somewhat different. Most often, queries to the database are the same with rare exceptions (search). BigTable and others are tied to this principle, creating an index on the necessary queries when changing data asynchronously.
Thus, after changing the data, the indexes for the necessary queries are immediately updated. SQL also has indexes, but they are at a lower level.
MongoDB builds indexes automatically on the first request. Therefore, it is very similar to the lang <-> memcache <-> sql scheme. But an order of magnitude faster, because mongodb itself is faster than memcached (I myself have not checked this yet and hardly believe it, but everyone unanimously says that this is so).
The second bonus is simpler replication. In particular, the same mongodb has the concept of master-slave and shards at its very heart.
The third bonus is map/reduce for data processing. They are executed in the built-in language (for mongodb it is spidermonkey, i.e. javascript).
In general, an application originally written in mongodb will theoretically be faster than the SQL version. At least with a fast implementation like MongoDB.

Answer 2

If we abstract from such “little things” as performance, scalability and reliability, then D (document) O (oriented) DBMS and O (object) O (oriented) DBMS in many cases allow the developer to reflect the entities of the subject area on the entities of the database without introducing additional entities :), which have to be entered into the R (relational) DBMS. For example, how many copies are broken in disputes about how to store objects of various classes inherited from one base class in RDBMS (in one table with a bunch of empty fields, in tables for each individual class, in a common table with common fields, ...), but here we just store it in one “table” and don’t think about such trifles. Relationships 1:1 and 1:M, when entities in the second half of the relationship belong to one and only one entity of the first and do not make sense without it, they are also displayed without additional tables and fields for communication (instead of comments.post_id and comments.content, we simply store a list / array of comments in the posts.comments field, not taking care of the integrity of links, synchronization, etc.). In other words, DDBMS often make life easier for the developer, although sometimes they complicate it (when the links are bidirectional, first of all, especially M: M - to establish a connection between two existing entities, two operations must be performed - adding a link to the first to the second, and to the second to the first -, and not one - adding to the link table - as in RDBMS) not caring about the integrity of links, synchronization, etc.). In other words, DDBMS often make life easier for the developer, although sometimes they complicate it (when the links are bidirectional, first of all, especially M: M - to establish a connection between two existing entities, two operations must be performed - adding a link to the first to the second, and to the second to the first -, and not one - adding to the link table - as in RDBMS) not caring about the integrity of links, synchronization, etc.). In other words, DDBMS often make life easier for the developer, although sometimes they complicate it (when the links are bidirectional, first of all, especially M: M - to establish a connection between two existing entities, two operations must be performed - adding a link to the first to the second, and to the second to the first -, and not one - adding to the link table - as in RDBMS)

Answer 3

Well, one of the nice features of mongo is not to produce relationship tables, but to have honest lists for many-to-many. The second possibility is to store data of a different type as a value.

Answer 4

Such databases are quite in demand where high performance is required, because the performance of MongoDB is an order of magnitude higher than that of relational databases. You can read more about the pros and cons here .

Answer 5

blog.wordnik.com/12-months-with-mongodb
Case Study

Answer 6

To store documents.