Summary of the advantages and disadvantages of MongoDB and MySQL

Compared with relational databases, the advantages of MongoDB:
①Weak consistency (eventually consistent), which can better guarantee the user’s access speed:
For example, in a traditional relational database, a COUNT operation locks the data set so that the exact value in the “current” situation is guaranteed. This in some cases, such as
For example, it is very important to check the account information through ATM, but for Wordnik, the data is constantly updated and growing.
Late. What they need is an “approximately” number and faster processing speed.

But in some cases MongoDB will lock the database. If there are hundreds of requests at this point, they can pile up and cause a lot of problems. We use the following optimization to avoid locking:
Before each update, we will first query the records. Query operations place objects in memory, so updates are as fast as possible. In a master/slave deployment scenario, the slave nodes can be run with the “-pretouch” parameter, which also achieves the same effect.
Use multiple mongod processes. We split the database into multiple processes based on access patterns.
②The storage method of the document structure can obtain data more conveniently.
For a hierarchical data structure, if such data is to be stored in a flat, tabular structure, it is very difficult to query or obtain data.
Example 1:
Take a “dictionary item” as an example, although it is not very complicated, it will still be related to “definition”, “part of speech”, “pronunciation” or “citation”. Most engineers will use this model with a relational database
The primary and foreign keys in , but wouldn’t it be better to think of it as a “document” rather than a “series of related tables”? use
“dictionary.definition.partOfSpeech=’noun'” to query is also more convenient than a series of complex (and often expensive) join queries between tables
And fast.

Example 2: In a relational database, a blog (including article content, comments, and comment votes) will be scattered in multiple data tables. In MongoDB, a blog can be represented by a document,
Comments and votes are placed in the main body document as document arrays. In this way, the data is easier to manage, and the “JOIN” operation that affects performance and horizontal scalability in traditional relational databases is eliminated.

CODE↓
> db.blogposts.save({ title : “My First Post”, author: {name :
“Jane”, id :1},
comments : [{ by: “Abe”, text: “First” },

{ by : “Ada”, text : “Good post” }]
})

> db.blogposts.find( { “author.name” : “Jane” } )

> db.blogposts.findOne({ title : “My First Post”,
“author.name”: “Jane”,
comments : [{ by: “Abe”, text: “First” },

{ by : “Ada”, text : “Good post” } ]
})
> db.blogposts.find( { “comments.by” : “Ada” } )

> db.blogposts.ensureIndex( { “comments.by” : 1 } );
Example ③:
MongoDB is a document-oriented database currently developed and maintained by 10gen. It has rich and complete functions and can completely replace MySQL. In the process of using MongoDB as a product prototype, we summarized some highlights of MonogDB:
Use JSON-style syntax, easy to grasp and understand: MongoDB uses JSON variant BSON as the internal storage format and syntax. Operations for MongoDB use JSON-style syntax, and the data submitted or received by the client is displayed in JSON format. Compared with SQL, it is more intuitive, easy to understand and master.
Schema-less, supports embedding sub-documents: MongoDB is a Schema-free document database. A database can have multiple Collections, each
A Collection is a collection of Documents. Collection and Document are not equivalent to Table and Row in traditional databases. no prior definition
Collection, ready to create.
Collections can contain document records with different schemas. This means, the document in your last record has 3 attributes, and the document in the next record can have 10 attributes
property, the type of the attribute can be either a basic data type (such as a number, a string, a date, etc.), an array or a hash, or even a sub-document (embed document). this
In this way, a denormalizing data model can be implemented to improve query speed.

③Built-in GridFS supports large-capacity storage.
GridFS is an excellent distributed file system that can support massive data storage.
Built-in GridFS and MongoDB, which can meet the fast range query on large data sets.
④ Built-in Sharding.
Provide Range-based Auto Sharding mechanism: a collection can be divided into several segments according to the range of records, and divided into different Sharon d.
Shards can be combined with replication. With Replica sets, Sharding+fail-over can be realized, and load balancing can be achieved between different shards. query is right
Clients are transparent. The client performs queries, statistics, MapReduce and other operations, which will be automatically routed to the back-end data nodes by MongoDB. This allows us to focus on our business, where appropriate
Time to upgrade painlessly. The Sharding design capability of MongoDB can support up to about 20 petabytes, which is enough to support general applications.
This ensures that MongoDB runs on clusters of cheap PC servers. PC clusters are very convenient and cost-effective to expand, avoiding the complexity and cost of “sharding” operations.

⑤ Abundant third-party support. (This is an advantage that MongoDB also has compared to other NoSQL)
Many NoSQL open source databases on the Internet are completely community-based and have no official support, which brings great risks to users.
The open source document database MongoDB is backed by the commercial company 10gen to provide commercial training and support.
Moreover, the MongoDB community is very active, and many development frameworks quickly provide support for MongoDB. Many well-known large companies and websites are also using MongoDB in the production environment, and more and more innovative companies are turning to MongoDB as a technical solution to match Django and RoR.
⑥Excellent performance:
In the use case, with tens of millions of document objects and nearly 10G of data, the query of indexed IDs will not be slower than mysql, while the query of non-indexed fields is an overall win.
mysql is actually not capable of querying any field under a large amount of data, but the query performance of mongodb really surprised me. The write performance is also very satisfactory, and the data of millions of levels is also written
According to reports, mongodb is much faster than the couchdb I tried before, and it can be solved in less than 10 minutes. To add one more sentence, mongodb is far from being a CPU killer during the observation process.

Compared with relational databases, the disadvantages of MongoDB:
①mongodb does not support transaction operations.
So a system with strict transaction requirements (such as a banking system) must not use it. (This corresponds to advantage ①)
②mongodb takes up too much space.
Regarding the reasons, in the official FAQ, the following aspects are mentioned:
1. Space pre-allocation: In order to avoid excessive hard disk fragmentation, mongodb will apply for a large hard disk space every time the space is insufficient, and the amount of application varies from 64M, 128M, and 256M
The number of samples increases exponentially until 2G is the maximum size of a single file. As the amount of data increases, you can see these files in the data directory that are generated as a whole and the capacity is increasing.

2. The space occupied by the field name: In order to keep the structural information in each record for query, mongodb needs to store the key-value of each field in the form of BSON, if
The value field is not larger than the key field. For example, when storing numerical data, the data overhead is the largest. A way to reduce the space occupied is to make the field name as short as possible, so that
The space is smaller, but this requires a trade-off between legibility and space occupation. I once suggested that the author make the field name an index, and each field name is represented by one byte, so that there is no need to worry about the length of the field name
up. But the author’s concern is not unreasonable. This index method needs to replace the index value with the original value after each query results, and then send it to the client. This replacement is also quite time-consuming. The current realization is
Trade space for time.

3. Deleting records does not free up space: It is easy to understand. In order to avoid large-scale movement of data after record deletion, the original record space is not deleted, but only marked as “deleted”, which can be reused in the future.

4. You can run db.repairDatabase() regularly to organize records, but this process will be slow

③MongoDB does not have as mature maintenance tools as MySQL, which is worth noting for both development and IT operations.