MongoDB线上实践指南-基础篇（一）

库

1. 库名全部小写，禁止使用任何`_`以外的特殊字符，禁止使用数字打头的库名，如：`123_abc`

   库以文件夹的形式存在，使用特殊字符或其它不规范的命名方式会导致命名混乱

2. 数据库名最多为64字符

3. 在创建新的库前应尽量评估该库的体积、QPS等，提前与DBA讨论是应该新建一个库还是专门为该库创建一个新的集群

   【案例一】某开发在拿到DBA提供的MongoDB后由于MongoDB的权限控制比较宽松,导致该业务的开发在创建集合的时候懒得与DBA讨论,而是随意的将所有集合都创建在一个库中,最初并没有什么问题,因为业务的请求量并不大。半年后,该业务增长到了一个比较大的量级,而此时开发人员上线了一个新的项目,该项目的写入量很大,大部分都为批量更新,由于所有集合都存放在一个库中,这个新项目的批量更新带来了频繁的库级锁,由于库级锁是排他的(在有锁的同时不可读写)开发发现:这个实例上的所有业务的数据库请求都变得极其缓慢。最后开发配合DBA一起将该库拆散到了多个新的库中,将一库N集合转换为单库单集合,性能问题迎刃而解。

集合

1. 1. 集合名全部小写，禁止使用任何`_`以外的特殊字符，禁止使用数字打头的集合名，如：`123_abc`，禁止system打头

      system是系统集合前缀

   2. 集合名称最多为64字符

   3. 为了避免库级锁带来的问题，应尽量对写入较大的集合使用“单库单集合”的结构，所以对于新增业务应尽量创建新库，而不是在现有库中创建新集合

      一个库中写入较大的集合会影响其它集合的读写性能

   4. 如果评估单集合数据量较大，可以将一个大表拆分为多个小表，然后将每一个小表存放在独立的库中，由于MongoDB是库级锁，因此这样做可以大幅减少并发写入带来的锁争用问题

      【案例2】某业务上线前进行压力测试(该业务为大量更新场景),在压测时发现更新量在1000/s以内的时候更新性能优秀(2ms左右),而在更新量达到2500/s之后更新性能严重下降(10ms左右),经过查看原因是由于并发过大导致锁争用严重,于是采取对应优化措施:开发针对这个大表做HASH分表处理,将一个集合拆分为16个集合并,将每个集合安置在独立的库中。这个方案理论上将此前的的锁争用消耗降低到了此前的1/16, 再次进行压测,结论是更新性能达到了5000/s(达到IO瓶颈),远超业务3000/s的要求。

   5. MongoDB的集合拥有“自动清理过期数据”的功能，只需在该集合中文档的时间字段增加一个TTL索引即可实现该功能，但需要注意的是该字段的类型则必须是mongoDate()

   本篇介绍了库、集合在命名和前期规划、拆分上的一些注意事项，下篇将介绍“文档”数据类型在实际使用过程中的注意事项和一些线上案例。