Why you should never say "never"

This publication of my little bit more than fully responds to the translation of the article “Why You Should Never Use MongoDB . ” The article, which, in fact, recommends staying away from MongoDB, is the most unsubscribed in the hub. And that sounds like a sentence. Therefore, it is logical to either close the hub and never read it again, or write an even more rating refutation. Of course, I chose the second option, risking my rating and karma (due to extreme holivarity in the comments).

Self-irony picture

Database selection

Referring to authoritative sources "some claim" and "others say", the author justifies his choice of database. Maybe I want too much, but it would be great to wrap up these “sources” with links to official recommendations from the developers of the mentioned databases.

But what are the alternatives? Some argue that graph databases are best suited, but I will not consider them, since they are too niche for mass projects. Others say that documentary data is ideal for social data, and they are fairly mainstream for real use. Let's take a look at why people think that MongoDB is much better suited for social data than PostgreSQL.

The statement that graph databases are too niche (???) for mass projects (???) working with social graphs is very difficult to justify even with the most authoritative source. From my own experience, I can say that graph bases, despite their name, work fine with graphs (including social graphs). Of course, you should not take graph databases as the main data repository. For these purposes, such tools as MySQL, MongoDB, Postgres, etc. remain indispensable. Similarly, when we need, for example, full-text search, we use Sphinx in conjunction with the main data repository, rather than making a painful choice between it, Redis and MariaDB.
')

Data modeling

To learn how to properly model data in MongoDB, you can read in the official manual . Usually, it is desirable to do this before you subscribe to the project and authoritatively propose architectural solutions and tools for their implementation. Yes, even if there are 40 pages in the document - you still need to read. Otherwise, you can easily overwhelm a project with an inept choice or inept use of good tools. And to write large articles with funny pictures that the compote is awkward with a fork.

We could also model this data as a set of nested objects (a set of key-value pairs). A lot of information about a particular series is one big structure of nested key-value sets. Inside the series, there are many seasons, each of which is also an object (a set of key-value pairs). Within each season, an array of episodes, each of which represents an object, and so on. So in MongoDB model the data. Each series is a document that contains all the information about one series.

The show has a name and an array of seasons. Each season - an object with metadata and an array of episodes. In turn, each episode has metadata and arrays of reviews and actors.

If Sarah had read the data modeling guide in MongoDB, then she would know that in this database one can work with more than one data model. But actually, I have one very simple question: did the author ever hold a calculator in her hands? About Google and Wikipedia will not even ask. What is it for me? Let's google the longest series. This masterpiece, entitled Guiding Light , contains 18.262 series of diversity and philosophy. In its background, Santa Barbara, with its 2.137 series, is a white dwarf in the starry sky of cinema. But this is all the lyrics. Now I’m getting bored again, and I assert that before you make a database choice authoritatively, you must not only become familiar with the recommended data storage models, but also with the limitations of this database. One of these limitations is the maximum document size, which cannot exceed 16 MB . And now we take in hand a calculator, hold the power and make a magic calculation, which I read in the book of spells DBA Architect:

16  / 18.262  = 876 //   

. , ! , (!!!) . , , ? , , .

C , - .

, Diaspora, . , .

, . , . «best practice» Diaspora, , . , ? , , . . Skype , , . ! , ?

, . , , Aggregation Framework. , , , , Sisi:

db.actors.aggregate( [
   { $match : { name: "Sisi" } }
   { $group : { _id : "$movieId", count: { $sum : 1 } } },
   { $group : { _id : null, avgMovieCount : { $avg : "$count" } } }
] )

, . MongoDB ORM ODM. , (lazy loading). , , MapReduce. , .

MongoDB. , . . , .

Web 3.0, , . , , . .

. ?

. , : . , . , , , .

, . , , , , . , — , . .

, MongoDB.

cleg:

« » :
—
—
—

, - —

? ? , ? ? , , «». . , , , , . - , . , . , -, , - , MySQL, , , , .

gandjustas:

. (), . — , . — .

? .

. . schemaless, , . — . , — , . . , , — 100 ? MongoDB , . , schemaless. MongoDB . .

, , . . best practice. . .