项目需要进行MongoDb转换，查了一些资料，整理好后以便查阅

ObjectId的选择

创建MongoDB文档时，如果没有赋值ID，系统会自动帮你创建一个，通常会在客户端由驱动程序完成。得到的ObjectId类似于这种

ObjectId使用12字节的存储空间，每个字节两位十六进制数字，是一个24位的字符串。其含义分别代表时间戳、机器码、PID、计数器。时间戳是文档创建时的时间，只是从十进制转化成了十六进制。机器码是生成文档主机的ID，为了区分多主机而生成的。PID则是区分同主机下不同mongoDB进程产生的，同样防止冲突。前面的9个字节是保证了一秒内不同机器不同进程生成ObjectId不冲突，最后的3个字节是一个自动增加的计数器，用来确保在同一秒内产生的ObjectId也不会冲突，允许256的3次方等于16777216条记录的唯一性。

显然系统生成的ObjectID已经很严谨了，但是在选择系统创建还是程序创建id上，经过网上查找的一些资料，得到的结论是尽量采用程序创建的方式，速度、可读性、可维护性都要强于系统创建。

虽然ObjectId 设计成轻量型的，易于生成，但是毕竟生成的时候还是产生开销。在客户端生成体现了MongoDB 的设计理念：能从服务器端转移到驱动程序来做的事，就尽量转移。这种理念背后的原因是，即便是像MongoDB 这样的可扩展数据库，扩展应用层也要比扩展数据库层容易得多。将事务交由客户端来处理，就减轻了数据库扩展的负担。

在客户端生成ObjectId，驱动程序能够提供更加丰富的API。例如，驱动程序可以有自己的insert 方法，可以返回生成的ObjectId，也可以直接将其插入文档。如果驱动程序允许服务器生成ObjectId，那么将需要单独的查询，以确定插入的文档中的"_id" 值。