Compared with relational databases, MongoDB’s advantages:
① Weak consistency (eventual consistency), which can better ensure user access speed:
传 For example, in the traditional relational database, an operation of a count type locks the data set, which can ensure that the accurate value of the current situation can be obtained. This is important in some cases, such as when checking account information through an ATM, but for Wordnik, the data is constantly updated and growing, and this "accurate" guarantee has almost no meaning, but will have a great impact. Delay. What they need is an "approximate" number and faster processing. But in some cases MongoDB will lock the database. If there are hundreds of requests at the moment, they can pile up and cause many problems. We use the following optimizations to avoid lock-ins:
Before each update, we will first query the records. Query operations put objects into memory so updates can be as fast as possible. In a master/slave deployment scenario, the slave node can be run with the "-pretouch" parameter, which will achieve the same effect.
Use multiple mongod processes. We split the database into multiple processes based on access patterns.
②The storage method of document structure makes it easier to obtain data.
For a hierarchical data structure, if you want to use a flat, table-like structure to save the data, it will be very difficult to query or obtain the data. Example 1:
Take a "dictionary item" as an example. Although it is not very complicated, it still involves content such as "definition", "part of speech", "pronunciation" or "citation". Most engineers would express this model using primary and foreign keys in a relational database, but wouldn't it be better to think of it as a "document" rather than a "series of related tables"? Using "dictionary.definition.partOfSpeech='noun'" to query is more convenient and faster than a series of complex (and often costly) join queries between tables.
Example 2:
In a relational database, a blog (including article content, comments, and votes for comments) will be scattered across multiple data tables. In MongoDB, a document can be used to represent a blog, with comments and votes as document arrays placed in the main text document. This makes the data easier to manage and eliminates the "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 feature-rich and complete and can completely replace MySQL. In the process of using MongoDB for product prototyping, we summarized some of the highlights of MonogDB: Using JSON style syntax, easy to master and understand: MongoDB uses BSON, a variant of JSON, as the format and syntax for internal storage. All operations on MongoDB use JSON style syntax, and the data submitted or received by the client is displayed in JSON form. Compared with SQL, it is more intuitive, easy to understand and master. Schema-less, supports embedded subdocuments: MongoDB is a Schema-free document database. A database can have multiple Collections, and each Collection is a collection of Documents. Collection and Document are not equivalent to Table and Row in traditional databases. There is no need to define a Collection in advance and 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 attributes, while the document in the next record can have 10 attributes. The type of the attributes can be either basic data types (such as numbers, strings, dates, etc.) or It can be an array or a hash, or even an embedded document. In this way, a denormalizing data model can be achieved and the query speed can be improved. ③ Built-in GridFS supports large-capacity storage.
GridFS is an excellent distributed file system that can support massive data storage. It has built-in GridFS and MongoDB, which can meet the fast range query of large data sets. ④Built-in Sharding. Provides a Range-based Auto Sharding mechanism: a collection can be divided into several segments according to the record range and split into different Shards. Shards can be combined with replication. Sharding+fail-over can be achieved with Replica sets, and load balancing can be achieved between different Shards. Queries are transparent to the client. The client performs queries, statistics, MapReduce and other operations, which are automatically routed to the back-end data nodes by MongoDB. This allows us to focus on our business and can upgrade painlessly when appropriate. MongoDB's Sharding design capability can support up to about 20 petabytes, which is enough to support general applications. This ensures that MongoDB runs on a cheap PC server cluster. PC clusters are very convenient and cost-effective to expand, avoiding the complexity and cost of "sharding" operations. ⑤ Rich 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.
Behind the open source document database MongoDB is 10gen, a commercial company that provides commercial training and support. And the MongoDB community is very active, and many development frameworks have quickly provided support for MongoDB. Many well-known large companies and websites are also using MongoDB in production environments. More and more innovative companies are turning to MongoDB as a technical solution to match Django and RoR. ⑥Superior performance: 千 On the occasion of use, tens of millions of document objects, nearly 10g data, query of index IDs will not be slower than mysql, but query on non -index fields will be fully won. Mysql is actually not capable of querying any field in a large amount of data, and the query performance of mongodb really surprised me. The writing performance is also very satisfactory. When writing millions of data, mongodb is much faster than the couchdb I have tried before. It can basically be solved in less than 10 minutes. I would like to add that during the observation process, mongodb is far from being a CPU killer. Compared with relational databases, MongoDB’s disadvantages: ①mongodb does not support transaction operations. So systems with strict transaction requirements (such as banking systems) definitely cannot use it. (This point corresponds to advantage ①)
②Mongodb takes up too much space.
About the reasons, in the official FAQ, the following aspects are mentioned:
1. Pre-allocation of space: In order to avoid excessive hard disk fragmentation, mongodb will apply for a large piece of hard disk space every time there is insufficient space, and the amount of application increases exponentially from 64M, 128M, 256M, 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 with increasing block generation capacity.
2. The space occupied by field names: In order to maintain 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 domain is not large compared to the key domain , such as storing numerical data, the data overhead is the largest. One way to reduce space usage is to make field names as short as possible so that they take up less space, but this requires a trade-off between readability and space usage. I once suggested that the author make the field name an index, and use one byte to represent each field name, so that you don't have to worry about how long the field name is. But the author's concerns are not unreasonable. This indexing method requires the index value to be replaced with the original value after each query results are obtained, and then sent to the client. This replacement is also quite time-consuming. The current implementation is about trading space for time.
3. Deleting records does not release space: This is easy to understand. In order to avoid large-scale movement of data after deletion of records, the original record space is not deleted and can only be 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.
Due to restrictions on uploading attachments and text, sometimes some pictures and text may not be displayed. For details, please see: http://mp.weixin.qq.com/s?__biz=MzI5ODI3NzY2MA==&mid=100000725&idx=3&sn=1e1354fe3a774b01f3d4301f82735024#rd
Everyone is welcome to communicate.
Scan the QR code below to get more and more beautiful articles! (Scan the QR code to follow for unexpected surprises!!) You are also welcome to join [Everyone Technology Network Discussion QQ Group], group number: 256175955, please note your personal introduction! Let’s talk about it together! |