1、范文范例指导学习 MongoDB设计命名规范 1. 库 1. 库名全部小写 ， 禁止使用任何 _ 以外的特殊字符 ， 禁止使用数字打头的库名 ，如： 123_abc； 2. 库以文件夹的形式存在 ， 使用特殊字符或其它不规范的命名方式会导致命名混乱； 3. 数据库名最多为 64 字符； 4.在创建新的库前应尽量评估该库的体积、QPS 等 ， 提前与 DBA 讨论是应该新建 一个库还是专门为该库创建一个新的集群;
某开发在拿到DBA 提供的 MongoDB后由于 MongoDB的权限控制比较宽松, 导致该业务的开发在创建集合的时候懒得与DBA 讨论 ,而是随意的将所有集合 都创建在一个库中,最初并没有什么问题, 。

2、因为业务的请求量并不大 。
半年后 ,该业 务增长到了一个比较大的量级,而此时开发人员上线了一个新的项目,该项目的 写入量很大 ,大部分都为批量更新,由于所有集合都存放在一个库中,这个新项目 的批量更新带来了频繁的锁、I/O 平均等 。
最后开发配合DBA 一起将该库拆散 到了多个新的库中,将一库 N 集合转换为单库单集合,性能问题迎刃而解 。
2. 集合 1. 集合名全部小写 ， 禁止使用任何 _ 以外的特殊字符 ， 禁止使用数字打头的集合名 ， 如： 123_abc， 禁止 system 打头 ;
system 是系统集合前缀； 2. 集合名称最多为 64 字符； 3. 一个库中写入较大的集合会影响其它集合的读 。

3、写性能 ， 如果业务比较繁华的集 合在一个DB 中 ， 建议最多80 个集合 ， 同时也要考虑磁盘I/O 的性能； 4. 如果评估单集合数据量较大 ， 可以将一个大表拆分为多个小表 ， 然后将每一个小表存放在独立的库中或者 sharding 分表； 5. MongoDB 的集合拥有“自动清理过期数据”的功能 ， 只需在该集合中文档的 时间字段增加一个 TTL索引即可实现该功能 ，但需要注意的是该字段的类型则必须是 mongoDate()， 一定要结合实际业务设计是否需要； 6. 设计轮询集合 - 集合是否设计为 Capped 限制集 ， 一定要结合实际业务设计是否需要； 7. 创建集合规则 不同的业务场景是可以配置进行不 。

4、同的配置;
a. 如果是读多写少的表在创建时我们可以尽量将 page size 设置的比较 小， 比如 16KB， 如果表数据量不太大 ( internal_page_max=16KB，leaf_page_max=16KB，leaf_value_max=8KB ，os_cache_max=1GB b. 如果这个读多写少的表数据量比较大 ，可以为其设置一个压缩算法 ，例如： block_compressor=zlib，internal_page_max=16KB，leaf_page_max=16KB ，leaf_value_max=8KB c. 注意：该 zlib 压缩算法不要使 。

5、用 ， 对 cpu 消耗特别大 ， 如果使用 snapp 消耗 20% cpu， 而且使用 zlib 能消耗 90%cpu， 甚至 100% d. 如果是写多读少的表 ，可以将 leaf_page_max 设置到 1MB， 并开启压 缩算法 ， 也可以为其制定操作系统层面 page cache 大小的 word 版本整理分享 范文范例指导学习 os_cache_max值 ， 让它不会占用太多的page cache内存 ， 防止影 响读操作； e. 案例 db.createCollection( logs, storageEngine: wiredTiger: configString: internal_page 。

6、_max=16KB, leaf_page_max=16KB,leaf_value_max=8KB,os_cache_max= 1GB ) f. 说明 读多写少的表 internal_page_max=16KB 默认为 4KB leaf_page_max=16KB 默认为 32KB leaf_value_max=8KB 默认为 64MB os_cache_max=1GB 默认为 0 读多写少的表 而且数据量比较大 block_compressor=zlib 默认为 snappy internal_page_max=16KB 默认为 4KB leaf_page_max=16KB 默认为 32KB。

7、leaf_value_max=8KB 默认为 64MB 3. 文档 1. 文档中的 key 禁止使用任何 _ 以外的特殊字符； 2. 尽量将同样类型的文档存放在一个集合中 ， 将不同类型的文档分散在不同的集合中；相同类型的文档能够大幅度提高索引利用率 ， 如果文档混杂存放则可能会出现查询经常需要全表扫描的情况； 3. 禁止使用 _id， 如：向 _id 中写入自定义内容； 某业务的 MongoDB 在放量后出现严重的写入性能问题 ,大致为 :写入达到 300/s 的时候 IO 跑满 ,排查中发现 ,该业务在设计的时候为了方便 , 而将 _id 中写入了无 序的类似 md5 的数据 。
MongoDB 的 。

8、表与 InnoDB 相似 ,都是索引组织表 ,数据 内容跟在主键后 ,而 _id 是 MongoDB 中的默认主键 ,一旦 _id 的值为非自增 ,当数 据量达到一定程度之后 ,每一次写入都可能导致主键的二叉树大幅度调整 ,这将 是一个代价极大的写入 , 所以写入就会随着数据量的增大而下降 ,所以一定不要 在_id 中写入自定义的内容 。
4. 尽量不要让数组字段成为查询条件 某业务在一个表的数组字段上创建了一个索引,创建完毕之后发现表体积 增大了很多很多,排查发现是由于索引体积的大幅度增大导致在 MongoDB中 ,如果为一个数组字段添加索引, 那么 MongoDB会主动为这 个数组中的所有元 。

来源：(未知)

【学习资料】网址：/a/2021/0419/0021967454.html

标题：MongoDB|MongoDB设计命名规范方案