MongoDB index management

Although the index of MongoDB is the same on the storage structure, it is divided into several types such as unique index (unique), sparse index (sparse), multivalued index (multikey) according to different application layer requirements.

Unique index

The unique index is created with the option to add unique:true , and the command is created as follows:

db.users.ensureIndex({username:1}, {unique: true})

When the above unique index is created, if you insert a username data that already exists, the following error is reported:

E11000 duplicate key error index: gardening.users.$username_1 dup key: { :"kbanker"}

If you create a unique index on the collection of an existing data, if the corresponding field of the unique index has duplicate data items, then the creation will fail, we need to add a dropdups option to force the deletion of duplicates, the following example:

db.users.ensureIndex({username:1}, {unique: true, dropDups: true})

Loosely indexed

If you have some rows in your data that do not have a field or field value NULL, then if you establish a normal index on this field, then the row without this field or value Null will also participate in the index structure, occupying the appropriate space. If we do not want those rows with empty values to participate in our index, this can be loosely indexed, and a loose index will only allow rows that are not empty for the specified field to participate in the index creation. To create a loose index, you can use the following command:

db.reviews.ensureIndex({user_id:1}, {sparse: true})

Multi-valued Index

MongoDB can create an index on an array type, like the following structure, where MongoDB can create an index on the tags field:

{ name: "Wheelbarrow",tags: ["tools","gardening", "soil"] }

When the index is built, three index elements are generated for each of the three values in the tags, and the Tools,gardening,soil three values in the index point to the same row of data. The equivalent of splitting into three separate index entries.

Index management index creation and deletion

There are many ways to create and delete an index, and the following two are the original methods, and the creation of the index is done by writing to the System.indexes collection:

spec = {ns: "green.users", key: {‘addresses.zip’:1}, name: ‘zip’} db.system.indexes.insert(spec,true)

The above command writes a record to system.indexes to create the index, which contains the namespace of the collection to create the index above, the index information, and the name of the index.

Once created, we can find the index we created with the following command:

db.system.indexes.find () { /code> "_id" : ObjectId ( "4d2205c4051f853d46447e95" "ns" : "green.users" "key" : { "Addresses.zip" : 1 }, Code class= "Java Plain" >: "Zip" "V" : 0 }

To delete a created index, we can use the following command to implement:

use green db.runCommand({deleteIndexes:"users", index: "zip"})

CREATE INDEX command

In fact, there are more convenient commands for creating indexes, which are ensureindex, such as when we create a federated index of open and close two fields, you can use the following command:

db.values.ensureIndex({open:1, close: 1})

This command triggers the two process of index creation, one is to sort the corresponding field, because the index is organized by the B + tree, to build the tree, to sort the data to improve the efficiency of inserting the B + tree (the efficiency of the second process), in the log, you can see the output similar to the following:

Tue Jan 409:58:17[conn1] building newindex on { open: 1.0, close:1.0 } forstocks.values 1000000/430830323% 2000000/430830346% 3000000/430830369% 4000000/430830392% Tue Jan 409:59:13[conn1] external sort used : 5files in 55 secs

The second procedure is to insert the sorted data into the index structure to make available indexes:

1200300/430830327% 2227900/430830351% 2837100/430830365% 3278100/430830376% 3783300/430830387% 4075500/430830394% Tue Jan 410:00:16[conn1] done building bottom layer, going to commit Tue Jan 410:00:16[conn1] done for4308303 records 118.942secsTue Jan 410:00:16[conn1] insert stocks.system.indexes 118942ms

In addition to the output in the log, you can also get information about the current operating thread by executing the currentop command at the terminal, as in the following example:

> db.currentOp() { "inprog" : [ { "opid" : 58, "active" : true, "lockType": "write","waitingForLock": false,"secs_running": 55,"op" : "insert", "ns" : "stocks.system.indexes","query" : { }, "client": "127.0.0.1:53421","desc" : "conn", "msg" : "index: (1/3) external sort 3999999/4308303 92%"} ] }

The final part is an index build process that is currently performing the sort process to 92%.

Create an index in the background

Creating an index adds a write lock to the database and, if the dataset is large, suspends the operation of the read-write database on the line to wait for the index creation to end. This affects the normal service of the database, we can make the creation work in the background by the option of adding background:true when the index is created, when the index is created or a write lock is required, but the write lock is not directly exclusive to the index creation, but pauses to make way for other read and write operations. Not cause serious performance impact. Specific methods:

db.values.ensureIndex({open:1, close: 1}, {background: true})

Create an index offline

In any case, the creation of indexes will put some pressure on the database, thus affecting the online service. If the process of creating an index does not affect the online service at all, we can add it to the replica sets by stripping the nodes in the replica sets from the cluster first, adding the appropriate indexes on the node. This only need to guarantee a condition, that is, the time to create the index can not be longer than Oplog can save the time of the log, or after the creation of the node again on-line discovery can no longer catch up with primary, this will be Resync operation.

Index Backup

We know that whether you use the Mongodump or the Mongoexport command, you simply back up the data and you cannot back up the index. When we recover, we still need to wait for a lengthy index creation process. So if you want to back up with an index, it's a good idea to use a backup data file.

Index compression

Index after the use of a period of time, experience additions and deletions and other operations, will become relatively loose, so that the war with unnecessary space, we can through the Reindex command, re-organize the index, so that the space footprint of the index becomes smaller.

http://blog.csdn.net/wxyfighting/article/details/8859445