乐趣区

关于存储技术:一文读懂GaussDBfor-Mongo的计算存储分离架构

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

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

退出移动版