Getting Started - MongoDB: The Definitive Guide - page 22

To provide uniqueness among different processes generating ObjectId s concurrently
on a single machine, the next two bytes are taken from the process identifier (PID) of
the ObjectId -generating process.
These first nine bytes of an ObjectId guarantee its uniqueness across machines and
processes for a single second. The last three bytes are simply an incrementing counter
that is responsible for uniqueness within a second in a single process. This allows for
up to 256 3 (16,777,216) unique ObjectId s to be generated per process in a single second.
Autogeneration of _id
As stated previously, if there is no "_id" key present when a document is inserted, one
will be automatically added to the inserted document. This can be handled by the
MongoDB server but will generally be done by the driver on the client side. There are
a couple of reasons for that:
• Although ObjectId s are designed to be lightweight and easy to generate, there is
still some overhead involved in their generation. The decision to generate them on
the client side reflects an overall philosophy of MongoDB: work should be pushed
out of the server and to the drivers whenever possible. This philosophy reflects the
fact that, even with scalable databases like MongoDB, it is easier to scale out at the
application layer than at the database layer. Moving work to the client side reduces
the burden requiring the database to scale.
• By generating ObjectId s on the client side, drivers are capable of providing richer
APIs than would be otherwise possible. For example, a driver might have its
insert method either return the generated ObjectId or inject it directly into the
document that was inserted. If the driver allowed the server to generate
ObjectId s, then a separate query would be required to determine the value of
"_id" for an inserted document.