Useful MONGO command line Db.currentop () Db.collection.find (). Explain ()-excerpt from the network

In Heyzap and Bugsnag I've been using MongoDB for more than a year, and I found it to be a very powerful database. As with other databases, it has some flaws, but there are some things I would like someone to tell me earlier. Even if the index selectivity count is slow For example, when paging through a user feed, you might see something like that, In MongoDB, this count takes an order of magnitude longer than you want. There is an open Ticke, currently 2.4, and here I hope they can get it out. Before that, you can leave a summary of your data. When inserting a new document, you can use $inccommand to store data summaries in MONGO.

Replica set Read inconsistency

When you start using a replica set to distribute readings across a cluster, you get yourself into the vortex of trouble. For example, if you write data to a master device, subsequent read operations may be directed to the slave device, while the data from the device remains to be copied. This can be illustrated with an example like the following,

Writes the object to the Primarydb.collection.insert ({_id:objectid ("505bd76785ebb509fc183733"), Key: "Value"});    This find was routed to a read-only secondary, and finds no Resultsdb.collection.find ({_id:objectid ("505BD76785EBB509FC 183733 ")});

This problem is more complicated if there are performance issues, because it causes replication lag between the master and slave devices, which can grow to a few minutes or even hours in some cases.

You can control whether a query runs on a slave device, or how many copies are performed from the device in the insert operation, but this will affect performance and, in some cases, can even cause permanent blocking!

Range queries are indexed in different order

I found that the index used by the scope query was slightly different from the other queries. Typically in a composite query, you use the keyword as the last parameter of an index operation. However, when you use a range query such as $in, the MONGO applies the index before the range is applied. This causes the index of the document to be done in memory, which is quite slow!

This doesn ' t use the last element in a compound index to Sortdb.collection.find ({_id: {$in: [  ObjectId ("505bd76785 ebb509fc183733 "),   ObjectId (" 505bd76785ebb509fc183734 "),  ObjectId (" 505bd76785ebb509fc183735 ")  , ObjectId ("505bd76785ebb509fc183736")]}}). sort ({last_name:1});

In Heyzap, we bypassed this problem by creating a cache layer in Redis for this query. But if you have only two values in the $in declaration, you can also perform the same query two times, or you can adjust the index if you have RAM available.

You can read more about this issue, or browse this tab.

MONGO's BSON ID is very useful

MONGO's BSON ID gives you a lot of useful functionality, but when I first used the MONGO, I didn't get one-second of what I could do with it. For example, the creation time of the BSON ID is stored in the ID. You can extract this time and easily have a CREATED_AT field!

Would return the time the ObjectId was Createdobjectid ("505bd76785ebb509fc183733"). Gettimestamp ();

The BSON ID is incremented over time, so sorting by ID is also sorted by creation date. This column is automatically indexed, so the query is fairly fast. You can read more about its content on the 10gen website.

Index all queries

When I first used MONGO, I sometimes executed queries on a specific underlying environment or from a scheduled task. Initially those queries were not indexed because there was no need to face the user or to run frequently. This, however, poses a performance problem for other index queries because queries that are not indexed do a lot of disk reads, which affects the retrieval of non-cached documents. So I was determined to make sure that the queries were at least partially indexed, lest such things happen again.

Always perform a explain operation on a newly created query

Obviously, if you have a relational database with background, you must be familiar with explain operations, which is equally important in MONGO. When you add a query to an application, you should run a query on the production data to check its speed. You can also ask MONGO to execute explain to explain how the query executes, so that you can check for parameters such as indexes and so on.

Db.collection.find (query). Explain () {    //Basiccursor means no index used, Btreecursor would mean this was an indexed que RY    "cursor": "Basiccursor",        //The bounds of the index that were used, see how much of the index is being scanned    "Indexbounds": [],        //number of documents or indexes scanned    "nscanned": 57594,        //Number of documents Scanned    "nscannedobjects": 57594,//The number of times the        the Read/write lock    was yielded "nyields": 2, 
   //number of documents matched    "n": 3,        //Duration in milliseconds    "Millis": 108,        //True if the Results can returned using only    the index "indexOnly": false,        //If True, a Multikey index were used    "is Multikey ": false}

I've seen a newly deployed application because the entire site is down because the query statements are not validated in the production environment. Doing a verification is relatively fast and easy to do, so don't look for a rejection!

Analyzer

MongoDB comes with a very useful parser. You can set the parser to analyze queries that are more than a certain amount of time, depending on your needs. I set it to record all queries over 100 microseconds.

Analyze all queries over 100 microseconds db.setprofilinglevel (1, 100);//Analyze All Queries Db.setprofilinglevel (2);//Close Analyzer db.setprofilinglevel (0);

The parser saves all the profiling data to the System.profile set with the prefix added. This is like other datasets, and you can perform queries against him, such as:

Know the latest analysis Db.system.profile.find (). Sort ({$natural: -1});    Query Db.system.profile.find ({millis: {$gt: 5}) found for more than 5 milliseconds;    Find the slowest query Db.system.profile.find (). Sort ({millis:-1});

You can display the most recent analysis output through Show Profile helper.

The parser itself adds a bit of overhead to each query, but I think it's worth it. Without him, you would be blind. I would rather sacrifice a little bit of speed overhead to let me see that those queries are causing the problem. Without it, you don't realize how slow your query is to the user.

Useful MONGO command-line

Here are some useful command lines that you can run in the MONGO Shell to monitor your server status. These can be scripted, so you can use it to get data for monitoring or charting.

• Db.currentop ()-Displays all of your currently running actions
• Db.killop (opid)-can be used to kill long queries
• Db.serverstatus ()-Displays the status of your entire server, which is very useful for monitoring
• Db.stats ()-Displays the status of the library you selected
• Db.collection.stats ()-The state of a specific set

Db.collection.find (). Explain ()

Monitoring

After a year of monitoring MONGO production instances, I listed the key thresholds that the series needed to monitor.

Index size

It is necessary to adjust the appropriate size of the Mongod memory according to your work needs. Take Heyzap as an example, we need to put all the indexes in memory, when browsing the old game or user configuration, we have to query the entire data set very frequently.

By charting the size of the index, HEYZAP can accurately predict when the server needs to be increased, when the index is removed or other methods are processed to increase the size of the index. We can predict in about a day whether we need to deal with the current index growth problem.

Monitoring

After a year of monitoring MONGO production instances, I listed the key thresholds that the series needed to monitor.

Index size

It is necessary to adjust the appropriate size of the Mongod memory according to your work needs. Take Heyzap as an example, we need to put all the indexes in memory, when browsing the old game or user configuration, we have to query the entire data set very frequently.

By charting the size of the index, HEYZAP can accurately predict when the server needs to be increased, when the index is removed or other methods are processed to increase the size of the index. We can predict in about a day whether we need to deal with the current index growth problem.

Useful MONGO command line Db.currentop () Db.collection.find (). Explain ()-excerpt from the network