Shulou(Shulou.com)06/01 Report--

Editor to share with you how to improve the performance of MongoDB, I hope you will learn a lot after reading this article, let's discuss it together!

MongoDB is high-performance data, but you occasionally encounter some performance problems in the process of using it. Compared with other relational databases, such as SQL Server, MySQL and Oracle, MongoDB is relatively new, and many people are not very familiar with it, so many developers and DBA often focus on the implementation of functions while ignoring the requirements of performance. In fact, MongoDB and SQL Server, MySQL, Oracle, a database object design adjustment, index creation, statement optimization, will have a great impact on performance.

In order to fully tap the performance of MongoDB, the following 18 items are simply summed up. You are welcome to continue to summarize and improve them.

(1) the default value is recommended for the _ id key in the document, and custom values are not allowed to be saved to _ id.

Interpretation: every MongoDB document has a "_ id" key, which defaults to an ObjectID object (the identifier contains a timestamp, machine ID, process ID, and counters). MongoDB differs greatly between specifying _ id and not specifying _ id insertion, and specifying _ id slows down the insertion rate.

(2) short field names are recommended.

Interpretation: unlike relational databases, every document in the MongoDB collection needs to store field names, and long field names require more storage space.

(3) MongoDB index can improve the query, update, delete and sort operations of documents, so it is appropriate to create an index according to business requirements.

(4) each index takes up some space and consumes the resources of the insert operation, so it is recommended that the number of indexes per collection should be limited to 5 as much as possible.

(5) for queries that contain multiple keys, it is a good solution to create a composite index containing these keys. The order of keys in a composite index is important to understand the leftmost prefix principle of the index.

Interpretation: for example, create a combinatorial index on the test collection {aburete 1 magnified bburel 1pr cjor1}. Execute the following seven query statements:

Db.test.find ({a: "hello"}) / / 1db.test.find ({b: "sogo", a: "hello"}) / / 2db.test.find ({a: "hello", b: "sogo", c: "666"}) / / 3db.test.find ({c: "666", a: "hello"}) / / 4db.test.find ({b: "sogo") C: "666"}) / / 5db.test.find ({b: "sogo"}) / / 6db.test.find ({c: "666"}) / / 7

The above query statements may go to index 1, 2, 3, 4.

The query should contain the leftmost index fields in the order in which the index is created, regardless of the order of the query fields.

The least index overrides the most queries.

(6) TTL index (time-to-live index, index with life cycle), the use of TTL index can time out the document aging, a document will be deleted after reaching the degree of aging.

Interpretation: the index that creates the TTL must be of a date type. An TTL index is a single-field index and cannot be a composite index. The TTL delete document background thread removes invalid documents every 60s. Fixed length collections are not supported.

(7) it is recommended to create a sparse index when you need to create an index in a field in the collection, but a large number of documents in the collection do not contain this key.

Interpretation: the index is dense by default, which means that even if the index field of the document is missing, there is a correspondence in the index. In sparse indexes, only documents that contain index key values appear.

(8) the field specifies text instead of 1 or-1 when creating a text index. Each collection has only one text index, but it can index any number of fields.

Interpretation: text search is much faster, it is recommended to use text index instead of inefficient query on multiple fields of collection documents.

(9) use findOne to query matching multiple items in the database, and it will return the first item in the collection of naturally sorted files. If you need to return multiple documents, use the find method.

(10) if the query does not need to return the entire document or is only used to determine whether the key value exists, the return field can be limited by projection (mapping) to reduce network traffic and memory usage of the client.

Interpretation: you can explicitly specify the returned fields by setting {key:1}, or you can set {key:0} to specify the fields to be excluded.

(11) except for prefix style queries, regular expression queries cannot use indexes, take longer to execute than most selectors, and should be used sparingly.

(12) in the aggregation operation, $should precede $group. Through $prefix, you can reduce the match prefix and reduce the number of documents to be processed by the $group operator.

(13) better performance is usually achieved by modifying the document through the operator, because it takes less time to serialize and transfer the data without having to go back and forth to the server to obtain and modify the document data.

(14) bulk insert (batchInsert) can reduce the number of data submitted to the server and improve performance. However, the batch submitted BSON Size does not exceed the 48MB.

(15) it is forbidden to sort too much data at a time. MongoDB currently supports sorting result sets less than 32m. If you need to sort, try to limit the amount of data in the result set.

(16) some $operators in the query may cause poor performance, such as the operator may lead to poor performance, such as $ne,$,not,$exists,$nin,$or should not be used in the business as far as possible.

A) $exist: because of the loose document structure, the query must traverse each document

B) $ne: if the negative value is most, the entire index will be scanned

C) $not: may cause the query optimizer to not know which index to use, so it will often degenerate to a full table scan

D) $nin: full table scan

E)\ $will be queried as many times as there are multiple conditions, and finally merge the result set, you should consider replacing the result set with or: how many times you will query if there are multiple conditions, and finally merging the result set, you should consider replacing it with $in.

(17) fixed sets can be used to record logs, which insert data faster and eliminate the earliest data when inserting data. This feature can be taken into account in requirements analysis and design, that is, improved performance and omitted deletion actions.

Interpretation: fixed collections need to be created explicitly, specify the size of the Size, and also specify the number of documents. No matter which limit the collection reaches first, the new document inserted later will move the oldest document out.

(18) the amount of data of the documents in the collection will affect the query performance, in order to maintain the appropriate amount, it needs to be archived regularly.

After reading this article, I believe you have a certain understanding of how to improve the performance of MongoDB, want to know more about it, welcome to follow the industry information channel, thank you for reading!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.