2020最新MongoDB规范你应该了解一下

共 4798字,需浏览 10分钟

 ·

2020-07-28 16:00

前言

MongoDB是非关系型数据库的典型代表,DB-Engines Ranking 数据显示,近年来,MongoDB在 NoSQL领域一直独占鳌头。MongoDB是为快速开发互联网应用 而设计的数据库系统,其数据模型和持 久化策略就是为了构建高读/写的性能,并且可以方面的弹性拓展。随着MongoDB的普及和使用量的快 速增长,为了规范使用,便于管理和获取更高的性能,整理此文档。我们从 数据库设计规范、集合设计 规范、索引设计规范、文档设计规范、API使用规范、连接规范等方面进行阐述和要求。

存储选型

  1. 主要解决大量数据的访问效率问题, 减少mysql 压力。MongoDB内建了多种数据分片的特性,可 以很好的适应大数据量的需求。内建的Sharding分片特性避免系统在数据增长的过程中遇到性能 瓶颈。
  2. 复杂数据结构,以多种不同查询条件去查询同一份数据。MongoDB的BSON数据格式非常适合文 档化格式的存储及查询;支持丰富的查询表达式,可轻易查询文档中内嵌的对象和数组及子文档。
  3. 非事务并且关联性集合不强的都可以使用(MongoDB4.0+支持跨Collection事务,MongoDB4.2+支持跨Shard事务)
  4. 无多文档事务性需求及复杂关联检索
  5. 业务快速迭代,需求频繁变动业务
  6. 数据模型不固定,存储格式灵活场景
  7. 单集群读写并发过大无法支撑业务增长
  8. 期望 5 个 9 的数据库高可用场景

一、库设计规范

  1. 【强制】数据库命名规范:db_xxxx

  2. 【强制】库名全部小写,禁止使用任何_以外的特殊字符,禁止使用数字打头的库名,如:123_abc

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

  3. 【强制】数据库名称最多为 64 个字符。

  4. 【强制】在创建新的库前应尽量评估该库的体积、QPS等,提前与DBA讨论是应该新建一个库还是专门为该库创建一个新的集群;

二、集合设计规范

  1. 【强制】集合名全部小写,禁止使用任何_以外的特殊字符,禁止使用数字打头的集合名,如:123_abc,禁止system打头; system是系统集合前缀;

  2. 【强制】集合名称最多为64字符;

  3. 【建议】一个库中写入较大的集合会影响其它集合的读写性能,如果业务比较繁忙的集合在一个DB中,建议最多80个集合,同时也要考虑磁盘I/O的性能;

  4. 【建议】如果评估单集合数据量较大,可以将一个大表拆分为多个小表,然后将每一个小表存放在独立的库中或者sharding分表;

  5. 【建议】MongoDB的集合拥有"自动清理过期数据"的功能,只需在该集合中文档的时间字段增加一个TTL索引即可实现该功能,但需要注意的是该字段的类型则必须是mongoDate(),一定要结合实际业务设计是否需要;

  6. 【建议】设计轮询集合---集合是否设计为Capped限制集,一定要结合实际业务设计是否需要;

    创建集合规则

    不同的业务场景是可以使用不同的配置;

    db.createCollection("logs",
    { "storageEngine": { "wiredTiger": 
    { "configString": "internal_page_max=16KB,
       leaf_page_max=16KB,leaf_value_max=8KB,os_cache_max=1GB"} } 
    })
    1. 如果是读多写少的表在创建时我们可以尽量将 page size 设置的比较小 ,比如 16KB,如果表数据量不大 ("internal_page_max=16KB,leaf_page_max=16KB,leaf_value_max=8KB,os_cache_max=1GB")

    2. 如果这个读多写少的表数据量比较大,可以为其设置一个压缩算法,例如:"block_compressor=zlib, internal_page_max=16KB,leaf_page_max=16KB,leaf_value_max=8KB"

    3. 注意:该zlib压缩算法不要使用,对cpu消耗特别大,如果使用snapp消耗20% cpu,而且使用zlib能消耗90%cpu,甚至100%

    4. 如果是写多读少的表,可以将 leaf_page_max 设置到 1MB,并开启压缩算法,也可以为其制定操作系统层面 page cache 大小的 os_cache_max 值,让它不会占用太多的 page cache 内存,防止影响读操作;

      读多写少的表 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 默认为64M

三、文档设计规范

  1. 【强制】集合中的 key 禁止使用任何 "_"(下划线)以外的特殊字符。
  2. 【强制】尽量将同样类型的文档存放在一个集合中,将不同类型的文档分散在不同的集合中;相同类型的文档能够大幅度提高索引利用率,如果文档混杂存放则可能会出现查询经常需要全表扫描的情况;
  3. 【建议】禁止使用_id,如:向_id中写入自定义内容;

说明:MongoDB的表与InnoDB相似,都是索引组织表,数据内容跟在主键后,而_id是MongoDB中的默认主键,一旦_id的值为非自增,当数据量达到一定程度之后,每一次写入都可能导致主键的二叉树大幅度调整,这将是一个代价极大的写入, 所以写入就会随着数据量的增大而下降,所以一定不要在_id中写入自定义的内容。

  1. 【建议】尽量不要让数组字段成为查询条件;
  2. 【建议】如果字段较大,应尽量压缩存放;

不要存放太长的字符串,如果这个字段为查询条件,那么确保该字段的值不超过1KB;MongoDB的索引仅支持1K以内的字段,如果你存入的数据长度超过1K,那么它将无法被索引

  1. 【建议】尽量存放统一了大小写后的数据 ;
  2. 【建议】如果评估单集合数据量较大,可以将一个大表拆分为多个小表,然后将每一个小表存放在独立的库中或者sharding分表;

四、索引设计规范

  1. 【强制】MongoDB 的组合索引使用策略与 MySQL 一致,遵循"最左原则";
  2. 【强制】索引名称长度不要超过 128 字符
  3. 【强制】应尽量综合评估查询场景,通过评估尽可能的将单列索引并入组合索引以降低所以数量,结合1,2点;
  4. 【建议】优先使用覆盖索引
  5. 【建议】创建组合索引的时候,应评估索引中包含的字段,尽量将数据基数大(唯一值多的数据)的字段放在组合索引的前面;
  6. 【建议】MongoDB 支持 TTL 索引,该索引能够按你的需要自动删除XXX秒之前的数据并会尽量选择在业务低峰期执行删除操作;看业务是否需要这一类型索引;
  7. 【建议】在数据量较大的时候,MongoDB 索引的创建是一个缓慢的过程,所以应当在上线前或数据量变得很大前尽量评估,按需创建会用到的索引;
  8. 【建议】如果你存放的数据是地理位置信息,比如:经纬度数据。那么可以在该字段上添加 MongoDB 支持的地理索引:2d 及 2dsphere,但他们是不同的,混用会导致结果不准确;

五、API使用规范

  1. 【强制】在查询条件的字段或者排序条件的字段上必须创建索引。
  2. 【强制】查询结果只包含需要的字段,而不查询所有字段。
  3. 【强制】在文档级别更新是原子性的,这意味着一条更新 10 个文档的语句可能在更新 3 个文档后由于某些原因失败。应用程序必须根据自己的策略来处理这些失败。
  4. 【建议】单个文档的BSON size不能超过16M;
  5. 【建议】禁用不带条件的update、remove或者find语句。
  6. 【建议】限定返回记录条数,每次查询结果不超过 2000 条。如果需要查询 2000 条以上的数据,在代码中使用多线程并发查询。
  7. 【建议】在写入数据的时候,如果你需要实现类似 MySQL 中 INSERT INTO ON DUPLICATE KEY UPDATE 的功能,那么可以选择 upsert() 函数;
  8. 【建议】写入大量数据的时候可以选择使用 batchInsert,但目前 MongoDB 每一次能够接受的最大消息长度为48MB,如果超出48MB,将会被自动拆分为多个48MB的消息;
  9. 【建议】索引中的-1和1是不一样的,一个是逆序,一个是正序,应当根据自己的业务场景建立适合的索引排序,需要注意的是{a:1,b:-1} 和 {a:-1,b:1}是一样的;
  10. 【建议】在开发业务的时候尽量检查自己的程序性能,可以使用 explain() 函数检查你的查询执行详情,另外 hint() 函数相当于 MySQL 中的 force index();
  11. 【建议】如果你结合体积大小/文档数固定,那么建议创建 capped(封顶)集合,这种集合的写入性能非常高并无需专门清理老旧数据,需要注意的是 capped 表不支持remove() 和 update()操作;
  12. 【建议】查询中的某些 ne,exists,or,尽量在业务中不要使用;

ne:如果当取反的值为大多数,则会扫描整个索引
nin:全表扫描in


  1. 【建议】不要一次取出太多的数据进行排序,MongoDB 目前支持对32MB以内的结果集进行排序,如果需要排序,那么请尽量限制结果集中的数据量;
  2. 【建议】MongoDB 的聚合框架非常好用,能够通过简单的语法实现复杂的统计查询,并且性能也不错;
  3. 【建议】如果需要清理掉一个集合中的所有数据,那么 remove() 的性能是非常低下的,该场景下应当使用 drop();remove() 是逐行操作,所以在删除大量数据的时候性能很差;
  4. 【建议】在使用数组字段做为查询条件的时候,将与覆盖索引无缘;这是因为数组是保存在索引中的,即便将数组字段从需要返回的字段中剔除,这样的索引仍然无法覆盖查询;
  5. 【建议】在查询中如果有范围条件,那么尽量和定值条件放在一起进行过滤,并在创建索引的时候将定值查询字段放在范围查询字段前;

六、连接规范

  1. 【强制】正确连接副本集,副本集提供了数据的保护、高可用和灾难恢复的机制。如果主节点宕 机,其中一个从节点会自动提升为从节点。
  2. 【建议】合理控制连接池的大小,限制连接数资源,可通过Connection String URL中的 maxPoolSize 参数来配置连接池大小。
  3. 【建议】复制集读选项 默认情况下,复制集的所有读请求都发到Primary,Driver可通过设置的Read Preference 来将 读请求路由到其他的节点。

 文末送书

ps:今天开始后面会有一个长期送书计划,会把广告恰饭的一部分收入回馈给粉丝。


参与形式也都不一样,本期送书关键字为:0724123456


在后台回复即可以抽奖了。如图所示

挑选了3本书籍,中奖者可随意指定其中一本。

事实证明:参与抽奖和中奖的每次也都是一小部分人


推荐阅读:

前脚跟产品扯完皮,后脚同事把我项目代码分支删了
一次分表踩坑实践的探讨
阿里孤尽:Code Review 是一场苦涩但有意思的修行
彻底弄懂java中的常量池

浏览 17
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报
评论
图片
表情
推荐
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报