Advantages and disadvantages of MongoDB versus MySQL

The advantages of MongoDB compared to relational databases:① Weak consistency (eventually consistent), to ensure the user's access speed: For example, in a traditional relational database, a count type of operation locks the dataset so that the exact value in the "current" case can be guaranteed. This is important in some cases, such as checking account information through ATM, but for Wordnik, the data is constantly being updated and growing, and this "precise" guarantee has little meaning, but can have a significant delay. What they need is a "about" number and faster processing speed. However, in some cases MongoDB will lock the database. If there are hundreds of requests at this point, they will accumulate and cause many problems. We have used the following optimizations to avoid locking: We will check the records before each update. The query operation puts the object into memory, so the update is as fast as possible. In a master/slave deployment scenario, the from node can be run with the "-pretouch" parameter, which can also have the same effect. Use multiple Mongod processes. We split the database into multiple processes based on the access pattern. The ② document structure is stored in a way that makes it easier to get data. For a hierarchical data structure, if you want to use a flat, tabular structure to hold the data, it is difficult to query or retrieve data. Example 1: Take a "dictionary item", although not very complex, but it will be related to "definition", "part of speech", "pronunciation" or "citation" and so on. Most engineers would use this model as a primary key and foreign key in a relational database, but wouldn't it be better to think of it as a "document" rather than a "series of relational Tables"? Using "dictionary.definition.partofspeech= ' noun '" to query is also easier and faster than a series of complex (and often costly) connection queries between tables. Example 2: In a relational database, a blog (a poll that contains the content, comments, and comments) is scattered across multiple data tables. In MongoDB, you can use a document to represent a blog, comments and polls as an array of documents, placed in the main body document. This makes data easier to manage and eliminates "JOIN" operations that affect performance and horizontal scalability in traditional relational databases. 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 3: MongoDB is a document-oriented database, currently developed and maintained by 10gen, it is rich in functionality, complete, can completely replace MySQL. In the process of using MongoDB to prototype a product, we summarize some of the highlights of Monogdb: Using JSON-style syntax, easy to grasp and understand: MongoDB uses the variant Bson JSON as the internal storage format and syntax. The JSON-style syntax is used for MONGODB operations, and the data submitted or received by the client is presented in JSON form. Compared to SQL, it is more intuitive, easy to understand and master. Schema-less, supporting embedding of sub-documents: MongoDB is a schema-free document database. A database can have multiple collection, and each collection is a collection of documents. Table and row for collection and document and traditional databases are not equivalent. No need to define Collection in advance, can be created at any time. Collection can contain document records with different schemas. This means that the document in your previous record has 3 properties, and the next document can have 10 properties, the type of the property can be either a basic data type (such as a number, a string, a date, and so on), an array or hash, or even a subdocument (embed document). In this way, the inverse normalization (denormalizing) data model can be implemented to improve the speed of the query. The ③ built-in GRIDFS supports high-capacity storage. Gridfs is an excellent distributed file system that can support massive data storage. Built-in Gridfs, MongoDB, can meet the fast range of large data set query. ④ built-in sharding. Provides a range-based auto sharding mechanism: A collection can be divided into several segments according to the range of records, to be segmented onto different shard. Shards can be combined with replication, with replica sets can achieve Sharding+fail-over, different shard can load balance. The query is transparent to the client. The client performs queries, statistics, and mapreduce operations, which are automatically routed by MongoDB to the backend data node. This allows us to focus on our own business and, when appropriate, to upgrade without pain. MongoDB's sharding design capability supports up to approx. petabytes and is sufficient to support general applications. This ensures that MongoDB runs on a cheap PC server cluster. PC clusters are easy to expand and inexpensive to avoid the complexity and cost of "sharding" operations. ⑤ third-party support is plentiful. (This is the advantage of MongoDB compared to other NoSQL) Many of the NoSQL open source databases on the Web are entirely community-based, with no official support, and pose a significant risk to users. and the open source document database MongoDB behind the commercial company 10gen provides it for business training and support. And the MongoDB community is very active, and many development frameworks quickly provide support for MONGDB. Many well-known big companies and websites also use MongoDB in the production environment, and more and more innovative enterprises use MONGODB as the technical solution to match django,ror. ⑥ Superior Performance: In the case of Tens other document objects, nearly 10G of data, queries for indexed IDs are no slower than MySQL, while queries on non-indexed fields are fully victorious. MySQL is not really competent for queries of any field under large data volumes, and MongoDB's query performance is surprising to me. Write performance is also very satisfying, also write millions other data, MongoDB than I have tried before the couchdb is much faster, basic 10 minutes below can be resolved. To make up a sentence, the observation process of MongoDB is far from being a CPU killer. The disadvantages of MongoDB compared to relational databases: ①mongodb does not support transactional operations. So a strict system of transactions (if the banking system) must not be able to use it. (This and the merit ① are corresponding) ②mongodb occupies too much space. For its reasons, in the official FAQ, the following aspects are mentioned: 1, space pre-allocation: In order to avoid the formation of excessive hard disk fragmentation, MongoDB each time the space shortage will be requested to generate a large chunk of hard disk space, and the amount of applications from 64M, 128M, 256M, such as the exponential increment, until 2G for the maximum volume of a single file. As the amount of data increases, you can see in their data directory the entire volume of files that have been incrementally generated. 2, the space occupied by the field name: In order to keep the structure information within each record used for querying, MongoDB needs to store the key-value of each field in the form of Bson, if the value field is not large relative to the key field, such as storing the data of numeric type, The overhead of the data is the largest. One way to reduce space usage is to take the field names as short as possible, so that space is small, but this requires a tradeoff between legibility and space occupancy. I have suggested that the author put the field name index, each of the field names in one byte, so you don't have to worry about how long the field name takes. But the author's concern is not unreasonable, this index method needs to be a result of each query to replace the index value with the original value, and then send to the client, this substitution is also very time-consuming. Now the realization is to take the space to exchange time. 3, delete the record does not free space: This is easy to understand, in order to avoid the record deleted after the large-scale movement of data, the original record space is not deleted, only marked "deleted" can be reused later. 4, can regularly run db.repairdatabase () to organize records, but this process will be relatively slow. ③mongodb does not have a proven maintenance tool like MySQL, which is a noteworthy area for development and IT operations. Due to uploading attachments and text restrictions, sometimes some pictures, text may not display, details see: http://mp.weixin.qq.com/s?__biz=MzI5ODI3NzY2MA==&mid=100000725&idx=3 &sn=1e1354fe3a774b01f3d4301f82735024#rd Welcome to communicate with us. Scan the following two-dimensional code for more beautiful articles! (scan the code to pay attention to the unexpected surprise!!) ） subscription number QR code. jpg (39.39 KB, download number: 0) Download attachments 2016-6-2 18:37 Upload Follow us on our subscription number (UNIGUYTECH100) and service number (Uniguytech) for more beautiful articles! Also welcome to join the "Everyone Technical network discussion QQ Group", group number: 256175955, please note your personal introduction! Let's talk about it!

