Nosql Database: Eight sins of MongoDB inventory

[It168 comment] for some political reasons, I have been silent on this issue for some time, but now I feel it is my responsibility to stand up and tell people who want to use MongoDB in their businesses with my own experiences.

Our team has used MongoDB in a large project (tens of millions of users). Based on our early experiences, we hope we can use it as the 10gen company touches, through long-term use, we can get the scalability benefits they have advertised, but it turns out that we are wrong. I think it is necessary to share our lessons, even if only one person gains from them, I think it's worth it. It should be noted that 10gen did their best and enthusiastically help us, sometimes even excited, but this does not prevent my criticism of their failed products.

　1. MongoDB writes data in an insecure way by default to win Benchmark Testing.

If you do not call getlasterror (), MongoDB will return the result before the write operation is completed. This will cause two problems:

In a concurrent environment (such as a connection pool), if you perform a write operation and then read the data you just written, a read error may occur, and you cannot know when the database will complete this write operation.

In many cases, the storage operations in the queue will be discarded, and you will not receive any notifications, such as connection interruption, database crash, or other unexpected situations, the operation stored in the TCP cache disappears.

2. MongoDB will lose your data in a lot of inexplicable ways

The data suddenly disappeared and I don't know why.

The damaged database cannot be recovered.

There is a gap between the backup of the master node and the slave node. As a result, some data is often missing from the slave node. Yes, there is no checksum, And the backup status shows that the data on the slave node is synchronized.

Backup often does not work and there are no errors. You need to monitor your backup status on your own.

　3. A global lock is required to send a write request.

　　4. MongoDB sharding does not work properly when load is involved.

Adding a shard to a high load is a nightmare. Mongo either moves data blocks between partitions too quickly, turns it into a DoS attack on itself, or rejects more blocks.

　　5. Mongo has no reliability at all.

Mongod/configuration server/mongos architecture is indeed very clever, but unfortunately, mongos is completely spam, it will crash at any time in case of load, a few hours short, A few days later, and restarting the management process is sometimes useless. Sometimes it throws assertions to destroy a key thread, but the process is still running.

Guess what, the only feasible way is to configure a haproxy in front of mongos, then start an external supervision program to poll mongos, regularly clear old instances and create new instances. That's right, that's it. No joke.

　　6. MongoDB even deleted the entire database once.

MongoDB 1.6, after the backup is configured, sometimes the data of a new node is treated as the latest data by mistake, delete all the data of all other nodes (about GB of good data is deleted), and synchronize the empty data to all other nodes as a database, this kind of thing should never happen. If you are not sure, ask the Administrator to select an appropriate operation instead of deleting all the data.

Fortunately, this bug was fixed in 1.8.

　7. They always deliver something that should not be delivered at all.

An embarrassing fact is that even a stable version has bugs that damage data-and it is always discovered after our data is damaged-We bought 10gen platinum support, but what we get is a bunch of hot patches called internal RC that run directly on our data.

　8. replication is basically a waste of wood on busy servers.

Backup often does not work, either it is the DOS master, or it consumes too much time until oplog is consumed (even if oplog has 50 GB space ).

However, these are not the main issues:

You may say that these are all old calendars. They have fixed these problems in the latest version, but this is not what I want to say. What I want to express is that as a database development company, they should sort their priorities in the following order:

1. data cannot be lost, ensuring data reliability

2. Ensuring accessibility through practice

3. multi-node scalability

4. Reduce latency to 99% and 95%

5. Requests per second for a single resource

The sorting of 10gen seems to be #5, which is the first. The sorting of other items is unknown, but it is certain that the first one is not in the first three of them.

Finally, I hope you will take the above warning into consideration.