摘要：IDC 认为，目前阶段来看，企业亟待解决的是数字化能力晋升，包含：与业务的深刻联合能力；数据处理和开掘能力；以及 IT 技术经营和治理能力。特地是数据处理和开掘能力，因为数字化转型推动企业从以流程为外围向以数据为外围转型，对海量、异构、多类型的数据处理和开掘能力是开释数据价值的前提，对数据全生命周期的管控治理是开释数据价值的保障。能够看出，数据库作为数据的承载，企业的要求不再只是简略的存储性能了。
GaussDB(for Mongo)是华为云自主研发兼容 MongoDB4.0 接口的文档数据库。基于共享存储的存算拆散架构，对于传统 MongoDB 社区版有如下劣势：
- 秒级增加 Secondary 节点(相比社区版 Mongo 小时级增加 Secondary 节点)
- 基于 WAL 复制, Secondary 节点无写 IO, 从根本上解决社区版 Seconary 节点 Oplog 脱节问题
- Primary/Seconary 无任何 IO 交互,Secondary 节点个数实践无下限, 反对百万 OPS 的读事务能力
- LSMTree Compaction 计算 /IO 卸载到 Compaction 对立调度池, 集中管理, 不节约用户读写 IO
- 基于共享存储，Chunk 决裂 / 迁徙动作不引起实在 IO，只更新路由元数据，秒级决裂 / 平衡
1.GaussDB(for Mongo)技术架构
1）容忍更多 Shard 宕机
与社区版 MongoDB 的 `Share-Nothing` 模式不同的是，GaussDB(for Mongo)采纳 `Share-Storage` 架构，计算存储拆散。集群模式下，N 个 Shard 节点，能够容忍 N - 1 个 Shard 宕机。
某个 Shard 节点宕机后，其负责的数据因为存在于共享的存储池中，因而不须要物理拷贝数据，只须要批改元数据路由信息，即可被其余分片节点接管。
2）更快的决裂与平衡能力
此外，因为 Chunk 数据在存储池中，Chunk 的决裂与平衡不波及到数据拷贝，能够做到分钟级决裂与扩容，决裂与扩容对用户的影响也远比社区版 MongoDB 小。
3）百万级读 OPS 能力
GaussDB(for Mongo)正本集模式下，Primary/Secondary 节点之间共享同一份数据库文件。Secondary 节点只复制 Primary 节点的 WriteAheadLog 以及 LSMTree 的构造变更信息，并利用到内存中。Secondary 节点没有 LSMTree 的 Compaction 和 Flush 工作，因而对用户的读业务影响很小。
此外，因为 `Share-Storage` 的架构劣势，增加 Secondary 节点并不需要拷贝数据，增加 Secondary 节点的动作能够秒级实现。而 Primary/Secondary 之间只传递元数据变更，不传递 WriteAheadLog，因而 Secondary 节点的个数即便变多，也不影响 Primary 节点的写性能。Secondary 节点能够程度扩大，撑持百万级的读 OPS。
4）主节点 IO 卸载
LSMTree 的写压力来源于三局部：
- 用户的业务写入导致的 Memtable Flush
- 后盾 SST 文件 Compaction
- WAL 的继续写入
依据线上业务的理论测算，三者的 IO 资源耗费占比为：1:10:1。后盾的 SST 文件 Compaction 占了绝大部分 IO 带宽，通过将 Compaction 工作集中化治理，从计算池卸载到存储池，进一步缩小了用户计算节点的 CPU 和 IO 资源耗费。
5）GaussDB(for Mongo) 只读节点设计
- 传统社区版 MongoDB 正本集基于 Oplog 做数据复制，只读节点须要镜像主节点的所有写 IO 操作。GaussDB(for Mongo) 的只读节点和主节点共享同一份底层数据库文件(LSMTree 的 SST 文件)，只读节点并不本人生成 SST 文件。
- 随着业务数据的写入，Compaction 的一直执行，LSMTree 的以后版本 (蕴含哪些 SST 文件) 不断更新，LSMTree 的元数据更新 (增删 SST 文件的记录) 被同步到只读节点执行。
- RocksDB 中，数据的变更被长久化到 WAL 里，元数据的变更 (增删文件的操作, 叫做 VersionEdit) 被长久化到 Mainifest 里。RocksDB 的数据和元数据是离开的，WAL 流和 VersionEdit 流是并行的，没有严格的先后顺序。为了保障只读节点和主节点完全一致的事件回放程序，WAL 和 VersionEdit 流必须要合并成一个流，在双流合并后，通过 LSN 就能够为每个事件 (WAL 的写操作 /VersionEdit) 定序。
- 基于 WAL+VersionEdit 复制，而不基于 Oplog 复制
- 共享文件 (sst/wal) 的生命周期治理由主节点负责 sst 文件和 wal 的文件的生命周期由主节点负责。RocksDB 中，SST 文件通过层级的援用计数来维持不被删除。如下图，RocksDB 的每个游标会维持 SuperVersion，如下图中的 S0，S1，S2。每个 SuperVersion 会援用一个 Version，一个 Version 代表 LSMTree 在一直变形 (通过增删 SST 文件变形) 的过程中，某个工夫点的形态，最新的 Version 就代表 LSMTree 以后的形态。
- 在 GaussDB(for Mongo)中，主节点会记录所有只读节点在应用的 Version，并为这些 Version 减少援用计数从而维持 SST 文件的生命周期。对于 WAL，主节点会记录所有只读节点中最老的 LSN(`oldestLsn`)，最老的 LSN 来自于复制最慢的只读节点。并删除比 oldestLsn 还旧的 WAL 文件。
- 元数据变更告诉，无论是 oldestLsn 还是只读节点的以后在用的沉闷的 Version，都须要及时推动，这些元数据的变更是通过主从节点的定期心跳上报到主节点上的。主节点利用心跳数据对垃圾版本与 WAL 做清理。如下图所示，在经验一次心跳后，主节点发现 Secondary0 的 Version0 和 Secondary1 的 Version0 不再应用。删除这两个 Version 后，SST0 的援用计数为 0，示意 SST0 能够被删除。OldestLsn 也从 100 推动到了 250，能够清理掉 250 之前的 WAL。
- 只读节点的 memtable 的开释：主节点的 Memtable 不会实时 Flush 为 SST 文件。如果只读节点不解决主节点的 Memtable 的话，只读节点的数据就不是实时的，且存在数据一致性问题。只读节点通过回放 WAL 到内存的 Memtable 中，来笼罩 SST 文件与主节点的 Memtable 的 Gap。上文介绍了只读节点是不往共享存储写入数据的，所以只读节点上的 Memtable 最初的终局肯定是被抛弃掉。但什么时候抛弃这个 Memtable 就是一个问题。过早的抛弃，会造成 SST 文件与 Memtable 之间的数据不间断，存在 Gap，过晚的抛弃会造成内存的节约。只有当只读节点辨认到 SST 的数据曾经齐全可能 Cover 某个 Memtable 时，这个 Memtable 才能够被抛弃。
- GaussDB(for Mongo)的只读节点在每次利用 VersionEdit 后，查看所有 SST 中的最大的 LSN 与 Memtable 的最小的 LSN 的关系，来决定是否要抛弃某个 Memtable。
- 内存元数据的反向更新：传统的复制，数据流从 Oplog 来，走一遍残缺的数据库 Server 层 CRUD 接口，再落到引擎层。这种逻辑和主节点上业务的写入逻辑是统一的，因而 Server 层的一些内存元数据结构，在这个过程中就自然而然的失去更新了。然而当采纳基于 WAL 的复制后，整个 WritePath 并不通过只读节点的 Server 层。因而 Server 层的内存元数据更新，就是一个很大的挑战。在这里，只读节点对每一条 WAL 做剖析，如果 WAL 的内容会影响 Mongo 内存元数据，就会 reload 对应的元数据模块。
GaussDB(for Mongo) 基于 Share-Storage 架构，实现秒级 Chunk 决裂与平衡，对业务影响更小，程度扩大速度更快，能容忍更多节点宕机。只读节点性能，实现了一份数据多计算节点共用的性能。极大的晋升了存储的利用效率，进步了计算节点的读取数据能力。为了让正本节点具备继续的读扩大能力，整个只读计划采纳元数据的同步模式，在不升高主节点负载的状况下，极大的晋升了整个零碎的读数据的解决能力。为 3 节点，5 节点，乃至于 15 节点以上的正本集的工作提供了可能。
数据显示，寰球数据量将从 2018 年 32.5ZB 快速增长到 2025 年的 180ZB。异构、智能和交融的数据库将成为金融、政府、电信等各行业数据基础设施的要害支柱。华为 GaussDB(for Mongo)，能打消企业各业务零碎数据孤岛，构建面向行业场景的数据建模、剖析和价值开掘能力，最终帮忙企业实现数据价值开掘和共享。
点击关注，第一工夫理解华为云陈腐技术~