Network Security Internet Technology Development Database Servers Mobile Phone Android Software Apple Software Computer Software News IT Information

In addition to Weibo, there is also WeChat

Please pay attention

WeChat public account

Shulou

Respective characteristics and comparison of Mongodb and MySQL

2025-02-24 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Database >

Share

Shulou(Shulou.com)06/01 Report--

The following together to understand the characteristics and comparison of Mongodb and MySQL, I believe we will certainly benefit a lot after reading, the text is not more refined, I hope Mongodb and MySQL respective characteristics and comparison of this short content is what you want.

In the data stored in the database, there is a special key called a primary key, which is used to uniquely identify a record in the table. That is, a table cannot have multiple primary keys, and primary keys cannot be null. Both MongoDB and MySQL have primary key definitions.

For MongoDB, the primary key name is "_id". When generating data, if the user does not actively assign a primary key to it, MongoDB will automatically generate a randomly assigned value for it.

In MySQL, primary key specification is defined by specifying PRIMARY KEY when MySQL inserts data. When the primary key is not specified, another tool, the index, acts as a substitute for the primary key. Index can be empty, there can be duplication, there is another index does not allow duplication called unique index. If neither a primary key nor an index is specified, MySQL automatically creates one for the data.

Storage speed comparison

Average insertion rate of database: MongoDB does not specify_id insertion> MySQL does not specify primary key insertion> MySQL specifies primary key insertion> MongoDB specifies_id insertion.

MongoDB has a big difference in speed between specifying_id and not specifying_id insertion, while MySQL has a much smaller difference.

Analysis:

When specifying_id or primary key, both databases process index values during insertion and find out if the same key exists in the database, which slows down the insertion rate.

In MongoDB, specified index insertion is much slower than unspecified, because the_id value of each piece of data in MongoDB is unique. When data is inserted without specifying_id, its_id is automatically calculated and generated by the system. MongoDB uses machine characteristics, time, process ID, and random numbers to ensure that the generated_id is unique. When specifying_id insertion, MongoDB needs to check whether this_id is available for each piece of data inserted. When there are too many pieces of data in the database, the query overhead of this step will slow down the insertion speed of the entire database.

MongoDB makes full use of system memory as a cache, which is a very good feature. Our test machine has 64 gigabytes of memory, and MongoDB tries to persist the data to hard disk as soon as possible after it runs out of memory. This is why MongoDB is so much more efficient when_id insertion is not specified. However, when the specified_id is inserted, when the amount of data is too large to fit in the memory, MongoDB needs to read the information in the disk into the memory to check the duplicate, so that its insertion efficiency is slow.

MySQL is indeed a very stable database, whether in the case of specified primary key or not specified primary key insertion, its efficiency is not much worse.

Insertion Stability Analysis

Insertion stability refers to the insertion rate per insertion of a certain amount of data as the amount of data increases.

In this test, we set the scale of this indicator at 10w, that is, the data displayed is how many pieces of data can be inserted per second during this period of time when 10w pieces of data are inserted.

Four pictures are presented first:

1. MongoDB specifies_id insert:

MongoDB does not specify_id insert:

3. MySQL specifies PRIMARY KEY insertion:

MySQL does not specify PRIMARY KEY insert:

Summary:

1. The overall insertion speed is similar to the previous statistics: MongoDB does not specify_id insertion> MySQL does not specify primary key insertion> MySQL specifies primary key insertion> MongoDB specifies_id insertion.

2. It can be seen from the figure that when the specified primary key is inserted into the data, MySQL and MongoDB will have a fluctuation in the inserted data every second when the data is of different orders of magnitude, and the spurs will be displayed as regular patterns in the chart. When inserting data is not specified, the insertion rate is average in most cases, but with the increase of data in the database, the insertion efficiency decreases momentarily in a certain period of time, and then becomes stable.

3. Overall, MongoDB's rate fluctuates more severely than MySQL's, and its variance varies greatly.

4. When MongoDB inserts at the specified_id, the insertion efficiency decreases significantly as the number of inserted data increases. In the other three insertion tests, the insertion rate was fixed at a standard most of the time from start to finish.

Analysis:

1. Glitch phenomenon is because when too much data is inserted, MongoDB needs to write the data in memory to the hard disk, and MySQL needs to re-divide the table. These operations are performed automatically whenever the data in the database reaches a certain magnitude, so there will be a significant glitch every once in a while.

MongoDB is still a new thing after all, and its stability is not as good as MySQL, which has been used for many years.

3, MongoDB in the specified_id insertion, its performance degradation is still very serious.

4. When the size of the data read is not large, MongoDB's query speed is really a ride away from MySQL.

When the amount of data queried gradually increases, MySQL's query speed is steadily decreasing, while MongoDB's query speed is somewhat fluctuating.

Analysis:

If MySQL is not query optimized, its query speed should not be compared with MongoDB. MongoDB can make full use of the memory resources of the system. The memory of our test machine is 64GB. The larger the memory, the faster the query speed of MongoDB. After all, the I/O efficiency of disk and memory is not the same magnitude.

2. The query data of this experiment is also randomly generated, so the probability that all the data to be queried exists in MongoDB's memory cache is very small. When querying, MongoDB needs to interact data in memory with disk many times in order to find it, so its query rate depends on the number of times it interacts. This makes it possible that, despite the large amount of data to be queried, this randomly generated piece of data is fetched from disk by MongoDB a smaller number of times. Therefore, the average query speed is faster. In this way, MongoDB's query speed fluctuation is also within a reasonable range.

The stability of MySQL is beyond doubt.

conclusion

Compared to MySQL, MongoDB database is more suitable for those task models with heavy reading tasks. MongoDB makes full use of the machine's memory resources. MongoDB queries are much faster if the machine is rich in memory resources.

2. MongoDB insertion efficiency is not high when inserting data with "_id". If you want to take full advantage of MongoDB's performance, it is recommended to insert without "_id" and then index the related fields for querying.

MongoDB is suitable for demand models where the specific data format of the database is unclear or the database data format changes frequently, and it is very friendly to developers.

4. MongoDB officially comes with a distributed file system, which can be easily deployed to Cloud Virtual Machine clusters. MongoDB has a concept of Shard, which is convenient for shards used for Cloud Virtual Machine. With each additional Shard, MongoDB's insertion performance increases by a factor of approximately, and disk capacity can be easily expanded.

MongoDB also comes with support for map-reduce computing framework, which is also very convenient for data statistics.

Flaws in MongoDB

1. Weak support for business relations. This is also a common flaw of all NoSQL databases, but NoSQL is not designed for transaction relationships, and specific applications are still very demanding.

2. There is some lack of stability, which can be seen from the above test.

MongoDB is convenient for developers on the one hand, but it puts forward quite a lot of requirements for operation and maintenance personnel on the other hand. The industry does not have mature MongoDB operation and maintenance experience, and the data storage format in MongoDB is also very random. Problems such as these are all tests for operation and maintenance personnel.

After reading the characteristics of Mongodb and MySQL and comparing this article, many readers will definitely want to know more about the relevant content. For more industry information, you can pay attention to our industry information column.

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.

Views: 0

*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.

Share To

Database

Wechat

© 2024 shulou.com SLNews company. All rights reserved.

12
Report