Mongodb installation and basic search operations: Learning and organizing (1), mongodb search

Mongodb installation and basic search operations: Learning and organizing (1), mongodb search

**

Install and configure MongoDB in windows:

**
Installation references: http://www.cnblogs.com/jiaxuekai/p/7204716.html
Https://jingyan.baidu.com/article/ed15cb1b52b8661be2698162.html
Http://www.weste.net/2014/10-31/99742.html
[MongoDB service cannot be started. windows prompts a specific service error: 100]
(Http://www.cnblogs.com/BGOnline/p/6813804.html :)
Administrator account password settings: And about login error settings http://blog.csdn.net/q1056843325/article/details/70941697

Basic concepts and operations:

_ Id and ObjectId
The document stored in MongoDB must have a "_ id" key. The value of this key can be of any type and is an ObjectId object by default. Each document in a set has a unique "_ id" value to ensure that each document in the set is uniquely identified. If there are two sets, both of them can have a "_ id" key with a value of 123, but each set can have only one "_ id" 123 document.
1. ObjectId
ObjectId is the default type of "_ id. It is designed to be lightweight, and different machines can easily generate it using the globally unique method of the same type. This is the main reason why MongoDB adopts ObjectId instead of other conventional approaches (such as automatically adding primary keys), because it is effort-consuming to automatically add primary key values on multiple servers. MongoDB was designed as a distributed database from the very beginning. processing multiple nodes is a core requirement. Later, we will see that the ObjectId type is much easier to generate in the sharding environment.

ObjectId uses a 12-byte storage space. Each byte has two hexadecimal numbers and is a 24-Bit String. Because it looks very long, many people will find it hard to handle it. But the key is to know that this long ObjectId is twice the actual data storage length.

If you create multiple objectids in a row, you will find that only the last few digits change each time. In addition, the numbers in the middle also change (for example, a pause of several seconds during creation ). This is caused by the creation of ObjectId. 12 bytes are generated as follows:

The next 3 bytes are the unique identifier of the host. It is usually the hash value of the machine host name. In this way, different hosts can generate different objectids without conflict.
To ensure that the ObjectId generated by multiple concurrent processes on the same machine is unique, the next two bytes are from the process identifier (PID) that generates the ObjectId ).

The first nine bytes ensure that the ObjectId generated by different processes on different machines in the same second is unique. The last three bytes are an automatically added counter, ensuring that the ObjectId generated by the same process in the same second is also different. Each process can have up to 2563 (16 777 216) Different objectids in a second.
2. automatically generate _ id
If you do not have the "_ id" key when inserting a document, the system will automatically create one for you. This can be done by the MongoDB server, but it is usually done by the driver on the client. The reasons are as follows.

Although ObjectId is designed to be lightweight and easy to generate, it still generates overhead. The design concept of MongoDB is embodied in client generation: If you want to migrate from the server to the driver, try to transfer it. The reason behind this idea is that, even a scalable database like MongoDB, it is much easier to expand the application layer than to expand the database layer. Transferring transactions to the client reduces the burden of database expansion.

When the ObjectId is generated on the client, the driver can provide richer APIs. For example, the driver can have its own insert method, return the generated ObjectId, or directly insert it into the document. If the driver allows the server to generate ObjectId, separate queries are required to determine the "_ id" value in the inserted document.

** Comparison between MongoDB syntax and existing Relational Database SQL syntax ** ----------------------------------------------------- db. test. find ({'name': 'foobar'}) <=> select * from test where name = 'foobar' db. test. find () <=> select * from testdb. test. find ({'id': 10 }). count () <=> select count (*) from test where ID = 10db. test. find (). skip (10 ). limit (20) <==> select * from test limit 10, 20db. test. find ({'id' :{$ in: [25, 35, 45] }}) <=> select * from tes T where ID in (25, 35, 45) db. test. find (). sort ({'id':-1}) <=> select * from test order by IDdescdb. test. distinct ('name', {'id': {$ lt: 20 }}) <=> select distinct (name) from testwhere ID <20db. test. group ({key: {'name': true}, cond: {'name': 'foo'}, reduce: function (obj, prev) {prev. msum + = obj. marks ;}, initial: {msum: 0 }}) <=> select name, sum (marks) from testgroup by namedb. test. find ('this. ID <20', {name: 1}) <=> select Name from test whereID <20db. test. insert ({'name': 'foobar', 'age': 25}) <==> insertinto test ('name', 'age') values ('foobar ', 25) db. test. remove ({}) <=> delete * from testdb. test. remove ({'age': 20}) <=> delete test where age = 20db. test. remove ({'age': {$ lt: 20 }}) <==> elete test where age <20db. test. remove ({'age': {$ lte: 20 }}) <==> delete test where age <= 20db. test. remove ({'age': {$ gt: 20 }}) <==> delete test where Age> 20 dB. test. remove ({'age': {$ gte: 20 }}) <==> delete test where age> = 20db. test. remove ({'age': {$ ne: 20 }}) <=> delete test where age! = 20db. test. update ({'name': 'foobar'}, {$ set: {'age': 36 }}) <==> update test set age = 36 where name = 'foobar' db. test. update ({'name': 'foobar'}, {$ inc: {'age': 3 }}) <==> update test set age = age + 3 where name = 'foobar'

References:

Top

0

Step on

0

View comments