MongoDB架构基础概念

来源：本文大部分来源于加上自己理解官方文档
特点
- schema free，基于二进制json存储文档，即binary json。一个json就是一个文档（document），支持嵌套
- 直接加机器，分布式扩容
- 聚合统计，类似es的全文检索，地理位置坐标检索，
- 支持table join（use $lookup）,支持group by（use aggregation pipeline）
操作关键字
- 善用help
- createCollection
- show collection
- find like $in sort 1|-1 $gt
- updateMany filter
- createIndex alter table add index,索引的顺序可以定义
- 聚合aggregate pileline操作 ,
  - where:$match
  - group by $group
  - having $match
  - select $project
  - order by $sort
  - limit $limit
  - sum $sum
  - count $sum
  - 拆分 $unwind
  - $_id.likes
  - 多个json 配置
一些名词概念解释
- mongod：单机版数据库
- bin list 对应以下操作实体
```
- root@udev:/usr/bin# ls |grep mongo
  mongo
  mongod
  mongodump
  mongoexport
  mongofiles
  mongoimport
  mongoperf
  mongorestore
  mongos
  mongostat
  mongotop
  root@udev:/usr/bin# 
```
- Replica set：【Primary & Secondary &Leader】复制集的概念（主从关系），由于多个mongod 单机版组成的高可用单元。多个mongod是会组成一个复制集群，做到数据的备份同步。不会因为单点故障而丢失数据。注意
  - 至少是奇数个mongod结点（min：3，2N+1），其中一个可以是arbiter，只投票，不竞选。不存储数据。
    - arbitr：比如有3个节点，我只想把数据写入两个节点中，那么第三个就必须为arbiter，如果仅仅两个节点的话，否则不知道谁是primary
  - 主从基于op log复制同步，类比mysql binlog
  - 读的时候默认是读主节点，可根据业务配置。
  - 主宕机后，replica set中会重新选举。客户端就会写到新的primary上。
  - 如果RS中有一半机器上宕机的，将无法写入，只能读。
- Sharding：分布式集群，由于多个Replica set组成的扩展集群，可以增加多个Replica set，就可以扩展整个分布式集群
  -
  - 每一个ReplicaSet称为一个shard（分片），多个分片组成了Shards，即sharding结构
  - 客户端请求会通过mongos router（也可以是多个router，可以理解为网关代理），通过路由层可以把数据路由到具体的shard上，在这个过程中会存储许多的元信息 meta，简单理解元信息就是索引，存储的是哪个key存在了哪个shard上。同时元信息服务器【config servers】本身也是个replica set，本身也是主从复制的，提供高可用。
单机mongo架构：由上到下，由顶到底
- client 客户端发请求
- mongodb query language 查询解析层
- mongodb data model 抽象存储层
- storage engine 存储引擎层
  - wired tiger 目前主流默认
  - MMAPV1
  - In Memory
- 基于journaling log做宕机恢复（类比mysql的redo log）：写数据之前顺序追加先写磁盘log，然后到内存，然后将定期将内存写入到磁盘中去，如果在内存写入到磁盘过程中挂掉了，会通过journaling log将数据恢复。由此可见不是准实时写入，但是可以达到高吞吐。
关于collection（类似mysql中的table）分片
- 当查询某个collection数据的时候，router（mongos）会路由到具体的shard（Replication set）中，根据shard规则可能数据都在一个shard中，也可能存在多个。
- collection会自动分层多个chunk，如下图collection1的白色的框框，每个chunk会被自动负载均衡到不同的shard（Replication set），即实际保证的是chunk在不同shard的高可用（根据设置的副本的数量），另外类似于redis的tag方法，mongodb支持zones方法
- 关于collection的切分规则
  - 按范围（range）切分chunk，类比mysql的按照id分，比如前1w个id放入a1,2w内的放在a2..
    -
    - 问题：字段如果是时间等类似相近的分类字段，会存在写入热点问题，会存在chunk集中存在某个shard上。
    - 注意：key应该为建立索引Single Field，联合索引Compound Index也可以。chunk默认为64MB，超过64MB的被分割。
    - 所有的chunk收尾相连就可以构成整个collection表
  - 按hash 切分chunk
    - 问题：无法规避hash冲突问题，即无法彻底规避热点问题
    - 注意：key必须为hash索引（key不允许设置唯一索引属性，也达不到唯一Unique Indexes），这样才能得到int整型去模预先[配置的chunk]:(https://docs.mongodb.com/manu...（数据量大于默认chunk大小）或者聚合（优化）的时候影响写入性能。
  - 关于扇出读写:(fan out read|write)
    - 如果如果用字段x去做shard分片，用一个未被设定的key y去查询，这样y可能分散到各个shard里（因为是按照x分片），因为y会被分到不同chunk的shard里。就是broadcast。