[MongoDB] The basic operation of Index in MongoDB, mongodboperation

[MongoDB] The basic operation of Index in MongoDB, mongodboperation

In the past four blogs, we attached importance to the index, including description and comparison with usage of index. now in this blog, we will mainly focus on the basic operation of index. such query, remove, repair and so on.

1. View Index

GetIndexes cocould view all the indexes in the collections.
2. Delete index delete all the indexes: db. test. dropIndexes () delete one index: db. test. dropIndex ({name: 1 })
Use the command to delete index:
Db. runCommand ({dropIndexes: "test", index: {name: 1 }})


3. rebuild indexdb. test. reIndex () is trying ant to db. runCommand ({reIndex: 'test '})

Attention: This operation need to add the lock into the document, so if the collection was filled with a large number of data, this operation wowould take much time.
If using repair to fix database, the database will rebuild the index.
What is recorded in the sysindex table in mongodb?

Record all indexes in the database.

Why did David Mytton migrate data from MySQL to MongoDB?

"I felt the joy and sorrow of the author. If some translation is inappropriate or cannot be understood, please correct me. :) 1. Why does David migrate? The original article is as follows: Write The problem we encountered was administrative. we wanted to scale using replication but found that MySQL had a hard time keeping up, especially with the initial sync. as such, backups became an issue, but we solved that. however, scaling MySQL onto multiple clustered servers as we plan to do in the future is difficult. you either do this through replication but that is only really suited Read-heavy applications; or using MySQL cluster. the cluster looks very good but I have read about some problems with it and was unsure of it's suitability for our needs. it seems that we have encountered management problems, although we have solved the backup problem. We try to solve the problem through the MySql cluster. The cluster looks good, but it is difficult for a large number of write applications. At the same time, we are not sure whether the cluster meets our needs. So David chose to replace MySQL and MongoDB. 2. Why MongonDB? Wrote Very easy to install. PHP module available. very easy replication, including master-master support. in testing this caught up with our live DB very quickly and stayed in sync without difficulty. automatically sharding being developed. good documentation. I think the most important thing is: Very easy replication, including master-master support. in testing this caught up with our live DB very quickly and stayed in sync without d Ifficulty. It is very easy to copy and fast and consistent data. 3. Problems after MongoDB is transplanted. Schema-less: Write Schema-lessThis means things are much more flexible for future structure changes but it also means that every row records the field names. we had relatively long, descriptive names in MySQL such as timeAdded or valueCached. for a small number of rows, this extra storage onl ...... remaining full text>