大数据开发之路-mongodb

2022-05-19 阅读数：168次

mongodb-最接近“mysql”的nosql数据库
关键特性
数据模型
关键技术
应用场景
参考资料

导引

大数据开发之路-概述

flume-高度定制化的日志采集传输系统

sqoop-rdbms和hadoop之间的数据同步工具

datax-多种异构数据源间的高效数据同步工具

canal-基于MySQL binlog的增量同步工具

hdfs-大数据生态系统的存储基石

hbase-基于hdfs的支持实时随机读写的列式数据库

kudu-介于hdfs和hbase之间的“锋卫摇摆人”

kafka-出色的分布式高性能发布/订阅消息队列系统

hive-基于Hadoop的数据仓库工具

spark streaming-分布式流式计算引擎

离线任务优化-数据开发的看家本领

实时任务优化-数据开发的看家本领

presto-基于MPP架构的分布式SQL交互式查询引擎

clickhouse-OLAP分析数据库的异域猛禽

doris-OLAP分析数据库的国产之光

kylin-MOLAP引擎的“扛把子”

mongodb-最接近“mysql”的nosql数据库

yarn-大数据生态体系的资源管理系统

ranger-大数据生态体系的统一权限控制系统

cap原则-分布式系统设计的指导思想

行存和列存-大数据存取的选择

存算分离-让大数据获得真正的弹性

离线数仓-大数据系统的重量级应用

实时数仓-实时性需求催生的数仓架构

流批一体-实时数仓架构的百家争鸣

olap-基于数仓的多维实时分析系统

数据湖-数据宇宙的未来架构（科普篇）

mongodb-最接近“mysql”的nosql数据库

MongoDB是一个开源、高性能、无模式的文档数据库，当初的设计就是用于简化开发和方便扩展，是NoSQL数据库产品的一种，是最像关系型数据库（MySQL）的非关系型数据库。
它支持的数据结构非常松散，是一种类似于JSON的格式叫BSON，所以它既可以存比较复杂的数据类型，又相当的灵活。

关键特性

面向文档存储，易于存储对象类型的数据
- 数据结构符合大部分程序语言，文件存储格式为BSON(一种JSON的扩展)
- 可在文档内嵌入子文档（相当于传统数据库的嵌套表）
- 动态增减文档或修改文档格式，模式自由
高性能
- 支持基于内存查询，减少磁盘 IO 交互
- 支持使用嵌入数据，减少系统I/O负担，支持子文档查询
- 使用高效的二进制数据存储，包括大型对象
多种查询类型支持，且支持数据聚合查询、文本检索、地址位置查询，支持复杂的 SQL 查询
高可用、水平扩展，支持副本集与分片
多种存储引擎：WiredTiger , In-Memory

数据模型

和关系型数据库mysql很相似。

关键技术

WiredTiger存储引擎

WT的数据结构

WT的Cache采用Btree的方式组织，每个Btree节点为一个page。root page是btree的根节点，internal page是btree的中间索引节点，leaf page是存储数据的叶子节点；btree的数据以page为单位按需从磁盘加载或写入磁盘。
为什么MongoDB使用了B树而不是B+树

B+树只在叶子节点中储存数据，叶子节点之间有链表相连方便遍历和范围查询。B树在单个查询时性能优于B+树，在范围查询时需要遍历树，效率不如B+树直接遍历链表。
MySQL 作为关系型数据库，需要处理大量的范围查询和遍历，选用了B+树；而MongoDB 作为文档的数据库，更看重面向文档的简单查询，所以选择了查询单个文档性能较好的B树。
WT的持久化
- 预写日志（WAL）： WT使用预写日志的机制，在数据更新时，先将数据更新写入到日志文件。日志的写入频率可以根据业务要求的可靠性等级配置，最严格的情况可以配置为集群中大部分节点都落盘后才将结果返回给客户端。
- 检查点（checkpoint）：在checkpoint操作开始时，WT提供指定时间点的数据库快照，并将快照中的所有数据以一致性方式写入到数据文件中。一旦checkpoint创建成功，WT保证数据文件和内存数据是一致的。当宕机重新启动时WT会先将数据恢复到最近的一次checkpoint的点，然后重放后续的操作日志来恢复数据。

事务支持

传统的观念认为NoSQL不支持或者只有部分支持事务，在MongoDB 4.0之前对事务的支持有限，但在MongoDB 4.0 引入了事务功能，支持多文档ACID特性。
事务实现原理：snapshot(事务快照) 、MVCC (多版本并发控制) 和redo log来实现事务。

MongoDB集群

副本集
- Primary 主节点，一个副本集有且仅有一台服务器处于Primary状态，只有主节点才对外提供写服务。如果主节点挂掉，副本集将投票选出一个备节点成为新的主节点。
- Secondary 备用节点，副本集允许有多台Secondary，每个备用节点的数据与主节点的数据是完全同步的。备节点可以提供读服务。
- Arbiter 仲裁节点，该类节点可以不用单独存在，如果配置为仲裁节点，就主要负责在复本集中监控其他节点状态，投票选出主节点。如果没有仲裁节点，那么投票工作将由所有节点共同进行。
官方推荐MongoDB副本节点在3~11个之间，奇数个副本节点。限制副本节点的数目是为了减少复制的成本，限制为奇数则是为了减少出现脑裂。
副本集的选举
跟很多NoSQL数据库一样，MongoDB副本集采用的是Bully算法进行主节点选举。
在以下场景副本集会开始进行选举：
- 初始化副本集时；
- 备份节点无法和主节点通讯时(可能主节点宕机或网络原因)；
- Primary 手动降级。
选举的大致原理是获取每个服务器节点的最后操作时间戳（oplog），选择最后操作时间戳最新(保证数据最新)的服务器节点作为主节点。
分片
当MongoDB存储海量的数据时，一台机器不足以提供可接受的读写吞吐量。这时，我们就可以通过在多台机器上分割数据，使得数据库系统能存储和处理更多的数据。

分片集群由Shard、Mongos和Config server 3个组件构成。
- mongos：数据库集群请求的入口，起到路由作用，它负责把对应的数据请求转发到对应的shard服务器上。生产环境中需要多个mongos。
- config server：保存集群和分片的元数据，mongos启动时会加载配置服务器上的配置信息，以后如果配置服务器信息变化会通知到所有的mongos更新自己的状态。生产环境需要多个配置服务器并定期备份。
- shard server：实际存储数据的分片。生产环境为了保证高可用，每个Shard都要求是副本集。