2023最新MongoDB规范

迷南。 2024-03-26 14:08 67阅读 0赞

## 前言 ##

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 个字符。

1.  【强制】在创建新的库前应尽量评估该库的体积、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”\} \}  
\})

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压缩算法不要使用，对cpu消耗特别大，如果使用snapp消耗20% cpu，而且使用zlib能消耗90%cpu，甚至100%

d. 如果是写多读少的表，可以将 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中写入自定义的内容。

4.【建议】尽量不要让数组字段成为查询条件;

5.【建议】如果字段较大，应尽量压缩存放;

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

6.【建议】尽量存放统一了大小写后的数据 ;

7.【建议】如果评估单集合数据量较大，可以将一个大表拆分为多个小表，然后将每一个小表存放在独立的库中或者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，not，exists，nin，or，尽量在业务中不要使用；

exist：因为松散的文档结构导致查询必须遍历每一个文档  
ne：如果当取反的值为大多数，则会扫描整个索引  
not：可能会导致查询优化器不知道应当使用哪个索引，所以会经常退化为全表扫描  
nin：全表扫描  
or：有多少个条件就会查询多少次，最后合并结果集，所以尽可能的使用in

13.【建议】不要一次取出太多的数据进行排序，MongoDB 目前支持对32MB以内的结果集进行排序，如果需要排序，那么请尽量限制结果集中的数据量；

14.【建议】MongoDB 的聚合框架非常好用，能够通过简单的语法实现复杂的统计查询，并且性能也不错；

15.【建议】如果需要清理掉一个集合中的所有数据，那么 remove() 的性能是非常低下的，该场景下应当使用 drop()；remove() 是逐行操作，所以在删除大量数据的时候性能很差；

16.【建议】在使用数组字段做为查询条件的时候，将与覆盖索引无缘;这是因为数组是保存在索引中的，即便将数组字段从需要返回的字段中剔除，这样的索引仍然无法覆盖查询；

17.【建议】在查询中如果有范围条件,那么尽量和定值条件放在一起进行过滤,并在创建索引的时候将定值查询字段放在范围查询字段前。

## 六、连接规范 ##

1.【强制】正确连接副本集，副本集提供了数据的保护、高可用和灾难恢复的机制。如果主节点宕 机，其中一个从节点会自动提升为从节点。

2.【建议】合理控制连接池的大小，限制连接数资源，可通过Connection String URL中的 maxPoolSize 参数来配置连接池大小。

3.【建议】复制集读选项 默认情况下，复制集的所有读请求都发到Primary，Driver可通过设置的Read Preference 来将 读请求路由到其他的节点。

2023最新MongoDB规范

发表评论取消回复

还没有评论，来说两句吧...

相关阅读

相关 2023最新IDEA下载安装教程

相关 java高频面试题(2023最新)

相关 2023最新MongoDB规范

相关 2023最新MYSQL面试题总结

相关 2023最新JAVA基础面试题

相关华为面经整理（2023最新）

相关 SpringMVC常见面试题(2023最新)

相关 Redis高频面试题(2023最新)

相关 java高频面试题(2023最新)

相关 mongoDB相关规范