【MongoDB】What is MongoDB? What are the characteristics of MongoDB? What is the applicable scenario of MongoDB?

What is a MongoDB database?

MongoDB is an open source, high-performance document database that supports nautical data storage.

MongoDB is an efficient non-relational database (table relationship is not supported: only single table can be operated)

MongoDB is a product between relational databases and non-relational databases. It is the most functional among non-relational databases and is most similar to relational databases. The data structure it supports is very loose, and it is in the bson format similar to json, so it can store complex data. data type.

MongoDB is one of the NoSQL database products. Its storage type is similar to MySQL, and it can also be queried through a certain field; so some people say that it is a non-relational database that is most similar to a relational database (MySQL).

What are the characteristics of MongoDB database?

Data storage method: memory + disk

High scalability: achieved with built-in data sharding

Feature 1: The way of data storage - memory + disk

The client interacts with MongoDB for data, and MongoDB includes two parts, memory and disk;

        For the query, the first data operation of the client is to operate on the memory, and it will search in the memory first, so the query speed is very fast; if the memory is large enough, it can directly query in the memory to avoid and The disk interacts; if the memory is insufficient, it is necessary to find the data in the disk.

        For storage, the data operation performed by the client is directly stored in the memory, and the direct operation is the memory, so the storage speed is relatively fast and the efficiency is high.

There will be a problem involved here. Now that the data is in the memory, once the server is restarted or the power is cut off or down, the memory data will be lost?

        For, with the help of the mechanism of the operating system, the data in the memory will be automatically mapped to the disk, but there will be a time rule, which is written every 60s.

So can this solve the problem of data loss? of course not!

If the data has been written in the memory, but has not been synchronized to the disk, and the power is suddenly cut off at this time, the data that has not been synchronized for 60 seconds will be lost.

This also explains why MongoDB is more efficient, because it directly operates on memory. At the same time, MongoDB also has the risk of losing data, because it involves data synchronization between memory and disk, that is, the process of disk flushing.

To solve this problem MongoDB optimizes the structure.

Structural optimization

        MongoDB is also divided into two parts, memory and disk; but the difference is that memory and disk are divided into two parts, one is log files, and the other is real business data. When the client sends a request to the memory, it first logs the statement of the operation, and then writes it to the memory part of the business data. Then the log in the memory will synchronize the record data to the log of the disk every 10ms; and the business data part in the memory will also be synchronized to the business data part of the disk every 60s.

The advantage of doing this is that the range of data synchronization time is narrowed down.

        When the memory writes data through log records, it suddenly crashes. Although the memory and disk will lose 60s of data; but the data synchronization between logs is set to a shorter time of 10ms. When the server restarts, the disk logs will be Comparing the file part with the business data part will find out the lost data and perform data recovery;

        The only downside is that although the synchronization data time is shortened, 10ms of data will still be lost. No matter how hard you try MongoDB will lose data for a period of time;

        In general, the first feature of MongoDB is to store data in memory + disk; the client basically operates on memory, and behind the scenes, the operating system synchronizes the data in memory with the disk, which may cause data Lost; since all operations are in memory, the efficiency of read and write operations is relatively high.

Feature 2: High scalability—realized by built-in data sharding

This often happens when we use MongoDB:

        Due to the limited storage capacity of its own hard disk, MongDB may not be able to store redundant data; what should we do at this time? MongoDB can use built-in data fragmentation to connect multiple MongoDB servers in series, and each server stores a part, so that the amount of stored data increases;

For example, there are three MongoDB servers A, B, and C, and each server can support 500GB, so the three servers can store 1.5TB of data in series;

In this way, using MongoDB's built-in data sharding can easily save massive amounts of data. This also laid the foundation for MongoDB's massive data storage. Of course, MySQL also supports data sharding, but it requires third-party services and components, and the implementation cost is relatively high.

 The two characteristics of data storage and high scalability explain MongoDB's high performance and massive storage support.


What is the applicable scenario of MongoDB?

1. Game industry: game equipment data, game props data

        These data are modified extremely frequently, and there are many data.

2. Logistics industry: geographic location information, massive data

        Multiple geographical location information are connected in series to display its trajectory on the map. The amount of data in the logistics industry is extremely large, and the address location coordinate information is continuously saved to the database. At the same time, saving these coordinate information also has many application scenarios, such as searching for nearby people

3. Live broadcast industry: live broadcast data, fan data, reward data

        The modification frequency of these data is extremely fast, and the amount of data is also extremely large.

4. Log data

        Some key logs in the project need to be saved, and the data volume of the logs is also huge, and the structure is changeable.

If you meet the above requirements, you can save the data in the MongoDB database.


Guess you like

Origin blog.csdn.net/zsy3757486/article/details/130209352