mongodb设计命名规范

《mongodb设计命名规范》由会员分享，可在线阅读，更多相关《mongodb设计命名规范（7页珍藏版）》请在金锄头文库上搜索。

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.创建集合规则 不同的业务场景是可以配置进行不同的配置; a.如果是读多写少的

4、表在创建时我们可以尽量将 page size 设置的比较 小 ，比如 16KB，如果表数据量不太大( “internal_page_max=16KB，leaf_page_max=16KB，leaf_val ue_max=8KB，os_cache_max=1GB“ b.如果这个读多写少的表数据量比较大，可以为其设置一个压缩算法，例 如： “block_compressor=zlib， internal_page_max=16KB，leaf_page_max=16KB，leaf_value_max=8KB“ c.注意：该 zlib 压缩算法不要使用，对 cpu 消耗特别大，如果使用 snapp 消

5、耗 20% cpu，而且使用 zlib 能消耗 90%cpu，甚至 100%d.如果是写多读少的表，可以将 leaf_page_max 设置到 1MB，并开启 压缩算法，也可以为其制定操作系统层面 page cache 大小的 os_cache_max 值，让它不会占用太多的 page cache 内存，防止影 响读操作； e.案例db.createCollection(“logs“, storageEngine: wiredTiger: configString: “internal_page_max=16KB, leaf_page_max=16KB,leaf_value_max=8KB,o

6、s_cache_m ax=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 leaf_value_max=8KB 默认为 64MB 3.文档 1.文档中的 key 禁止使用任何_

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

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

9、素,那么等于一次创建了 11 条索引,这是 索引体积大幅度增大的根本原因。 另外,如果组合索引中存在数组字段, 那么 MongoDB 会为每一个元素与其它字段的组合创建一个独立的索引, 例如: 为数组字段a:x,y,z和b:qqq添加索引a:1,b:1,实 际上添加的索引为: a:x:1,b:1 a:y:1,b:1 a:z:1,b:1 如果一个组合索引中存在两个数组字段,那么索引的数量将是两个数组字段中 元素的笛卡儿积,所以 MongoDB 不允许索引中存在一个以上的数组字段。 5.如果字段较大，应尽量压缩存放 某业务上线后一直很正常,但在放量 3 倍之后发现 MongoDB 服务器的网 卡流

10、量报警,IO 压力报警,排查中发现,该业务讲一个超长的文本字段存 放在 MongoDB 中,而这个字段的平均体积达到了 7K。在并发为 2000QPS 的场景下,每次取出 120 条数据,导致这个 MongoDB 每秒钟 要发送将 近 100MB 的数据,而对于数据库而言,读写均为随机 IO,所以 在如此大的数据吞吐场景中,IO 达到了报警阈值。 由于文本是一个容易压缩的样本, 所以我们对该字段进行了压缩存放,使其平 均体积降低到了 2K,而解压在业务端进行处理,最终将吞吐降低到了 20MB/S 左右。 如果字段较大且会成为查询条件，例如一长串的 url，尽量转成 md5 后存放 某业务上线前

11、进行压力测试,测试中发现某个场景下的查询性能不够理想,排 查中发现该场景的查询条件类似:url:xxxx,而 url 字段中的值大部 分都很长很长,该字段的平均体积达到了 0.5K,在这种情况下索引的体 积会变得很大从而导致虽然请求虽然能够走索引但效率并不够理想,于是 dba 配合业务开发一起对该场景进行优化: 1.将该字段的存放的内容由真实的 url 改为 url 内容 md5 后的值,字段 体积得到了大幅度缩小,固定在了 32 位 2.查询时,用户请求通过 url 查询,而此时程序会将该 url 进行 md5,然 后用得到的值进行查询,由于所以体积大幅度缩小,所以查询速度有了极 大的提高,

12、优化完毕后再次进行压力测试,性能达标,为之前的 6 倍。 6.由于 MongoDB 是大小写敏感的，如果字段无需大小写敏感，为了提高查询效 率应尽量存放统一了大小写后的数据，如：全部小写或为该字段增加一个统一 了大小写的辅助字段； 某业务需要根据字段a:XxX来进行查询,在 MongoDB 中 a 的值是大小 写敏感的,并且无法配置为忽略大小写,但该业务场景为了满足查询需求 而需要忽略大小写,这个大小写敏感与否的矛盾导致业务需要使用正则来 进行匹配:a:/xxx/i,i 参数在正则中表示忽略大小写,上线后发现, 查询性能非常低下,在一个拥有 200 万文档的集合中一次查询需要消耗 2.87 秒

13、,并发达到 50QPS 的时候 MongoDB 实例所在服务器的 CPU 就 跑到了 973%。MongoDB 在查询条件中使用正则的时候,能够像普通精确匹配一样使用 索引达到高效率的查询,但一旦使用了参数 i 来忽略大小写查询优化器就 需要对每一个数据的大小写进行调整然后再进行匹配,此时这个请求就变 成了全表扫描,这就是效率低下的根本原因。 对于这种场景可以采用新建一个统一了大小的字段,例如全部小写:假设原字段 为:a:aAbB,那么为其添加一个全部为小写的对应字段:a_low:aabb然 后通过字段 a_low 进行查询就能达到精确匹配,按照该方案改进后,该场景的 查询耗时降低到了 2 毫

14、秒 虽然新增字段导致实例会变大一些,但对于换来性能 的大幅度提升还是非常值得的。 7.不要存放太长的字符串，如果这个字段为查询条件，那么确保该字段的值不超 过 1KB； 8.MongoDB 的索引仅支持 1K 以内的字段，如果你存入的数据长度超过 1K，那 么它将无法被索引； 4.索引 1.MongoDB 的组合索引使用策略与 MySQL 一致，遵循“最左原则”; 2.索引名称长度不要超过 128 字符; 3.应尽量综合评估查询场景,通过评估尽可能的将单列索引并入组合索引以降低 所以数量，结合 1，2 点; MongoDB 的组合索引规则和 MySQL 一样,都遵循最左原理,假设一个组 合索引

15、为:a:1,b:1,c:1,那么以下条件的查询是可以被用到的:a:1 a:1,b:2 a:1,b:2,c:3 以下条件的查询是不能用到索引的:b:1 b:1:c:2 c:2 另外在设计索引的时候可以通过该原理减少索引的数目,如果需要通过 a:xxx或a:xxx,b:xxx来进行查询,那么创建索引: a:1,b:1 即可同时满足这两个查询场景而无需再单独创建a:1索引。 4.在创建组合索引的时候，应评估索引中包含的字段，尽量将数据基数大(唯一 值多的数据)的字段放在组合索引的前面； 某业务某场景下的查询十分缓慢,大概需要 1.7 秒左右,需要进行调优, 该场景的查询和对应索引如下: 查询:nam

16、e:baidu,status:0 索引:status:1,name:1 乍一看没什么问题,因为查询和索引十分匹配,但对该集合分析后发现该 集合一共有 150 万文档,而 status=0 的有 1499930 由于这基本上占 了 99%的文档数目(数据基数很小),所以导致虽然使用了索引,但依然需 要从 149 万行数据中找到 name=baidu 的数据但 name 字段则有大量不 同的数据(数据基数很大),所以如果将该组合索引调整为 name 在前,该查询即可先通过 name 字段抽出较少的数据,再通过 status 进行过滤, 就快了: name:1.status:1调整后查询耗时降低到 35 毫秒。 5.在数据量较大的时候，MongoDB 索引的创建是一个缓慢的过程