MongoDB基础入门到深入（七）建模、调优

文章目录

• 系列文章索引
• 十一、MongoDB开发规范
• 十二、MongoDB调优

• 1、三大导致MongoDB性能不佳的原因
• 2、影响MongoDB性能的因素
• 3、MongoDB性能监控工具

• （1）mongostat
• （2）mongotop
• （3）Profiler模块
• （4）查看操作日志
• （5）db.currentOp()
• （6）性能问题排查案例

• 十三、建模案例分析

• 1、建模案例分析1

• （1）需求
• （2）建模 - 不好的设计
• （3）建模 - 推荐的设计

• 2、建模案例分析2：多列数据结构

• （1）需求
• （2）建模 - 不好的模型设计
• （3）建模 - 一般的设计
• （4）建模 - 合理的设计

• 3、建模案例分析3 - 物联网时序数据库建模

• （1）需求
• （2）建模
• （3）总结

• 十四、MongoDB高级集群架构

• 1、两地三中心集群架构
• 2、全球多写集群架构

• 
  

十一、MongoDB开发规范

（1）命名原则。数据库、集合命名需要简单易懂，数据库名使用小写字符，集合名称使用统一命名风格，可以统一大小写或使用驼峰式命名。数据库名和集合名称均不能超过64个字符。
（2）集合设计。对少量数据的包含关系，使用嵌套模式有利于读性能和保证原子性的写入。对于复杂的关联关系，以及后期可能发生演进变化的情况，建议使用引用模式。
（3）文档设计。避免使用大文档，MongoDB的文档最大不能超过16MB。如果使用了内嵌的数组对象或子文档，应该保证内嵌数据不会无限制地增长。在文档结构上，尽可能减少字段名的长度，MongoDB会保存文档中的字段名，因此字段名称会影响整个集合的大小以及内存的需求。一般建议将字段名称控制在32个字符以内。
（4）索引设计。在必要时使用索引加速查询。避免建立过多的索引，单个集合建议不超过10个索引。MongoDB对集合的写入操作很可能也会触发索引的写入，从而触发更多的I/O操作。无效的索引会导致内存空间的浪费，因此有必要对索引进行审视，及时清理不使用或不合理的索引。遵循索引优化原则，如覆盖索引、优先前缀匹配等，使用explain命令分析索引性能。
（5）分片设计。对可能出现快速增长或读写压力较大的业务表考虑分片。分片键的设计满足均衡分布的目标，业务上尽量避免广播查询。应尽早确定分片策略，最好在集合达到256GB之前就进行分片。如果集合中存在唯一性索引，则应该确保该索引覆盖分片键，避免冲突。为了降低风险，单个分片的数据集合大小建议不超过2TB。
（6）升级设计。应用上需支持对旧版本数据的兼容性，在添加唯一性约束索引之前，对数据表进行检查并及时清理冗余的数据。新增、修改数据库对象等操作需要经过评审，并保持对数据字典进行更新。
（7）考虑数据老化问题，要及时清理无效、过期的数据，优先考虑为系统日志、历史数据表添加合理的老化策略。
（8）数据一致性方面，非关键业务使用默认的WriteConcern：1（更高性能写入）；对于关键业务类，使用WriteConcern：majority保证一致性（性能下降）。如果业务上严格不允许脏读，则使用ReadConcern：majority选项。
（9）使用update、findAndModify对数据进行修改时，如果设置了upsert：true，则必须使用唯一性索引避免产生重复数据。
（10）业务上尽量避免短连接，使用官方最新驱动的连接池实现，控制客户端连接池的大小，最大值建议不超过200。
（11）对大量数据写入使用Bulk Write批量化API，建议使用无序批次更新。
（12）优先使用单文档事务保证原子性，如果需要使用多文档事务，则必须保证事务尽可能小，一个事务的执行时间最长不能超过60s。
（13）在条件允许的情况下，利用读写分离降低主节点压力。对于一些统计分析类的查询操作，可优先从节点上执行。
（14）考虑业务数据的隔离，例如将配置数据、历史数据存放到不同的数据库中。微服务之间使用单独的数据库，尽量避免跨库访问。
（15）维护数据字典文档并保持更新，提前按不同的业务进行数据容量的规划。

十二、MongoDB调优

1、三大导致MongoDB性能不佳的原因

1. 慢查询2. 阻塞等待3. 硬件资源不足 1,2通常是因为模型/索引设计不佳导致的
排查思路：按1-2-3依次排查

2、影响MongoDB性能的因素

https://www.mongodb.com/docs/v4.4/tutorial/model-embedded-one-to-one-relationships-between-documents/https://www.mongodb.com/docs/v4.4/reference/connection-string/

https://www.mongodb.com/docs/manual/administration/production-notes/#hardware-considerations

3、MongoDB性能监控工具

（1）mongostat

mongostat是MongoDB自带的监控工具，其可以提供数据库节点或者整个集群当前的状态视图。该功能的设计非常类似于Linux系统中的vmstat命令，可以呈现出实时的状态变化。不同的是，mongostat所监视的对象是数据库进程。mongostat常用于查看当前的QPS/内存使用/连接数，以及多个分片的压力分布。mongostat采用Go语言实现，其内部使用了db.serverStatus()命令，要求执行用户需具备clusterMonitor角色权限。

mongostat -h 192.168.56.10 --port 28017 -uroot -proot --authenticationDatabase=admin --discover -n 300 2

参数说明:

-h：指定监听的主机，分片集群模式下指定到一个mongos实例，也可以指定单个mongod，或者复制集的多个节点。

–port：接入的端口，如果不提供则默认为27017。

-u：接入用户名，等同于-user。

-p：接入密码，等同于-password。

–authenticationDatabase：鉴权数据库。

–discover：启用自动发现，可展示集群中所有分片节点的状态。

-n 300 2：表示输出300次，每次间隔2s。也可以不指定“-n 300”，此时会一直保持输出。

指标说明

mongostat需要关注的指标主要有如下几个：

插入、删除、修改、查询的速率是否产生较大波动，是否超出预期。

qrw、arw：队列是否较高，若长时间大于0则说明此时读写速度较慢。 conn：连接数是否太多。

dirty：百分比是否较高，若持续高于10%则说明磁盘I/O存在瓶颈。

netIn、netOut：是否超过网络带宽阈值。

repl：状态是否异常，如PRI、SEC、RTR为正常，若出现REC等异常值则需要修复。

使用交互模式
mongostat一般采用滚动式输出，即每一个间隔后的状态数据会被追加到控制台中。从MongoDB 3.4开始增加了--interactive选项，用来实现非滚动式的监视，非常方便。

mongostat -h 192.168.56.10 --port 28017 -uroot -proot --authenticationDatabase=admin --discover --interactive -n 2

（2）mongotop

mongotop命令可用于查看数据库的热点表，通过观察mongotop的输出，可以判定是哪些集合占用了大部分读写时间。mongotop与mongostat的实现原理类似，同样需要clusterMonitor角色权限。

mongotop -h 192.168.56.10 --port=28017 -uroot -proot --authenticationDatabase=admin

默认情况下，mongotop会持续地每秒输出当前的热点表

指标说明

mongotop通常需要关注的因素主要包括：

热点表操作耗费时长是否过高。这里的时长是在一定的时间间隔内的统计值，它代表某个集合读写操作所耗费的时间总量。在业务高峰期时，核心表的读写操作一般比平时高一些，通过mongotop的输出可以对业务尖峰做出一些判断。

是否存在非预期的热点表。一些慢操作导致的性能问题可以从mongotop的结果中体现出来

#mongotop的统计周期、输出总量都是可以设定的
#最多输出100次，每次间隔时间为2s
mongotop -h 192.168.56.10 --port=28017 -uroot -proot --authenticationDatabase=admin -n 100 2

（3）Profiler模块

Profiler模块可以用来记录、分析MongoDB的详细操作日志。默认情况下该功能是关闭的，对某个业务库开启Profiler模块之后，符合条件的慢操作日志会被写入该库的system.profile集合中。Profiler的设计很像代码的日志功能，其提供了几种调试级别:

对当前的数据库开启Profiler模块:

# 将level设置为2，此时所有的操作会被记录下来。
db.setProfilingLevel(2)
#检查是否生效
db.getProfilingStatus()

slowms是慢操作的阈值，单位是毫秒；

sampleRate表示日志随机采样的比例，1.0则表示满足条件的全部输出。

# 如果希望只记录时长超过500ms的操作，则可以将level设置为1
db.setProfilingLevel(1,500)
# 还可以进一步设置随机采样的比例
db.setProfilingLevel(1,{slowms:500,sampleRate:0.5})

（4）查看操作日志

# 开启Profiler模块之后，可以通过system.profile集合查看最近发生的操作日志
db.system.profile.find().limit(5).sort({ts:-1}).pretty()

这里需要关注的一些字段主要如下所示:
op：操作类型，描述增加、删除、修改、查询。
ns：名称空间，格式为{db}.{collection}。
Command：原始的命令文档。
Cursorid：游标ID。
numYield：操作数，大于0表示等待锁或者是磁盘I/O操作。
nreturned：返回条目数。
keysExamined：扫描索引条目数，如果比nreturned大出很多，则说明查询效率不高。docsExamined：扫描文档条目数，如果比nreturned大出很多，则说明查询效率不高。
locks：锁占用的情况。
storage：存储引擎层的执行信息。
responseLength：响应数据大小（字节数），一次性查询太多的数据会影响性能，可以使用limit、batchSize进行一些限制。
millis：命令执行的时长，单位是毫秒。
planSummary：查询计划的概要，如IXSCAN表示使用了索引扫描。
execStats：执行过程统计信息。
ts：命令执行的时间点。

根据这些字段，可以执行一些不同维度的查询。比如查看执行时长最大的10条操作记录

#查看某个集合中的update操作日志
db.system.profile.find().limit(10).sort({millis:-1}).pretty()
#查看某个集合中的update操作日志
db.system.profile.find({op:"update",ns:"shop.user"})

注意事项
system.profile是一个1MB的固定大小的集合，随着记录日志的增多，一些旧的记录会被滚动删除。
在线上开启Profiler模块需要非常谨慎，这是因为其对MongoDB的性能影响比较大。建议按需部分开启，同时slowms的值不要设置太低。
sampleRate的默认值是1.0，该字段可以控制记录日志的命令数比例，但只有在MongoDB 4.0版本之后才支持。
Profiler模块的设置是内存级的，重启服务器后会自动恢复默认状态。

（5）db.currentOp()

Profiler模块所记录的日志都是已经发生的事情，db.currentOp()命令则与此相反，它可以用来查看数据库当前正在执行的一些操作。想象一下，当数据库系统的CPU发生骤增时，我们最想做的无非是快速找到问题的根源，这时db.currentOp就派上用场了。
db.currentOp()读取的是当前数据库的命令快照，该命令可以返回许多有用的信息，比如：
操作的运行时长，快速发现耗时漫长的低效扫描操作。
执行计划信息，用于判断是否命中了索引，或者存在锁冲突的情况。
操作ID、时间、客户端等信息，方便定位出产生慢操作的源头。

对示例操作的解读如下:

（1）从ns、op字段获知，当前进行的操作正在对test.items集合执行update命令。

（2）command字段显示了其原始信息。其中，command.q和command.u分别展示了update的查询条件和更新操作。

（3）“planSummary”：“COLLSCAN” 说明情况并不乐观，update没有利用索引而是正在全表扫描。

（4）microsecs_running：NumberLong（186070）表示操作运行了186ms，注意这里的单位是微秒。

优化方向：
value字段加上索引
如果更新的数据集非常大，要避免大范围update操作，切分成小批量的操作

#opid表示当前操作在数据库进程中的唯一编号。如果已经发现该操作正在导致数据库系统响应缓慢，则可以考虑将其“杀”死
db.killOp(4001)

db.currentOp默认输出当前系统中全部活跃的操作，由于返回的结果较多，我们可以指定一些过滤条件:

# 查看等待锁的增加、删除、修改、查询操作
db.currentOp({
    waitingForLock:true,
    $or:[
        {op:{$in:["insert","update","remove"]}},
        {"query.findandmodify":{$exists:true}}
    ]
})

#查看执行时间超过1s的操作
db.currentOp({
    secs_running:{$gt:1}
})
#查看test数据库中的操作
db.currentOp({
    ns:/test/
})

currentOp命令输出说明
currentOp.type：操作类型，可以是op、idleSession、idleCursor的一种，一般的操作信息以op表示。其为MongoDB 4.2版本新增功能。
currentOp.host：主机的名称。currentOp.desc：连接描述，包含connectionId。currentOp.connectionId：客户端连接的标识符。currentOp.client：客户端主机和端口。currentOp.appName：应用名称，一般是描述客户端类型。
currentOp.clientMetadata：关于客户端的附加信息，可以包含驱动的版本。currentOp.currentOpTime：操作的开始时间。MongoDB 3.6版本新增功能。
currentOp.lsid：会话标识符。MongoDB 3.6版本新增功能。
currentOp.opid：操作的标志编号。
currentOp.active：操作是否活跃。如果是空闲状态则为false。
currentOp.secs_running：操作持续时间（以秒为单位）。
currentOp.microsecs_running：操作持续时间（以微秒为单位）。
currentOp.op：标识操作类型的字符串。可能的值是：“none” “update” “insert”“query”“command” “getmore” “remove” “killcursors”。其中，command操作包括大多数命令，如createIndexes和findAndModify。
currentOp.ns：操作目标的集合命名空间。
currentOp.command：操作的完整命令对象的文档。如果文档大小超过1KB，则会使用一种$truncate形式表示。
currentOp.planSummary：查询计划的概要信息。
currentOp.locks：当前操作持有锁的类型和模式。
currentOp.waitingForLock：是否正在等待锁。
currentOp.numYields：当前操作执行yield（让步）的次数。一些锁互斥或者磁盘I/O读取都会导致该值大于0。
currentOp.lockStats：当前操作持有锁的统计。
currentOp.lockStats.acquireCount：操作以指定模式获取锁的次数。
currentOp.lockStats.acquireWaitCount：操作获取锁等待的次数，等待是因为锁处于冲突模式。acquireWaitCount小于或等于acquireCount。
currentOp.lockStats.timeAcquiringMicros：操作为了获取锁所花费的累积时间（以微秒为单位）。timeAcquiringMicros除以acquireWaitCount可估算出平均锁等待时间。
currentOp.lockStats.deadlockCount：在等待锁获取时，操作遇到死锁的次数。

注意事项
db.currentOp返回的是数据库命令的瞬时状态，因此，如果数据库压力不大，则通常只会返回极少的结果。
如果启用了复制集，那么currentOp还会返回一些复制的内部操作（针对local.oplog.rs），需要做一些筛选。
db.currentOp的结果是一个BSON文档，如果大小超过16MB，则会被压缩。可以使用聚合操作$currentOp获得完整的结果。

（6）性能问题排查案例

记一次 MongoDB 占用 CPU 过高问题的排查MongoDB线上案例：一个参数提升16倍写入速度

十三、建模案例分析

1、建模案例分析1

（1）需求

朋友圈评论内容管理

社交类的APP需求，一般都会引入“朋友圈”功能，这个产品特性有一个非常重要的功能就是评论体系。
先整理下需求：
这个APP希望点赞和评论信息都要包含头像信息：
点赞列表，点赞用户的昵称，头像；
评论列表，评论用户的昵称，头像；

数据查询则相对简单：
根据分享ID，批量的查询出10条分享里的所有评论内容；

（2）建模 - 不好的设计

跟据上面的内容，先来一个非常非常"朴素"的设计：

{
  "_id": 41,
  "username": "小白",
  "uid": "100000",
  "headurl": "http://xxx.yyy.cnd.com/123456ABCDE",
  "praise_list": [
    "100010",
    "100011",
    "100012"
  ],
  "praise_ref_obj": {
    "100010": {
      "username": "小一",
      "headurl": "http://xxx.yyy.cnd.com/8087041AAA",
      "uid": "100010"
    },
    "100011": {
      "username": "mayun",
      "headurl": "http://xxx.yyy.cnd.com/8087041AAB",
      "uid": "100011"
    },
    "100012": {
      "username": "penglei",
      "headurl": "http://xxx.yyy.cnd.com/809999041AAA",
      "uid": "100012"
    }
  },
  "comment_list": [
    "100013",
    "100014"
  ],
  "comment_ref_obj": {
    "100013": {
      "username": "小二",
      "headurl": "http://xxx.yyy.cnd.com/80232041AAA",
      "uid": "100013",
      "msg": "good"
    },
    "100014": {
      "username": "小三",
      "headurl": "http://xxx.yyy.cnd.com/11117041AAB",
      "uid": "100014",
      "msg": "bad"
    }
  }
}

可以看到，comment_ref_obj与praise_ref_obj两个字段，有非常重的关系型数据库痕迹，猜测，这个系统之前应该是放在了普通的关系型数据库上，或者设计者被关系型数据库的影响较深。而在MongoDB这种文档型数据库里，实际上是没有必要这样去设计，这种建模只造成了多于的数据冗余。

另外一个问题是，url占用了非常多的信息空间，这点在压测的时候会有体现，带宽会过早的成为瓶颈。同样username信息也是如此，此类信息相对来说是全局稳定的，基本不会做变化。并且这类信息跟随评论一起在整个APP中流转，也无法处理”用户名修改“的需求。

（3）建模 - 推荐的设计

{
  "_id": 41,
  "uid": "100000",
  "praise_uid_list": [
    "100010",
    "100011",
    "100012"
  ],
  "comment_msg_list": [
    {
      "100013": "good"
    },
    {
      "100014": "bad"
    }
  ]
}

对比可以看到，整个结构要小了几个数量级，并且可以发现url，usrname信息都全部不见了。那这样的需求应该如何去实现呢？

从业务抽象上来说，url，username这类信息实际上是非常稳定的，不会发生特别大的频繁变化。并且这两类信息实际上都应该是跟uid绑定的，每个uid含有指定的url，username，是最简单的key，value模型。所以，这类信息非常适合做一层缓存加速读取查询。

进一步的，每个人的好友基本上是有限的，头像，用户名等信息，甚至可以在APP层面进行缓存，也不会消耗移动端过多容量。但是反过来看，每次都到后段去读取，不但浪费了移动端的流量带宽，也加剧了电量消耗。

总结
MongoDB的文档模型固然强大，但绝对不是等同于关系型数据库的粗暴聚合，而是要考虑需求和业务，合理的设计。有些人在设计时，也会被文档模型误导，三七二十一一股脑的把信息塞到一个文档中，反而最后会带来各种使用问题。

2、建模案例分析2：多列数据结构

（1）需求

基于电影票售卖的不同渠道价格存储。某一个场次的电影，不同的销售渠道对应不同的价格。整理需求为：

数据字段：
场次信息；
播放影片信息；
渠道信息，与其对应的价格；
渠道数量最多几十个；

业务查询有两种：
根据电影场次，查询某一个渠道的价格；
根据渠道信息，查询对应的所有场次信息；

（2）建模 - 不好的模型设计

我们先来看其中一种典型的不好建模设计：

{
  "scheduleId": "0001",
  "movie": "你的名字",
  "price": {
    "gewala": 30,
    "maoyan": 50,
    "taopiao": 20
  }
}

数据表达上基本没有字段冗余，非常紧凑。再来看业务查询能力：

1、根据电影场次，查询某一个渠道的价格；
建立createIndex({scheduleId:1, movie:1})索引，虽然对price来说没有创建索引优化，但通过前面两个维度，已经可以定位到唯一的文档，查询效率上来说尚可；

2、根据渠道信息，查询对应的所有场次信息；
为了优化这种查询，需要对每个渠道分别建立索引，例如：
createIndex({“price.gewala”:1})
createIndex({“price.maoyan”:1})
createIndex({“price.taopiao”:1})
但渠道会经常变化，并且为了支持此类查询，肯能需要创建几十个索引，对维护来说简直就是噩梦；
此设计行不通，否决。

（3）建模 - 一般的设计

{
  "scheduleId": "0001",
  "movie": "你的名字",
  "channel": "gewala",
  "price": 30
}
 
{
  "scheduleId": "0001",
  "movie": "你的名字",
  "channel": "maoyan",
  "price": 50
}
 
{
  "scheduleId": "0001",
  "movie": "你的名字",
  "channel": "taopiao",
  "price": 20
}

与上面的方案相比，把整个存储对象结构进行了平铺展开，变成了一种表结构，传统的关系数据库多数采用这种类型的方案。信息表达上，把一个对象按照渠道维度拆成多个，其他的字段进行了冗余存储。如果业务需求再复杂点，造成的信息冗余膨胀非常巨大。膨胀后带来的副作用会有磁盘空间占用上升，内存命中率降低等缺点。对查询的处理呢：
1、根据电影场次，查询某一个渠道的价格；
建立createIndex({scheduleId:1, movie:1, channel:1})索引；
2、根据渠道信息，查询对应的所有场次信息；
建立createIndex({channel:1})索引；

更进一步的优化呢？

（4）建模 - 合理的设计

{
  "scheduleId": "0001",
  "movie": "你的名字",
  "provider": [
    {
      "channel": "gewala",
      "price": 30
    },
    {
      "channel": "maoyan",
      "price": 50
    },
    {
      "channel": "taopiao",
      "price": 20
    }
  ]
}

这里使用了在MongoDB建模中非常容易忽略的结构——”数组“。查询方面的处理，是可以建立Multikey Index索引
1、根据电影场次，查询某一个渠道的价格；
建立createIndex({scheduleId:1, movie:1, "provider.channel":1})索引；
2、根据渠道信息，查询对应的所有场次信息；
建立createIndex({"provider.channel":1})索引；

总结
这个案例并不复杂，需求也很清晰，但确实非常典型的MongoDB建模设计，开发人员在进行建模设计时经常也会受传统数据库的思路影响，沿用之前的思维惯性，而忽略了“文档”的价值。

3、建模案例分析3 - 物联网时序数据库建模

（1）需求

本案例非常适合与IoT场景的数据采集，结合MongoDB的Sharding能力，文档数据结构等优点，可以非常好的解决物联网使用场景。

需求：
案例背景是来自真实的业务，美国州际公路的流量统计。数据库需要提供的能力：
存储事件数据
提供分析查询能力

理想的平衡点：
内存使用
写入性能
读取分析性能

可以部署在常见的硬件平台上

（2）建模

每个事件用一个独立的文档存储

{
    segId: "I80_mile23",
    speed: 63,
    ts: ISODate("2013-10-16T22:07:38.000-0500")
}

非常“传统”的设计思路，每个事件都会写入一条同样的信息。多少的信息，就有多少条数据，数据量增长非常快。
数据采集操作全部是Insert语句；

每分钟的信息用一个独立的文档存储（存储平均值）

{
    segId: "I80_mile23",
    speed_num: 18,
    speed_sum: 1134,
    ts: ISODate("2013-10-16T22:07:00.000-0500")
}

对每分钟的平均速度计算非常友好（speed_sum/speed_num）；
数据采集操作基本是Update语句；
数据精度降为一分钟；

每分钟的信息用一个独立的文档存储（秒级记录）

{
    segId: "I80_mile23",
    speed: {0:63, 1:58, ... , 58:66, 59:64},
    ts: ISODate("2013-10-16T22:07:00.000-0500")
}

每秒的数据都存储在一个文档中；
数据采集操作基本是Update语句；

每小时的信息用一个独立的文档存储（秒级记录）

{
    segId: "I80_mile23",
    speed: {0:63, 1:58, ... , 3598:54, 3599:55},
    ts: ISODate("2013-10-16T22:00:00.000-0500")
}

相比上面的方案更进一步，从分钟到小时：
每小时的数据都存储在一个文档中；
数据采集操作基本是Update语句；
更新最后一个时间点（第3599秒），需要3599次迭代（虽然是在同一个文档中）

进一步优化下：

{
    segId: "I80_mile23",
    speed: {
        0:  {0:47, ..., 59:45},
        ...,
        59: {0:65, ... , 59:56}
    }
    ts: ISODate("2013-10-16T22:00:00.000-0500")
}

用了嵌套的手法把秒级别的数据存储在小时数据里；
数据采集操作基本是Update语句；
更新最后一个时间点（第3599秒），需要59+59次迭代；

嵌套结构正是MongoDB的魅力所在，稍动脑筋把一维拆成二维，大幅度减少了迭代次数；

每个事件用一个独立的文档存储VS每分钟的信息用一个独立的文档存储
从写入上看：后者每次修改的数据量要小很多，并且在WiredTiger引擎下，同一个文档的修改一定时间窗口下是可以在内存中合并的；
从读取上看：查询一个小时的数据，前者需要返回3600个文档，而后者只需要返回60个文档，效率上的差异显而易见；
从索引上看：同样，因为稳定数量的大幅度减少，索引尺寸也是同比例降低的，并且segId，ts这样的冗余数据也会减少冗余。容量的降低意味着内存命中率的上升，也就是性能的提高；

每小时的信息用一个独立的文档存储VS每分钟的信息用一个独立的文档存储
从写入上看：因为WiredTiger是每分钟进行一次刷盘，所以每小时一个文档的方案，在这一个小时内要被反复的load到PageCache中，再刷盘；所以，综合来看后者相对更合理；
从读取上看：前者的数据信息量较大，正常的业务请求未必需要这么多的数据，有很大一部分是浪费的；
从索引上看：前者的索引更小，内存利用率更高；

（3）总结

那么到底选择哪个方案更合理呢？从理论分析上可以看出，不管是小时存储，还是分钟存储，都是利用了MongoDB的信息聚合的能力。
每小时的信息用一个独立的文档存储：设计上较极端，优势劣势都很明显；
每分钟的信息用一个独立的文档存储：设计上较平衡，不会与业务期望偏差较大；
落实到现实的业务上，哪种是最优的？最好的解决方案就是根据自己的业务情况进行性能测试，以上的分析只是“理论”基础，给出“实践”的方向，但千万不可以此论断。

十四、MongoDB高级集群架构

1、两地三中心集群架构

双中心双活＋异地热备=两地三中心

2、全球多写集群架构