DBA规范利器： MongoDB模式校验

一直以来想做一个关于MongoDB的系列专题，但又没有中心思想，所以一直拖着，但现在想想大可不必。完全可以东打一枪，西放一炮。

所以有了今天的第一篇文章。

今天就来说说runCommand的collMod命令

首先我们先来盘算一下，MongoDB创建集合的方式有哪几种：

• 对希望创建的collection插入数据
  db..insert({: })
• 通过对collection创建索引
  db..createIndex({:1}
• 调用官方API接口显式创建
  db.createCollection(

从MongoDB 3.2开始，官方提供了相应接口对Schema作 强一致性 的策略：
当数据进行Insert或者Update的时候，通过创建集合时的validator option的参数控制，按照自定义的validation rules 或者 expressions，达到数据强一致性检查。

db.createCollection( "contacts",
   { validator: { $or:
      [
         { phone: { $type: "string" } },
         { email: { $regex: /@mongodb\.com$/ } },
         { status: { $in: [ "Unknown", "Incomplete" ] } }
      ]
   }
} )

这里提供了3种验证方式，满足一种即可。若是$and，则需要同时满足。

若不满足，MongoDB将会返回121错误，提示Document failed validation，插入0条。

该特性对MongoDB的Schemaless以及对DBA维护MongoDB表结构、规范等提供了相当大的帮助。

下面图1既是引用官方文档关于validation level的定义：

下面图2既是引用官方文档关于validation action的定义：

db.runCommand( { collMod: "contacts",
                 validator: { $or:
                    [
                       { phone: { $type: "string" } },
                       { email: { $regex: /@mongodb\.com$/ } },
                       { status: { $in: [ "Unknown", "Incomplete" ] } }
                    ]
                 },
                 validationLevel: "moderate",
                 validationAction: "warn"

} )

目前正准备着手先培训 开发遵守我们的MongoDB 数据规范，之后再开始对历史数据做清理。个人感觉是个大坑。。不过我选择跳。

总结

collMod的作用是非常明显的，可以帮助DBA去规避之前由于Schemaless而无法约束开发的窘境。可以就collMod来规范MongoDB的开发过程。
敦促我们DBA去有意识、有必要的使用强一致性对相应MongoDB数据作统一规划。