Comparison between MongoDB and traditional relational database MySQL

compared to relational database, the advantages of MongoDB: reprinted from Http://blog.sina.com.cn/s/blog_966e430001019s8v.html
① 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.

Before each update, we will query the records first. 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 way the document structure is stored makes it easier to get data.
for a hierarchical data structure, if you want to use a flat, tabular structure to hold the data, this can be difficult when querying or fetching data.
Example 1:
Take a "dictionary item", although not very complex, but it will be related to "definition", "part of speech", "pronunciation" or "reference" 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},  "Abe", Text: "First" },               "Ada", Text: "Good post" }]})> Db.blogposts.find ({"Author.name": "Jane" })> Db.blog Posts.findone ({title: "My First Post", "Author.name": "Jane",  "Abe", Text: "First" },              "Ada", Text: "Good post"} ]})> Db.blogposts.find ({"comments.by": "Ada" })> Db.blogposts.ensureI Ndex ({"Comments.by": 1});

Example ③:
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.

③ built-in Gridfs to support high-capacity storage. The
 gridfs is an excellent distributed file system that can support massive data storage.
  has built-in Gridfs MongoDB to meet fast-range queries over large data sets.
④ built-in sharding 。 The
provides a range-based auto sharding mechanism: A collection can be divided into segments and slices to different shard according to the range of records. The
shards can be combined with replication, with replica sets to achieve sharding+fail-over, and load balancing between different shard. 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 approximately 20 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.

⑥ Excellent performance:
in the case of Tens other document objects, nearly 10G of data, queries for indexed IDs are no slower than MySQL, and 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 disadvantage of MongoDB compared to relational databases:
①mongodb does not support transactional operations.
  Therefore the transaction-demanding system (if the banking system) must not be able to use it. (This and the merit ① are corresponding)
②mongodb takes up too much space 。
  for its reasons, in the official FAQ, the following aspects are mentioned:
1, Space pre-allocation: To avoid the formation of excessive hard disk fragmentation, MongoDB requests a large chunk of hard disk space each time it is out of space, and the amount requested is incremented from the exponent of 64M, 128M, 256M, until 2G is 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.

Comparison between MongoDB and traditional relational database MySQL