关于go:MongoDB-这一篇就够了

MongoDB

MongoDB 是一个基于分布式文件存储的数据库，MongoDB 是一个介于关系数据库和非关系数据库 (nosql) 之间的数据库产品。

MongoDB 与 MySQL 术语比照

• database 数据库，与 SQL 的数据库 (database) 概念雷同，一个数据库蕴含多个汇合(表)

• collection 汇合，相当于 SQL 中的表 (table)，一个汇合能够寄存多个文档(行)。
  不同之处就在于汇合的构造 (schema) 是动静的，不须要事后申明一个严格的表构造。更重要的是，默认状况下 MongoDB 并不会对写入的数据做任何 schema 的校验；

  • document 文档，相当于 SQL 中的行 (row)，一个文档由多个字段(列) 组成，并采纳 bson(json)格局示意；
  • field 字段，相当于 SQL 中的列(column)，相比一般 column 的差异在于 field 的类型能够更加灵便，比方反对嵌套的文档、数组；

MongoDB vs. 关系型数据库

实用场景

• 利用不须要事务及简单 join 反对
• 新利用，需要会变，数据模型无奈确定，想疾速迭代开发
• 利用须要 2000-3000 以上的读写 QPS（更高也能够）
• 利用须要 TB 甚至 PB 级别数据存储
• 利用倒退迅速，须要能疾速程度扩大
• 利用要求存储的数据不失落 利用须要 99.999% 高可用
• 利用须要大量的地理位置查问、文本查问

存储引擎和索引

存储引擎

WiredTiger 存储引擎之一：根底数据结构剖析

索引类型

MongoDB 索引详解（一）

事物

始终以来，” 不反对事务 ” 是 MongoDB 始终被诟病的问题，当然也能够说这是 NoSQL 数据库的一种衡量 (放弃事务，谋求高性能、高可扩大)，但本质上，MongoDB 很早就有事务的概念，然而这个事务只能是针对单文档的，即单个文档的操作是有原子性保障的。
在 4.0 版本之后，MongoDB 开始反对多文档的事务：

• 4.0 版本反对正本集范畴的多文档事务；
• 4.2 版本反对跨分片的多文档事务(基于两阶段提交)；

MongoDB 尽管曾经在 4.2 开始全面反对了多文档事务，但并不代表大家应该毫无节制地应用它。相同，对事务的应用准则应该是：能不必尽量不必。通过正当地设计文档模型，能够躲避绝大部分应用事务的必要性

• 为什么？事务 = 锁，节点协调，额定开销，性能影响

MongoDB WiredTiger 存储引擎反对 read-uncommitted、read-committed 和 snapshot3 种事务隔离级别，MongoDB 启动时默认抉择 snapshot 隔离。

事务开发：写操作事务

writeConcern：决定一个写操作落到多少个节点上才算胜利。writeConcern 的取值包含：

• 0：发动写操作，不关怀是否胜利；
• 1~ 集群最大数据节点数：写操作须要被复制到指定节点数才算胜利；
• majority：写操作须要被复制到大多数节点上才算胜利。
• all：写操作须要被复制到全副节点上才算胜利。

事务开发：读操作事务

在读取数据的过程中咱们须要关注以下两个问题：

• 从哪里读？
• 什么样的数据能够读？

第一个问题是是由 readPreference：决定应用哪一个节点来满足正在发动的读申请

• primary: 只抉择主节点；
• primaryPreferred：优先选择主节点，如果不可用则抉择从节点；
• secondary：只抉择从节点；
• secondaryPreferred：优先选择从节点，如果从节点不可用则抉择主节点；
• nearest：抉择最近的节点；

第二个问题则是由 readConcern：决定这个节点上的数据哪些是可读的，相似于关系数据库的隔离级别

• available：读取所有可用的数据;
• local：读取所有可用且属于以后分片的数据;
• majority：读取在大多数节点上提交实现的数据;
• linearizable：可线性化读取文档;
• snapshot：读取最近快照中的数据;

事务开发：多文档事务

MongoDB ACID 事务反对

高可用

复制集机制及原理

MongoDB 的 复制集相似于 MySQL 的主从架构，然而又比 MySQL 的主从架构要弱小的多。
复制集的作用：

• 数据写入时将数据迅速复制到另一个独立节点上
• 在承受写入的节点产生故障时主动选举出一个新的代替节点

在实现高可用的同时，复制集实现了其余几个附加作用：

• 数据散发：将数据从一个区域复制到另一个区域，缩小另一个区域的读提早
• 读写拆散：不同类型的压力别离在不同的节点上执行
• 异地容灾：在数据中心故障时候疾速切换到异地

复制集架构

一个典型的复制集由 3 个以上具备投票权的节点组成，包含：
一个主节点（PRIMARY）：承受写入操作和选举时投票
两个（或多个）从节点（SECONDARY）：复制主节点上的新数据和选举时投票
不举荐应用 Arbiter（投票节点）

数据是如何复制的

• 当一个批改操作，无论是插入、更新或删除，达到主节点时，它对数据的操作将被记录下来（通过一些必要的转换），这些记录称为 oplog。

• 从节点通过在主节点上关上一个 tailable 游标一直获取新进入主节点的 oplog，并在本人的数据上回放，以此放弃跟主节点的数据统一。

  分片集群架构

• 路由节点 mongos：提供集群入口、转发利用端申请、抉择适合数据节点进行读写、合并多个数据节点的返回
• 配置节点 Config：提供集群元数据存储、分片数据分布的映射
• 数据节点 mongod：负责存储数据库数据，每个 Shard 数据分片默认三节点正本集（三节点正本集由 Primary 节点 + 1 个 Secondary 节点 + 1 个 Arbiter 节点形成）、以复制集为单位横向扩大

分片集群特点：利用全透明，无非凡解决、数据主动平衡、动静扩容，毋庸下线

数据分片策略

Chunks 块：MongoDB 将分片数据拆分成块。每个分块都有一个基于分片键的上上限范畴

基于范畴：范畴分片能很好的满足『范畴查问』的需要，比方想查问 x 的值在 [-75, 25] 之间的所有文档，这时 mongos 间接能将申请路由到 Chunk2，就能查问出所有符合条件的文档。

• 长处：片键范畴查问性能好、优化读
• 毛病：数据分布可能不平均、容易有热点

基于 Hash：Hash 分片是依据用户的 shard key 计算 hash 值（64bit 整型），依据 hash 值依照『范畴分片』的策略将文档散布到不同的 chunk

• 长处：数据分布平均，写优化
• 毛病：范畴查问效率低

基于 zone / tag：基于地区去划分

文档参考

• geektime-mongodb-course