前言
mongo的使用过程中，我们有了越来越多的数据，当数据到达千万级之后，数据处理的效率就是必须提上日程的东西了。
比如：当我们进行分页时，会发现一个问题，刚开始的跳过2000展示2000，返回速率很快，毫秒级别，但是当你跳过4000000（400W）展示2000,那可能就需要5秒以上，如果你再加一些查询条件，反应速率可能更慢。所以，千万级以上的大数据处理优化势在必行，
以下，为一部分数据优化方案。
1.优化方案
1.1 数据模型优化
数据反应缓慢的一个主要问题就是表的数据太大，在此我们说数据占用的空间大，有些数据模型，一条数据中就有几十、上百个字段，对应的，即使数据仅仅有几百万条，也会查的非常缓慢，因此，我们就要优化数据模型；
有些人在表中存储数组套对象这种反mongo的结构！！！
因此，我们需要根据业务场景，对需要查询主要的字段进行单独存储，已便于后续进行索引优化；
1.2 数据库分表
当数据量超过一定量级后，查询性能会明显下降，我们就可以根据业务场景记下你那个分库、分表，较少查询数据是的数据分析总量，就像我们日常对log进行分片存储一样；
最简单的就是，我们可以按照年做分割，将不同年份的数据存入不同的数据表中，在查询之前，判断数据的时间范围，根据不同的时间去不同的表进行查询；
其次一个分表优化，与模型优化一致，提取重要信息字段，将其单拉一个表/视图，通过减少表的字段，来减少表的体积；
缺点：如果查询的时间范围横跨很大，我们要对多张表进行查询，增加了查询次数，并且分页问题比较难以处理，因此要根据实际的业务场景来决定分库分表的粒度；
1.3 缓存数据
1.3.1 接口缓存
最有效的api性能优化手段，但弊端也很明显，缓存时间过长会导致最新的数据无法及时同步，所以需要根据实际场景选择合适的缓存时间；
1.3.2 恒定数据缓存
对于那些一旦产生后就不会再更新的数据，考虑将他们放入缓存，减少mongo查询次数
场景1：跨年后，去年的数据会恒定不变的存入数据库，此时可将这部分数据缓存至内存中
场景2：有时我们的数据库中只存储了id，name信息存储在其他表中，此时我们可以将id和name的映射关系存入内存，减少mongo查询次数
1.4 多节点读写分离
大量索引会影响数据的写入速率，同样，同意节点如果在写入大量的数据时，内存使用率过高，也是会影响数据的读取速率；
如果拥有多个Mongo节点，则可以配置读写分离，所有只涉及查询的数据库连接集中分配到某个读节点；
1.5 索引优化
mongo查询可以使用.explain("executionStats")进行分析，最主要是要看是否避免全表扫描、是否使用索引、是否避免内存排序；
索引的原理是在内存中建立了一个排序的列表，key是被添加索引字段的值，value是字段对应document的物理地址，通过查询这张表来避免全文索引，提升查询速度，同时每次给collection插入数据时也会同时给索引中新加入一条数据；
常用的索引类型：普通索引、text、hashed
- 普通索引：查询时需要按照该字段排序，加普通索引最合适
- text：查询时需要按照该字段模糊查询，加text索引最合适
- hashed：查询条件包含该字段的==条件，加hashed索引最合适
索引的本质就是利用空间换时间，因为建立索引需要占用很大的存储空间，并且影响数据插入性能，因此不能滥用索引；
关于索引的详细使用，可以参考以下文章
https://www.yuque.com/morange/morange/ohryo0
1.6 查询语句优化
查询条件优化是最容易执行的，也是最难执行；但是可以参考下面几个原则：
原则一：查询结果和条件不包含所有字段，则需要有限使用projection，只返回需要的字段，尽量减少无效字段的返回与查询；
原则二：优先使用match，再使用sort和group；
小技巧：可以使用.lean（）方法进行读取数据，但是要注意，lean()方法会将mongo的原子性破坏为json数组，所以，在使用lean()方法时，mongoose的Getters方法会失效！！！按需求使用！
博主寄语
保持好的习惯，才会让你持续进步
