摘要：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)，能打消企业各业务零碎数据孤岛，构建面向行业场景的数据建模、剖析和价值开掘能力，最终帮忙企业实现数据价值开掘和共享。

点击关注，第一工夫理解华为云陈腐技术~