Impact of MongoDB planned Cache

Impact of MongoDB planned Cache

After creating an index for Primary in the MongoDB 2.6 replica set, it is found that the Secondary query does not follow the latest index.

It is normal after the plan cache of the set is cleared temporarily. I have observed that when performance problems occur, the statements do not adopt the optimal execution plan.

For MongoDB 3.0.3 and earlier versions, you can solve the problem by using the following two methods:
1. explicitly specify hints for the query.
2. Set the cache index filter for the query plan to override the default query plan.

Fixed in 3.0.4.

SERVER-15225, SERVER-20139
Https://jira.mongodb.org/browse/SERVER-15225

The cache refresh issue of the execution plan. If the execution plan has a cache for the same type of query, it will not be verified. The query of the same type may have different execution conditions.

You can solve this problem by setting the internalQueryCacheReplanningEnabled parameter.
The query optimizer caches plans for each query shape and reuses these plans for a time. in situations where the performance of the cached plan is poor for a special instance of the query shape, the optimizer may select a plan with poor performance and fail to evict the cache entry. this behavior may impact deployments where two queries with the same shape have different performance characteristics if they have different selectivity.
This improvement makes the query planner evaluate the cost of the cached query plan, and if the cost of this plan is too high, the query planner switches to a more efficient plan. this more efficient plan is then cached for future use.
This improvement is not enabled by default. to enable by default set the internalQueryCacheReplanningEnabled parameter totrue using the setParameter command on a running system, or at start time using the setParameter commandline option orsetParameter in the configuration file.
For example, to enable using setParameter:
Db. runCommand ({setParameter: 1, internalQueryCacheReplanningEnabled: true })
This improvement can be disabled as follows:
Db. runCommand ({setParameter: 1, internalQueryCacheReplanningEnabled: false })
3.0.4 you can use this parameter, which is disabled by default.

Query plan

Given the available index, the MongoDB query optimizer processes the query and selects the most efficient query plan for a specific query. The query plan is used by the query system for each query execution.

The query optimizer only caches query plans that appear to have multiple feasible plans.

When the set content changes, the query optimizer re-evaluates the query plan to ensure the optimal query plan. You can use the index filter to specify the index evaluated by the optimizer.

For a given query, you can use the explain () method to view the statistics of the query plan.

Query Plan Revision

As the set changes over time, in one of the following situations, the query optimizer deletes the query plan and reevaluates it:
1. The set receives 1,000 write operations.
2. The reIndex rebuilds the index.
3. You can add or delete an index.
4. The specified D process restarts.

Cache query plan Interface

2.6 New Features

MongoDB provides query plan cache commands and methods to view and modify cached query plans.

Db. runCommand ({planCacheListFilters: Product })
Db. runCommand (
{
PlanCacheListPlans: "Product ",
Query: {Path:/^ 9-1-6 (-\ d +) * $/, "Status": {$ lt: 4 }}
}
)
Db. runCommand (
{
PlanCacheClear: "Product ",
Query: {Path:/^ 9-1-6 (-\ d +) * $/, "Status": {$ lt: 4 }}
}
)
Db. runCommand (
{
PlanCacheClear: "Product"
}
)

Index Filter

2.6 New Features.

The index filter determines which index the optimizer evaluates as a query shape. A query shape consists of query, sorting, and ing instructions. If a given query shape has an index filter, the optimizer will only consider the indexes specified in the filter.

When an index filter exists in the query shape, MongoDB ignores hint (). If you want to know whether MongoDB uses an index filter for a query, you can check the explain. filterSet field output by explain.

The index filter only affects the index evaluated by the optimizer. The Optimizer may still select the set scan as the winning solution for a given query shape.

The index filter only exists in the server process and is not saved after being shut down. MongoDB also provides a command to manually delete the filter.

Because the index filter overrides the Operations expected by the optimizer and the hint () method, please use the index filter properly.

Db. runCommand (
{
PlanCacheSetFilter: "orders ",
Query: {item: "ABC "},
Projection: {quantity: 1, _ id: 0 },
Sort: {order_date: 1 },
Indexes :[
{Item: 1, order_date: 1, quantity: 1}
]
}
)

For more information about MongoDB, see the following links:

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

This article permanently updates the link address: