对象存储平台mongodb主键问题思考

我仔细思考了一下关于id字段和文件目录关联问题，有以下几点：

1. 看了官方文档和很多博客，mongo里一般的主键都不用自己设定的，都用mongo自己机制里的_id，这样做的好处也是方便集群，由于随机性和唯一性

2. mongo里没有自增ID的机制，需要自行实现。我看了一下各种实现方法都没有很简单依赖mongo官方的方法来实现，大多是用数据库以外的脚本逻辑语言来实现，严谨性不强（虽然mongo有原子性，不用考虑并发问题）

3. 自增ID有很大一个问题就是集群，我们的集群式分片+副本集的，如果在业务逻辑里写自增ID，很有可能在分片和副本集熄火重新选主以及各种备份复制数据时出现冲突或者自增ID丢失间断，因为我们的也无需求主要是大批量的写，所以这种危险还是有可能发生的

4. 我们设计ID字段的初衷是为了在这个目录和文件合在一起的表里让文件记录去索引目录记录，但是我们的大部分记录又都是文件，目录记录所占比例极其小，所以对于文件记录来说这个ID就基本没什么意义，因为没有记录去索引它，这个字段的主要意义在目录记录上

综上所述问题，提出以下解决方案：

1. 删除id自增字段，主键就使用mongo自带的_id字段，原因主要是考虑到集群，UUID很安全很方便

2. 修改fod字段为did（directory id），将bool改为int型，当值为0或者空时，代表该记录为文件；若值不为0的数时，代表是目录id，用于文档记录索引

3. dir字段类型应该为int，是该文件或目录的目录id或父目录id（应该是云婷忘记改了）

image.png

方案解释：

1. 字段数量上减少了一个字段，通过一个did字段，由于int类型0值得特性，既起到了辨别文件和目录的作用，又可以作为目录id让文件索引。因为之前的id同时用于文件和目录，显然int类型是不够存TB或者PB级的数据量级，若更大long之类的，凸显了mongo这种json存储的空间浪费问题

2. 方案本质相当于把原来的fod字段和id字段合并，降低了fod字段一个不是判断相同等级记录的bool型字段的冗余性，又减小了大量文件记录的id值带来的存储空间浪费

3. did依旧是自增id，也考虑过用uuid或者md5这种随机数，但是感觉目录记录的数量级没那么大，几乎是可以数的，而且int类型范围内基本没有这种唯一随机的数值生成策略，所以不好用随机方法

4. 虽然did需要通过后端脚本（或者Django）写自增策略，但是考虑到目录记录极少，所以在分片+副本集的集群中发生上述自增丢失问题概率较小，宕机复制发生错误的可能性也很小，个人想象可以这种情况可以接受

5. 如果严格考虑自增id对集群的影响，就可以将did设置为string型，用uuid或者md5策略生成，当值为空时是文件，同时dir字段也改为string。但是这种随机策略生成的字符串长度较长，与其这样还不如用自带的_id这个十二位长度的uuid作为索引，did字段只用一个bool来判断类型就好了（ps：如果有长度合适的随机数策略可以选择，我看上面UR最后的随机数就可以）

   
   
   

   image.png

6. 5中讲到的具体这两种策略怎么这种大家可以考虑下，前者用int更在乎存储空间的优化，后者用随机数更在乎集群数据安全性。由于个人考虑目录记录极少，更偏向前者。（方案选择的关键就在目录记录的多少，少，就可以用前者；多，就尽量后者，安全第一！）