MogDBCube数据库一体机架构解析与创新实践
数据库的架构选型
主CPURAM
Disk
备CPURAM
Disk
Shard1CPURAM
Disk
Shard2CPURAM
Disk
RWCPU
RW/ROCPU
GlobalMemoryPool
ShareStoragePool
基于数据库日志复制保证高可用，典型场景RTO30s
单机能力满足大部分业务性能需求
经典成熟方案，适用于稳态业务场景
Oracle,DB2,MySQL,MogDB
数据按照Shard划分，节点资源独立，读写负载水平扩展，满足大规模业务场景性能需求
典型场景RTO30s，并且仅部分业务受损
损失部分单机数据库的能力
支持快速扩容，适用于敏态业务场景
TiDB,CockroachDB
通过多节点集群方式，实现极致的高可用能力，典型场景RTO10s
采用共享存储方式，提供多写多读或一写多读能力，一定的扩展能力
完全继承单机数据库的能力
专业存储处理磁盘故障及亚健康问题
适用于对高可用敏感的核心业务场景
OracleRAC,MogDBCube
Share Storage 架构 更适合国产数据库平替
RTO时间更短
数据库主备节点间不用复制日志，故障切换时回放日志量更少
更专业的存储管理系统，相比数据库自己管理服务器本地盘，提供更高的可靠性
磁盘亚健康管理、故障点灯、磨损均衡、故障盘重构、盘FW升级
单盘故障、IOHang等错误对数据库几乎无感，避免主备切换
集中式架构能满足90%以上的业务性能需求
大行1万~3万TPS，股份制银行2000~5000TPS，城商行1000TPS左右
针对不同负载优化
DataShippingfor
OLTP，减少网络开销以及分布式事务2PC开销，时延更低；
Functionshipping
forOLAP，和sharenothing架构类似
更低的业务改造成本
ShareNothing架构很难完整继承单机能力，如外键、存储过程等
业务需要改造，设置合理的分片键
更高的性能密度
更少的节点数量，更少的License费用，更少的机柜空间，更节能
计算和存储独立扩容
存储扩容不会绑定计算也扩容（一主多从、软件License费用）
数据库运维
IOE时代，90%问题运维人员可以自己解决，10%问题求助原厂，分布式数据库，90%问题需要原厂分析；
存储运维
本地盘故障，由数据库厂家负责，还是OS厂家负责，还是盘厂家负责？
盘故障自动隔离，跳过故障盘继续使用，长时间免运维
MogDB Cube 架构：两层池化 + 数存融合
共享存储
日志卷
数据卷
存储网络
Client
公共网络
VIP
节点1
节点N
VIP
私有
网络
用户态文件系统
…
主机多路径
LUN
主机多路径
LUN
投票卷
仲裁卷
日志卷
备份卷
CMS
集群管理
用户态文件系统
CMS
集群管理
MogDBInstance
SQLEngine
CacheFabric(page/lock)
Segment
MogDBInstance
SQLEngine
CacheFabric(page/lock)
Segment
MogDBCubeManager
内存池化+存储池化
数据库主备节点无日志GAP，
50万TPMC下RTO10s
数据库节点共享一份数据，降低
50%存储成本
备机实时强一致读，读写分离提供读扩展能力
多节点并行查询，TPC-H性能提升150%
计算/存储资源独立按需扩容，分钟级扩容备节点
/
数存融合
自研数据库专用存储zStorage，
单节点50万IOPS@0.8ms
专业磁盘故障及亚健康管理，磁盘故障重构性能15min/TB
IO全局打散，聚合更大IO带宽，相比本地盘提升50%
8KB原子写，去除双写代价
高优先级处理日志IO
IOFence，避免双主问题
可写快照，快速克隆数据库
MogDB Cube 架构：内存池化
日志卷
数据卷
日志卷
备份卷
共享存储
投票卷 仲裁卷
备节点(只读)
SQL引擎
用户态文件系统
CacheFabric
事务管理
PageRequester
主节点(读写)
SQL引擎
用户态文件系统
CacheFabric
事务管理
PageMaster
备节点(只读)
SQL引擎
用户态文件系统
CacheFabric
事务管理
PageOwner
面或锁
30S
10S
故障切换
RTO时间
备机实时一致性读
①请求页
将请求转发
②给页面持