MongoDb的各语言驱动都实现了ObjectId的生成算法，比如PyMongo，在bson.objectid.py里面。通过ObjectId的生成算法以及mongo shell、pymongo的例子，我们可以看到，objectid的生成是由驱动负责的，而不是MongoDB负责，这样减轻了MongoDB负担，也达到了去中心化服务的目的。

　　这里的结构化ID，就是指按一定规则，用时间、空间（机器）信息生成的ID，上面介绍的UUID以及各种变种都属于结构化id。

　　结构化ID的优点在于充足的信息，最有用的肯定是时间信息，通过ID就能直接拿到数据的创建时间了；另外，天然起到了冷热数据的分离。当然，有利必有弊，比如在ID作为分片键的分片环境中，如果ID包含时间信息，那么很可能在短时间内生成的数据会落在同一个分片。在《带着问题学习分布式系统之数据分片》一文中，介绍了MongoDB分片的两种方式：“hash partition”与“range partition“，如果使用ObjectId作为sharding key，且sharding方式为range partition，那么批量导入数据的时候就会导致数据落在同一个shard，结果就是大量chunk的split和migration，这是不太好的。

　　如果结构化ID中包含分片信息，那就更好了，这样就不会再维护数据与分片的信息，而是直接通过id找出对应的分片。我们来看看TFS的例子

　　TFS是淘宝研发的分布式文件存储系，其的结构一定程度上参考了GFS（HDFS），元数据服务器称之为Nameserver，实际的数据存储服务器称之为Dataserver。TFS将多个小文件合并成一个大文件，称之为block，block是真实的物理存储单元。因此，DataServer负责存储Block，而NameServer维护block与DataServer的映射。那么小文件与block的映射关系在哪里维护呢？要知道小文件的量是很大的

　　TFS的文件名由块号和文件号通过某种对应关系组成，最大长度为18字节。文件名固定以T开始，第二字节为该集群的编号(可以在配置项中指定，取值范围 1~9)。余下的字节由Block ID和File ID通过一定的编码方式得到。文件名由客户端程序进行编码和解码

　　如图所示：

　　从上图可以看到，最终的文件名是包含了block id信息的的，那么如何利用这个blockid信息呢，如下图所示：

　　当需要根据文件名获取文件内容的时候，TFS的客户端，首先通过文件名解析出Block id与File id，然后从NameServer上根据Block id查询block所在的DataServer。然后从DataServer上根据Block id拿到对应的block，在根据file id从block中找到对应的文件。

　　TFS用于存储淘宝大量的小文件，比如商品的各种尺寸的小图片，这个数量是非常大的，如果用单独的元数据服务器维护文件名与文件信息的映射，这个量是非常大的。而使用携带block id信息的文件名，很好规避了这个问题。但使用这种携带分区信息的ID时，需要考虑数据在分区之间的迁移情况，ID一般来说使不能变的，因此ID映射的应该是一个逻辑分区，而不是真正的物理分区。

　　 本文介绍了分布式系统中，全局唯一ID的生成方法。ID主要有两种类型，一种是数字自增ID，如flicker的解决方案；另一种是携带时间、机器信息的组合ID，如uuid。分布式系统中，好的全局ID生成算法首先是需要避免单点，如果不需要中心化服务的话更好；另外，携带时间信息、分片信息的ID更加实用。

Ticket Servers: Distributed Unique Primary Keys on the Cheap

UUID（Universally unique identifier）

rfc4122

Are you designing Primary Keys and ID’s???Well think twice..

TFS