MongoDB 3.2 is faster

MongoDB 3.2 is faster

MongoDB 3.2 is expected to be introduced in MongoDB World by the end of 2015. We believe this will benefit some attractive features. Most of these features are still evolving. Even though they are displayed, they may change when MongoDB 3.2 is published.

Mode?

There were a lot of discussions about models at the meeting. A "stateless" database, such as an upgrade of MongoDB, looks strange, but it seems like MongoDB, the company has rediscovered the document that the structure of the rule is stored in the database to help manage the evolution of a database.

This actually involves a new, MongoDB enterprise tool for payment, scanning collection and reverse engineer searches from the collection mode. It also provides new heat features for use in MongoDB3.2 to make the collection more useful and normal. These features are ......

Verification

One of the many new features of the MongoDB open-source version is that it can validate the fields in the document. This feature enables the set to have a validator as part of the set metadata. The validator is a matching expression that verifies that the matching result is true when the document is inserted or modified. If the verification fails, the modification will be rejected and an error 121 will be returned, DocumentValidationFailure.

But there are also some restrictions. First, the validator must be a very simple matching expression, such as greater than, less than, or existence. You cannot use a location near a geographical location. You cannot use a text query or a where expression.

You can set the validator when creating a table (I think it should be a set). You only need to add a validator setting item, or you can use the collmod Command, as shown below:

Db. runCommand ({"collMod": collName,
"Validator": {a :{$ exists: true }}})

This example verifies whether the field "a" exists. If you want to modify the validator, but notice that you have not obtained the metadata function, you need to obtain the statistical information of the Set (stats), which contains the existing validator. Then you can use "collMod" to modify and reset the settings.

You still need to remember the validator. First, they only take effect when adding and modifying operations. The implication is that the validator does not verify the existing data in the set... until you update an existing document, the validator will take effect unless the document has not been changed. Therefore, if you want to enable verification, you may need to first scan the existing set to confirm that all documents meet the requirements or add a failed snapshot for all add/modify operations. You can grant the BypassDocumentValidation permission to your users so that they can setbypassDocumentationValidationMark, but this may conflict with the original intention of verification. By the way, these permissions and identifiers are mainly designed for some O & M operations, such as restoring a partially conforming collection.

Partial Index

Another server-side function related to the mode is "Local index", which has been mentioned in JIRA of MongoDB since 2010. The best explanation for this function is through examples. Suppose you have all the customers you have ever been to, including active and inactive customers. In daily use, you want to obtain good performance when querying active customers. One way to achieve good performance is to divide it into two datasets (that is, tables) for processing. One dataset is an active customer, which has an index, and the other is a non-active customer without an index, however, this requires changes to the application to ensure that the customer is stored in the data set it should store. In addition, you can use a local index to index only the documents that meet the filter expression. As follows:

Myusercoll. createIndex ({name: 1 },
{PartialFilterExpression: {status: {$ eq: "active "}})

In this case, the processing performance of very large tables will be greatly improved. In this case, if the document does not match the filter, not only are these documents skipped during query, but they are not indexed when they are inserted or updated. However, the performance improvement depends entirely on the Structure and density of the fields to be indexed.

Lookup!

There is an indisputable fact that MongoDB does not have any form of table join. In most cases, you do not need table join, but when you need to combine and analyze data, you may want a connection function. MongoDB's opinion on this point is that it will slightly unnormalize your data, copy the data from different sets to the collection you are going to analyze, and keep them synchronized at least once a day, but when it comes to analysis, you cannot copy data everywhere.

MongoDB's core analysis tool is aggregation. With this tool, you can create a task pipeline, apply various operations to the selected documents, and finally obtain the required data. When you want to aggregate the order table, first add an operator in the pipeline to match the orders of certain types of products, and then use another operator group to calculate the sales volume of each type of products. The problem is that pipeline can only operate the documents in one set. Therefore, if you need to operate another set, you will not be able to perform any operations. MongoDB 3.2 adds a $ lookup operator to introduce data from other sets.

The $ lookup operator has a from parameter to specify the set from which you want to drag data. Another on parameter is used to specify which field in the other set should match the field in pipeline. Finally, when a document is matched, the document will be inserted into the document in the pipeline, and the document will be put into the key by setting a key through the as parameter. This method seems a little violent, making the document very large. Don't worry, other aggregate operators will cut the data down.

$ Lookup has great potential in the aggregation pipeline, so that users do not need to deliberately normalize data. However, we have to wait until the alpha/beta release to know how effective $ lookup is in practice.

Summary

This is the first time to judge database-level operations. We should put the expectation on MongoDB 3.2. The pain points of all three features here are the servers in the MongoDB architecture. When MongoDB 3.2 alpha/beta is released, we will be able to make more improvements on the server client. Most other MongoDB 3.2 changes and storage engines, authentication, integration and replication. We will cover it in the future.

Sort out common MongoDB operation commands

MongoDB 3.0 official version released and downloaded

CentOS compilation and installation of MongoDB

CentOS compilation and installation of php extensions for MongoDB and mongoDB

CentOS 6 install MongoDB and server configuration using yum

Install MongoDB2.4.3 in Ubuntu 13.04

MongoDB beginners must read (both concepts and practices)

MongoDB Installation Guide for Ubunu 14.04

MongoDB authoritative Guide (The Definitive Guide) in English [PDF]

Nagios monitoring MongoDB sharded cluster service practice

Build MongoDB Service Based on CentOS 6.5 Operating System

MongoDB details: click here
MongoDB: click here

MongoDB 3.2-A First Forward Look

This article permanently updates the link address: