_ Id and ObjectId in MongoDB

Zookeeper

_ 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.
In a set, each set has a unique "_ id" value to ensure that each document in the set is uniquely identified. If
Two sets can have a "_ id" key with a value of "123", but each set can have only one "_ id"
Is a 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 common practices (such as automatically adding primary keys), because
It is laborious and time-consuming to automatically add a primary key value during synchronization on the server. MongoDB was designed as a distributed database from the very beginning to process multiple nodes.
Point is a core requirement. The ObjectId type is much easier to generate in the partition 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, no
Few 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 (
Is paused for several seconds during creation ). This is caused by the creation of ObjectId. 12 bytes are generated as follows:
0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11
Timestamp | machine | PID | counter
The first four bytes are the timestamp starting from the standard epoch, in seconds. This will bring about some useful attributes.

Timestamp, combined with the next five bytes, provides second-level uniqueness.
Because the timestamp is in the front, this means that the ObjectId will be arranged roughly in the order of insertion. This is useful for some aspects, such as using it as an index
High efficiency, but this is not guaranteed, just "rough ". These four bytes also imply the document creation time. Most drivers will be made public
A method obtains this information from ObjectId.

Because the current time is used, many users are worried about synchronizing time on the server. In fact, this is not necessary because the actual timestamp value is not
Important, as long as it keeps increasing (once per second ).

The next three bytes are the unique identifier of the host. It is usually the hash value of the machine host name. This ensures that different hosts generate different
ObjectId, no conflict.

To ensure that the ObjectId generated by multiple concurrent processes on the same machine is unique. The last three bytes are an automatically added counter.
The ObjectId generated by the same process in the same second is also different. Each process can have up to 256 (16777216) Different objectids in a second.

2. automatically generate _ id
As mentioned above, if there is no "_ id" key when inserting a document, the system will automatically create one for you. The MongoDB server can do this,
Generally, the driver is used on the client. The reasons are as follows:
Although ObjectId is designed to be lightweight and easy to generate, it still generates overhead. MongoDB design is embodied in client generation
Concept: transfer everything from the server to the driver. The reason behind this idea is that, even MongoDB is scalable.
Expanding the application layer is much easier than expanding 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 and can return
Can be directly inserted into the document. If the driver allows the server to generate ObjectId, separate queries are required to confirm
Specify the value of "_ id" in the inserted document.