"Turn" MongoDB vs MySQL Comparison

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.

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. &NBSP
② 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, this can be difficult both in querying and 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},
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 that is currently being developed and maintained by 10gen and is fully functional, complete, and completely alternative to MySQL. In the process of using MongoDB to prototype a product, we summed up some of the highlights of Monogdb:
using JSON-style syntax, easy to grasp and understand: MongoDB uses a variant of JSON Bson 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. The
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 a 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.

⑤ is rich in third-party support. (This is the advantage of MongoDB compared to other NoSQL)
now many of the NoSQL open source databases on the Web are entirely community-based, with no official support, which poses a great 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.
⑥ performance:
In the case of Tens other document objects, nearly 10G of data, the query for indexed IDs is 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.
  So 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, mentioned in the following aspects:
1, pre-allocation of space: to avoid the formation of excessive hard disk fragmentation, MongoDB each time the space is insufficient to generate a large chunk of hard disk space, and the amount of applications from 64M, 128M, Exponential increments of 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.

"Turn" MongoDB vs MySQL Comparison