MongoDB设计规范1.1 mongoDB库的设计l 不能为空字符串(“”)l 不能以$开头l 不能包含.(点号)和空字符串l 数据库名区分大小写(建议数据库名全部使用小写)l 禁止使用数字打头的库名l 数据库名最多为 64字符l 不要与系统保留的数据库名相同,这些数据库包括:admin,local,config等1.2 mongoDB集合的设计l 集合名全部小写l 禁止使用任何 " _ "（下...
MongoDB设计规范
1.1 mongoDB库的设计
- l 不能为空字符串(“”)
- l 不能以$开头
- l 不能包含.(点号)和空字符串
- l 数据库名区分大小写(建议数据库名全部使用小写)
- l 禁止使用数字打头的库名
- l 数据库名最多为 64字符
- l 不要与系统保留的数据库名相同,这些数据库包括:admin,local,config等
1.2 mongoDB集合的设计
- l 集合名全部小写
- l 禁止使用任何 " _ "（下划线） 以外的特殊字符
- l 禁止使用数字打头的集合名称
- l 集合名称最多为 64字符
- l 一个库中写入较大的集合会影响其它集合的读写性能
- l 如果评估单集合数据量较大，可以将一个大表拆分为多个小表，然后将每一个小表存放在独立的库中，由于MongoDB是库级锁，因此这样做可以大幅减少并发写入带来的锁争用问题
- l 集合名不能为空字符串(“”)
- l 不能包含0或空字符,这个字符表示键的结尾
- l 集合名不能以”system.”开头,此前缀是系统本身保留的
- l 集合名不能包含$字符(注:可包含 . 点号)
1.3 mongoDB文档的设计
- l 文档中的 key 禁止使用任何 " _ "（下划线）以外的特殊字符
- l 尽量使用自定义 _id ，如：向 _id 中写入自定义内容（默认索引）
- l 尽量不要让数组字段成为查询条件
- l 尽量存放统一了大小写后的数据
- l 尽量将同样类型的文档存放在一个集合中，将不同类型的文档分散在不同的集合中
- l 相同类型的文档能够大幅度提高索引利用率，如果文档混杂存放则可能会出现查询经常需要全表扫描的情况
- l 尽可能的缩短key的长度(注意是尽可能！会涉及到性能问题)
1.4 mongoDB索引的设计
- 优先使用覆盖索引（特定场景）
所有的查询字段是索引的一部分
所有的查询返回字段在同一个索引中
2. 备注-查询会默认带出_id
！尽量遵循最左前缀原则
l 索引名称长度不要超过 128 字符
l 应尽量综合评估查询场景,通过评估尽可能的将单列索引并入组合索引以降低索引数量，结合上面2点
l 在创建组合索引的时候，应评估索引中包含的字段，尽量将数据基数大的字段放在组合索引的前面
l 在数据量较大的时候，MongoDB 索引的创建是一个缓慢的过程，所以应当在上前线或数据量变得很大前尽量评估，按需创建会用到的索引
l MongoDB 的索引创建是库级锁，在索引创建时该集合所在库不可读写，所以如需添加索引，请联系 DBA
l 特别注意基于地理位置的索引建立时会带来的问题。
建议
尽量在创建集合时，规划好索引，在集合为空的时候创建索引
针对已有大量数据的集合，尽量后台建索引--后台建索引时并不是 bulk cursor，而是使用普通的 cursor 逐条插入，故不会去竞争 checkpoint 的锁
1.5 查询优化
MongoDB可以自动对查询进行优化并尽可能高效的对查询进行评估。评估通常包括基于谓词的数据选择和基于排序类别的数据排序。查询优化器会周期性的执行多种查询计划并选择性能变现最好的索引。这种经验式测试结果会以缓存查询计划存储下来并周期性执行。
MongoDB有explain工具，可以显示每个查询优化前后的信息，包括：
l 文档返回数
l 文档读取数
l 使用了哪个索引
l 查询是否被覆盖，如果覆盖了，则文档不需要读取以返回数据
l 内存排序是否执行了，如果执行了，就意味着加入索引会更高效
l 索引扫描数量
l 查询多长时间可以返回结果（仅限于使用executionStats模式）
l 那个可选择的查询方案被否决了（仅限于allPlansExecution模式）
如果查询的过程花费不到1ms，那么解释计划会显示0ms，通常，在一个优化过的系统中，查询时间就不应该超过1ms。执行计划确定后，之前的缓存查询计划就会放弃，但是多样的测试索引计划还是会重复执行保证最佳的执行计划会得到实施。查询计划可以在不执行查询的前提下对查询过程进行估算并返回结果，DBA不需要等到查询过程执行完就可以评估使用哪个查询计划。
1.6 注意点
- 索引的数量越少越好
每当你建立一个索引时，系统会为你添加一个索引表，用于索引指定的列，然而当你对已建立索引的列进行插入或修改时，数据库则需要对原来的索引表进行重新排序，重新排序的过程非常消耗性能，但应对少量的索引压力并不是很大，但如果索引的数量较多的话对于性能的影响可想而知。所以在创建索引时需要谨慎建立索引，要把每个索引的功能都要发挥到极致，也就是说在可以满足索引需求的情况下，索引的数量越少越好。
2. 索引列颗粒越小越好
什么叫颗粒越小越好？在索引列中每个数据的重复数量称为颗粒，也叫作索引的基数。如果数据的颗粒过大，索引就无法发挥该有的性能。例如，我们拥有一个"age"列索引，如果在"age"列中，20岁占了50%，如果现在要查询一个20岁，名叫"Tom"的人，我们则需要在表的50%的数据中查询，索引的作用大大降低。所以，我们在建立索引时要尽量将数据颗粒小的列放在索引左侧，以保证索引发挥最大的作用。
1.7 shard key选择
- 分片方式
范围分片，能很好的支持范围分片
hash分片，读写更好的均分到各个shard
2. shard key选择应结合实际业务需求，需要避免的问题
1. shard key 取值范围太小（low cardinality）
2. shard key某个值的文档特别多，这样导致单个chunk特别大（jumbo chunk），会影响chunk迁移及负载均衡
3. 根据非shard key进行查询，更新操作会变成scatter-gather查询，影响效率
备注：执行创建片键时，若collection不为空，则需要提前创建好索引；反之，则为创建该索引
最低0.47元/天 解锁文章
3901
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
