Databases: Advantages and Disadvantages of mongodb compared with relational databases zz

Compared with relational databases, MongoDB has the following advantages:
① Weak consistency (eventual consistency) ensures the user access speed:
For example, in a traditional relational database, a COUNT operation locks the dataset to ensure that the exact value is obtained under the "current" condition. This is important in some cases, for example, when viewing account information through an ATM, but for Wordnik, data is constantly updated and growing, this "accurate" guarantee has almost no meaning, but will lead to a great delay. What they need is an approximate number and a faster processing speed.

However, in some cases, MongoDB locks the database. If there are hundreds of requests at this time, they will pile up, causing many problems. We used the following optimization method to avoid locking:
We will query records before each update. The query operation puts the object into the memory, so the update will be as fast as possible. In the Master/Slave deployment scheme, slave nodes can run with the "-pretouch" parameter, which also achieves the same effect.
Use multiple mongod processes. We split the database into multiple processes according to the access mode.
② The storage of the document structure makes it easier to obtain data.
For a hierarchical data structure, it is very difficult to query or obtain data if you want to store such data in a flat-table structure.
Example 1:
Taking a "dictionary item" as an example, although it is not very complicated, it will still be related to "Definition", "part of speech", "Pronunciation" or "Reference. Most engineers will express this model using the primary key and foreign key in the relational database, but it is not better to regard it as a "document" rather than "a series of related tables? Using "dictionary. definition. partOfSpeech = 'none'" to query queries is more convenient and fast than a series of complex (often expensive) connection queries between tables.

Example 2: in a relational database, a blog (containing post content, comments, and comments) is dispersed into multiple data tables. In MongoDB, a document can be used to represent a blog. Comments and votes are taken as an array of documents and placed in the main document of the body. This makes data easier to manage and eliminates the "JOIN" operation that affects performance and horizontal scalability in traditional relational databases.

CODE Execution
> 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, which is currently developed and maintained by 10gen. It has rich functions and is complete and can completely replace MySQL. In the process of using MongoDB as a product prototype, we summarized some highlights of MonogDB:
The JSON style syntax is easy to understand: MongoDB uses the JSON variant bson as the internal storage format and syntax. All operations on 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 and 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 of which is a collection of documents. The table and row of collection and document are not equal to those of traditional databases. Collection can be created at any time without prior definition.
Collection can contain document records with different schemas. This means that the document in your previous record has three attributes, and the document in the next record can have 10 attributes, attribute types can be basic data types (such as numbers, strings, dates, etc.), arrays or hash, or even a sub-document (embed document ). In this case, the data model of denormalizing can be implemented to increase the query speed.

Figure 1 MongoDB is a schema-free document database

Figure 2 is an example. Works and comments can be designed as a collection. Comments are embedded as sub-documents in the comments attribute of art, comments are embedded in the replies attribute as subdocuments of comment sub-documents. According to this design pattern, you only need to retrieve all the relevant information by file ID. In MongoDB, we do not emphasize that data must be normalize. In many cases, we recommend de-normalize. developers can discard the limitations of various paradigms of traditional relational databases, you do not need to map all objects to a collection. You only need to define the top class. The document model of MongoDB allows us to easily map our own objects to collections for storage.

Figure 2 MongoDB supports embedding sub-Documents

③ Built-in GridFS, supporting large storage capacity.
GridFS is an excellent distributed file system that supports massive data storage.
The built-in GridFS MongoDB allows you to quickly query large datasets.
④ Built-in Sharding.
The Range-based Auto Sharding mechanism is provided. A collection can be divided into several segments based on the record Range and split into different Shard segments.
Shards can be combined with replication, and can be used with Replica sets to achieve Sharding + fail-over, and load balancing between different Shard. The query is transparent to the client. The client performs query, statistics, MapReduce, and other operations. These operations are automatically routed to the backend data node by MongoDB. This allows us to focus on our own business, which can be easily upgraded when appropriate. MongoDB's Sharding design capability can support up to 20 petabytes, which is sufficient to support general applications.
This ensures that MongoDB runs on a cheap PC server cluster. The expansion of PC clusters is very convenient and cost-effective, avoiding the complexity and cost of "sharding" operations.

⑤ Rich third-party support. (This is also an advantage of MongoDB over other NoSQL databases)
Currently, many open-source NoSQL databases on the Internet are fully community-oriented and do not have official support, which brings great risks to users.
The commercial company 10gen behind the open-source document database MongoDB provides business training and support.
In addition, the MongoDB community is very active, and many development frameworks quickly provide MongDB support. Many well-known large companies and websites also use MongoDB in their production environments. More and more innovative enterprises are switching to MongoDB as a technical solution that works with Django and RoR.
⑥ Superior performance:
In use cases, query of tens of millions of document objects and nearly 10 Gb of data for indexed IDS is not slower than query of non-indexed fields, in this case, it is a complete winner. Mysql is not competent to query any field in a large data volume, and I was surprised by the query performance of mongodb. The write performance is equally satisfactory, as well as writing millions of data records. mongodb is much faster than couchdb I have tried before and can be solved in less than 10 minutes. In addition, mongodb is far from a CPU killer during observation.

Compared with relational databases, MongoDB has the following Disadvantages:
① Mongodb does not support transaction operations.
Therefore, a system with strict transaction requirements (if a banking system) certainly cannot use it. (This corresponds to advantage 1)
② Mongodb occupies too much space.
The reasons are described in the official FAQ as follows:
1. pre-allocation of space: to avoid the formation of too many hard disk fragments, mongodb will apply to generate a large disk space each time when space is insufficient, in addition, the application volume increases exponentially from 64 M, 128 M, and M until 2G is the maximum volume of a single file. As the amount of data increases, you can see these files in the data directory with increasing capacity.

2. space occupied by field names: to keep the structure 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 large relative to the key field, for example, to store numeric data, the overhead of the data is the largest. One way to reduce the space occupation is to take the field name as short as possible, so that the occupied space will be smaller, but this requires a trade-off between ease of use and space occupation. I once suggested that the author use the field name as an index, and each field name is represented in one byte, so that you don't have to worry about the length of the field name. However, the author's concerns are not unreasonable. This index method requires that the index value be replaced with the original value after each query result and then sent to the client. This replacement is quite time-consuming. The current implementation is to exchange space for time.

3. delete a record without releasing space: This is easy to understand. To avoid large-scale migration of deleted data, the original record space is not deleted and only marked as "deleted, it can be reused in the future.

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

③ MongoDB does not have mature maintenance tools like MySQL, which is worth noting for development and it operations.