Why should you never use MongoDB again

Sven Slootweg (joepie91) is a hacker and founder of CRYTOCC and now provides the node. JS Code Review Service. Recently, he published a blog post on the "Why you should never, never, never again use MongoDB." In the article, he cites the following reasons:

• Loss of data (see 1, 2);
• The default ignores errors, assuming that each write is successful on a 32-bit system, which can cause data to be silently lost;
• Even under the applicable scenario of MONGODB propaganda, its performance is still not high (see 3, 4);
• In almost all scenarios, developers will be forced to develop bad habits using implicit patterns (see 4);
• There is a lock problem (see 4);
• Response to security issues is slow (see 5);
• does not conform to acid (see 6);
• Expansion and maintenance difficulties;
• JSON storage is also not a unique feature of MongoDB, PostgreSQL, COUCHDB also support (see 7, 8).

Joepie91 believes that MongoDB not only has many problems, but also has no prominent place. If the project involves a user account or a relationship between the two records, then the relational database should be used instead of the document store, and if the project is using mongoose, then the relational database should also be used, because mongoose only uses the document store to simulate a schema-based relational database. As a result, most situations actually require a relational database. In these cases, PostgreSQL is a good option. Developers can use the Query Builder or ORM to simplify the process, for example, in node. js, you can choose Knex, Bookshelf, sequelize, or waterline. Even if you really need a document store, there are better options than MongoDB. In addition, he does not think MongoDB is suitable for creating prototypes, because if the production environment uses a different database, then all the code needs to be rewritten. In short, MongoDB does not have any applicable scenarios. It is technically inferior to other options, does not provide unique features that are truly useful, and developers are unable to ensure data consistency and security. Finally, joepie91 points out that popularity is not the same as quality, only that the product has a good marketing team:

Never use a database for the "other person to do it", for a particular database, to study its advantages and disadvantages.

Joepie91 's view was broadly endorsed in hack news. Netizen Karmakaze also believes that, with PostgreSQL 9.4, there is no reason to use MongoDB (jsonb than Bson), in addition to the use of couchdb. For the specific limitations of MongoDB, Netizen Giaour recommends reading Aphyr's series of call Me maybe, and points out that although there are known workarounds, it greatly reduces the MongoDB development experience. Netizen Animats thinks, if the traffic of the site is smaller than wiki, then use some kind of relational database to be able. Netizen Pebbleshd has a similar view:

As a small deployment ..., just install a basic MySQL What's the problem? On our internal wiki, we've visited more than 20,000 times a day ...

But there are some different voices. For example, netizens threeseed that MongoDB is still one of the easiest databases to install and use. In response, Joepie91 replies to the following:

To do things in the wrong way, it is not easy to--mongodb that happens to be done. It does not need to set authentication or table mode, so it appears "easy to install." But in fact, in order to save 10 minutes, you are wasting a few hours of time. Because later, you will encounter intrusion (no authentication) or data corruption ...

Shodan's report also confirms Joepie91 's assertion that nearly 30,000 MongoDB instances on the Internet have no authentication enabled. This problem is ubiquitous and has existed for many years.

Netizen Toyg commented that:

I recently used MongoDB for the first time in an internal project. I think that no pattern really significantly improved the speed of development ... Now that the project is ripe and back, I can see why the relational database would be more appropriate, but if I used the RDBMS from the start, I might not be able to complete the migration so quickly. Although switching to a real RDBMS means modifying 32 classes, it doesn't change much. So, I don't agree that MongoDB is not suitable for prototype development.

Joepie91 questioned the idea of "modifying 32 classes, but not much," because migrating to different databases often requires a lot of work, based on the experience of doing code reviews. As for the switching speed, joepie91 points out that in a system with a rollback mechanism, it may be faster.

In some cases, however, the developer has no other choice. For example, a netizen put forward, meteor is used and can only use MongoDB. And because of its partnership with Hadoop, MongoDB is well integrated with Hadoop, so it is very popular in the field of big data analytics.

In addition, Eric Sink, a software developer from SourceGear, said after reading the joepie91 article:

The part (and perhaps all) of what he has enumerated is indeed true. In fact, now, let's assume that what he writes is correct. I'm not here to say that the author is wrong. Rather, I would like to point out that this blog post only makes me understand very little about MongoDB, but it makes me feel a lot of the emotions of the people who write this blog post.

He felt that it was impossible to deny MongoDB outright because of those problems, after all:

MongoDB is the top NoSQL provider. Every day, tens of thousands of businesses use it to serve millions of users. Like all new-born software with a large number of users, it has flaws and flaws. But it is steadily improving. Any discussion of technical flaws, if not helping to solve the problem, can only be a vent to a large extent.

This article originally published in Infoq, the article content is the author's personal opinion, does not represent the site position.

Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced.

Why should you never use MongoDB again