Shulou(Shulou.com)05/31 Report--

This article shows you what MongoDB means. It is concise and easy to understand. It will definitely brighten your eyes. I hope you can get something through the detailed introduction of this article.

A brief introduction to MongoDB

MongoDB is a high-performance, open source, schemalless document database, which is one of the most popular NoSql databases. It can be used to replace the traditional relational database or key / value storage in many scenarios. Mongo is developed using C++. The official website address of Mongo is http://www.mongodb.org/, where readers can get more detailed information.

Episode: what is NoSql?

NoSql, whose full name is Not Only Sql, refers to a non-relational database. The next generation database mainly addresses several key points: non-relational, distributed, open source, and horizontally scalable. Originally intended for large-scale web applications, the campaign began in early 2009 with features such as: free mode, support for easy replication, simple API, ultimate consistency (non-ACID), large-capacity data, etc. NoSQL is most used by us when key-value storage, of course, there are other document, column storage, schema database, xml database and so on.

Features:

High performance, easy to deploy, easy to use, very convenient to store data. The main functional features are:

For collection storage, it is easy to store data of object type.

Mode freedom.

Dynamic query is supported.

Full indexing is supported, including internal objects.

Query is supported.

Replication and failure recovery are supported.

Use efficient binary data storage, including large objects such as video, etc.

Automatically handle fragments to support scalability at the cloud computing level

Drivers for Python,PHP,Ruby,Java,C,C#,Javascript,Perl and C++ are supported, and drivers for platforms such as Erlang and .NET are also available in the community.

The file is stored in BSON (an extension of JSON).

Can be accessed through the network.

Features:

Collection-oriented storage: suitable for storing objects and data in JSON form.

Dynamic query: Mongo supports rich query expressions. Query instructions use tags in the form of JSON to easily query objects and arrays embedded in a document.

Complete indexing support: including document embedded objects and arrays. Mongo's query optimizer parses the query expression and generates an efficient query plan.

Query monitoring: Mongo includes a monitoring tool for analyzing the performance of database operations.

Replication and automatic failover: Mongo database supports data replication between servers, master-slave mode and mutual replication between servers. The primary goal of replication is to provide redundancy and automatic failover.

Efficient traditional storage: supports binary data and large objects (such as photos or pictures)

Automatic sharding to support cloud-level scalability: the automatic sharding feature supports horizontal database clusters and can dynamically add additional machines.

Applicable occasions:

Website data: Mongo is very suitable for real-time insertion, update and query, and has the replication and high scalability required for website real-time data storage.

Caching: due to its high performance, Mongo is also suitable as a cache layer for the information infrastructure. After the system restart, the persistent cache layer built by Mongo can avoid the data source overload of the lower layer.

Large-size, low-value data: it may be expensive to use traditional relational databases to store some data. before that, programmers often choose traditional files for storage.

Highly scalable scenario: Mongo is ideal for databases consisting of dozens or hundreds of servers. Mongo's roadmap already includes built-in support for the MapReduce engine.

For object and JSON data storage: Mongo's BSON data format is very suitable for document format storage and query.

In the overall domestic environment, the flow of MongoDB in small and medium-sized companies is much higher than that of other Nosql.

Why not?

1) MongoDB defaults to unsafe writing in order to win the Benchmark test.

If you do not call getLastError (), MongoDB will not return after confirming that the database write is complete, which introduces at least two problems:

In a concurrent environment (connection pooling, etc.), continuous read operations after a read operation is "completed" can go wrong, and MongoDB does not have a "fence condition lock" to know when to finish writing.

An unknown number of save operations will be discarded because the queue for save operations will be in different places. Such as TCP cache and so on. When you disconnect from the database because of some meaning, these things are discarded.

10gen CTO replied: this has nothing to do with Benchmark, and said that this is the design of API, it is up to users to choose, because there are many ways to write.

2) MongoDB can lose data in shocking ways

Here is a list of its missing data that we have experienced:

The data is lost, and the reason is unknown.

It was not successful to recover data from a corrupted database, such as the transaction log.

There is a gap in the data replication between the master and slave nodes, which leads to the loss of the data of the master node. Yes, there is no CheckSum, and yes, you will also see the current state where the replication status is "slave node".

Data replication sometimes stops without errors. You need to monitor your replication status!

10gen CTO replied one by one: 1) there has never been a data loss of BUG we do not immediately fix things. Can you tell me the problem number you gave us? We need to at least understand what's going on. If it's our problem, we'll fix it right away. 2) isn't it normal that you can't fully recover data from a corrupted database? But it would be better to have master and slave servers backing up each other. 3) Please tell me your problem number, we have never received such an error report. If there is, it is indeed very serious. 4) if there is no notification when the error condition occurs, it is possible. In addition, you can monitor the write operation of data replication, and you can use Word2 as the parameter of getLastError.

3) MongoDB needs a global write lock to request a write operation

When writing frequently, this is tantamount to killing you. If you run a blog, you may not care about it because you are not good at reading and writing.

10gen CTO replied: read-write locks are always a problem, but 2.0 will be much better, and 2.2 will solve it better.

4) Sharding (partition) of MongoDB will stop working under high load

Adding a shard under high load is a nightmare. Mongo either moves its data blocks too fast, causing DOS attacks to generate a lot of traffic that takes up bandwidth, or it rejects more blocks altogether. This will make a high-traffic website bear a heavy write operation.

10gen CTO reply: if the system has exceeded its load, then moving data will of course become very difficult. Every time I give a speech, I make it very clear that don't add shard when the system performance is not good. It won't work.

5) Mongo is unreliable

The architecture of the Mongod/ configuration server / mongos is indeed reasonable and smart. Unfortunately, mongos is completely rubbish. Under a load, it crashes from time to time, sometimes for hours, sometimes for days. Process restart monitoring sometimes doesn't work because it throws assertions to spoof a critical thread, leaving the process still running. Double Fail .

Worst of all, the only viable way is to put a HaProxy (a load balancer) in front of a bunch of mongos instances, run a job to slowly access these mongos instances, and kill them regularly so that new instances can be restarted. I'm not kidding.

10gen CTO replied: this is impossible. Can you tell me more details?

6) MongoDB even deleted the entire database once

MongoDB 1.6. in a data synchronization configuration, an incorrect node (often an empty node) is sometimes configured as the latest data node. So the data on the other synchronized data nodes is wiped out (I'm talking about the good data of 700GB), because it synchronizes the data of this empty node back to the node with data. The database should never do this. If this problem occurs, the database should throw an error and let DBA choose a reasonable operation, or force the correct configuration. You shouldn't delete all the data (it was a bad day).

They fixed this problem in 1.8. Oh, my God.

10gen CTO reply: can not find such a thing, also can not find the corresponding submitted code, can you give more information?

7) released something that should not be released.

As we all know, finding some embarrassing bug in the stable version can lead to data problems-and they always tell us about them after we have a problem, because we bought 10gen's platinum support for their super fraud. They responded by sending us a hot patch, something they called RC internally, and then having the hot patch run on our data.

10gen CTO replied: with regard to platinum technical support, all the issues we have taken over will be made public, and so will fix. There is no specific situation, this kind of thing is difficult to discuss. We will respond differently according to different circumstances. We hope that the problems of our users can be solved as soon as possible.

8) the replicator is overshadowed by the busy server

The replicator often launches DOS attacks on Master, or replicates very slowly, takes a very long time, and oplog is almost exhausted (even 50GB's oplog).

We have a busy, large data set, and we won't copy it because it's dynamic. It was a painful month, or we need to cross our fingers before choosing a different database system.

10gen CTO replied: it looks like the server is overloaded. I mentioned it earlier.

But the worst problem is:

You might say that my problems are all in the past; they have fixed all these problems or they will fix them in the next version; the X problem can be mitigated with Y practice. Wait, wait.

Unfortunately, it's useless for you to say these things.

The real problem is that so many questions are first and foremost. Database developers should be able to hold to a higher standard than the average programmer. In other words, your priority should look like this:

Don't lose the data, be completely sure of the data

Ensure availability through practice

Performance scalability of multiple nodes

The minimum delay should be kept between 99% and 95%

Requests per second per resource

The order of 10gen seems to be # 5 is the first, other items are casual, # 1 is not in the top 3.

10gen CTO replied: this is obviously not true. Take a look at the code we submitted and look at our fix. We never hide a bug in the release version. If we care a lot about performance benchmark, we will put effort into solving those lock problems, so that multithreading concurrency will be faster.

MongoDB is a new thing, and there are a lot of things that need to be polished. If you want to come and get to know us, you are welcome to meet us.

These failures, and the company's implied priority, point to a fundamental problem with corporate culture, which can cause problems in any release: because they lack design rules that respect the necessary database systems.

What does MongoDB mean? have you learned any knowledge or skills? If you want to learn more skills or enrich your knowledge reserve, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.