_id and Objectid in MongoDB

Objectid is the default type for "_id". It is designed to be light-weight, and different machines can easily generate it with a globally unique homogeneous method.
This is the main reason that MongoDB uses objectid instead of other more conventional practices (such as auto-incremented primary keys) because in multiple
Automatic increase of primary key values on the server is laborious and time consuming. MongoDB was designed from the outset to work as a distributed database, processing multiple sections
Point is a core requirement. Later on, the Objectid type is much easier to generate in a sharding environment.

Objectid uses 12 bytes of storage space, two hexadecimal digits per byte, and is a 24-bit string. Because it looks very long, not
Less people will find it difficult to deal with. But the key is to know that this long objectid is twice times the actual amount of data stored.

If you create multiple objectid quickly and continuously, you will find that only the last few digits change. The other numbers in the middle also change (to
is to pause for a few seconds during the creation process). This is caused by the way Objectid was created. The 12 bytes are generated as follows:
0|1|2|3 | 4|5|6 | 7|8 | 9|10|11
Time Stamp | Machine | PID | Counter
The first 4 bytes are timestamps starting from the standard era, in seconds. This will bring some useful properties.

The timestamp, combined with the subsequent 5 bytes, provides the uniqueness of the second level.
Since the timestamp is in front, this means that the Objectid is roughly sorted in the order in which they were inserted. This is useful for some aspects, such as indexing
High efficiency, but this is not guaranteed, just "approximate". These 4 bytes also imply when the document was created. Most drivers will be exposed
A way to get this information from Objectid.

Because the current time is used, many users worry about the time synchronization of the server, in fact, this is not necessary, because the actual value of the timestamp is not
Important, as long as it always keeps on increasing (once per second).

The next three bytes are the unique identifier of the host on which it resides. This is usually the hash value of the machine host name. This ensures that different hosts can generate different
ObjectId, does not create a conflict.

To ensure that the objectid generated by multiple processes concurrently on the same machine are unique. The last 3 bytes is an automatically incremented counter that
The same process is not the same as the objectid produced in the same second. The same second allows up to 256 (16777216) different objectid per process.

2. Automatically generate _id
As mentioned earlier, if there is no "_id" key when inserting a document, the system will automatically create one for you. It 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 generates overhead when it is generated. Create a design that embodies MongoDB on the client
Idea: To transfer from the server to the driver to do things, as far as possible to transfer. The reason behind this idea is that even a scalable, like MongoDB,
Extending the application layer is much easier than extending the database layer. By handing the transaction over to the client, the burden of the database extension is mitigated.

Drivers can provide richer APIs when the client generates Objectid. For example, the driver can have its own insert method that can return the raw
Objectid, you can also insert it directly into the document. If the driver allows the server to generate Objectid, a separate query is required to
The "_id" value in the inserted document.

Reprint:http://blog.csdn.net/magneto7/article/details/2384294

_id and Objectid in MongoDB