一、定义
云数据库OceanBase是一款高性能、分布式的金融级关系型数据库,具备多地多活、异地容灾的高可用性,支持自由扩展以应对日益增长的业务需求
二、应用场景
1.金融级数据可靠性需求
OceanBase每一次提交事务,总是会在多个数据中心实时同步对应日志,并持久化。即使发生数据中心级别的灾难,也可以在其他的数据中心恢复每一笔已经完成的交易
2.让数据库适应飞速增长的业务
OceanBase是一款真正意义的分布式关系型数据
库,由一个个独立的通用计算机作为系统各个节点,数据根据容量大小、可用性自动分布在各个节点,当数据量不断增长时,OceanBase可以扩展节点的数量,满足业务需求
3.连续不间断的服务
分布式的OceanBase集群,当某个节点出现异常时,可以自动剔除此服务节点,该节点对应的数据有多个其他副本,对应的数据服务也由其他节点提供。甚至当某个数据中心出现异常,OceanBase可以在短时间内将服务节点切换到其他数据中心,可以保证业务持续可用
三、功能特性
1.平台先进
1)高效的存储引擎
a.单机引擎
写操作需要⾸先记录Redo⽇志并通过Paxos协议复制到多数派,接着再修改内存。为了提⾼系统的吞吐量,记录Redo⽇志时使⽤了Group Commit技术
写⽇志也需要实现成异步,即SQL线程提交写⽇志任务后不需要等待,就可以⽴即处理下⼀个任务,等到写⽇志完成后再异步应答客⼾端,从而做到最优提交
当内存中的修改增量超过某个阈值时,将触发转储或合并操作
转储操作将内存中的数据写⼊磁盘⽣成转储SSTable,而合并操作需要融合基线 SSTable、转储SSTable以及MemTable,⽣成新的基线SSTable
b.内存事务引擎
内存索引结构
OceanBase MemTable采⽤双索引结构:B+树索引以及哈希索引,B+树索引能够更好地⽀持范围查找;哈希索引是针对单⾏查找的⼀种优化
每次事务执⾏时,MemTable会⾃动维护B+树索引与哈希索引之间的⼀致性
多版本并发控制引擎
MemTable在内存中维护了历史版本的事务,每⼀⾏将历史事务针对该⾏的操作按照时间顺序组织成⾏操作链,新事务提交时会往⾏操作链尾部追加新的⾏操作。如果⾏操作链保存的历史事务过多,将影响读取性能,此时需要触发compaction操作,融合这些历史事务以⽣成新的⾏操作链。
Follower需要接受Leader以Paxos协议发送的Redo⽇志并回放到MemTable。MemTable⽀持多线程并发回放,且Follower回放的开销远小于Leader执⾏事务的开销,从而避免出现⾼峰期Follower赶不上Leader的情况
c.基线存储
基线存储数据结构称为SSTable(Sorted String Table,有序字符串表),这个名称最初来源于Google Bigtable系统
为了减少SSTable合并的开销,SSTable内部划分为2MB的宏块(Macro Block),每个宏块内部⼜划分为⼤小在4kb〜64kb的微块(Micro Block),微块内部的数据⾏按照主键有序存储
SSTable保存了宏块的索引结构(有序数组),而宏块内部⼜保存了微块的索引结构(有序数组)。微块类似于关系数据库中的⻚⾯,是读取时块缓存(Block Cache)的基本单位。
除了Block Cache,基线存储还会维护⾏缓存(Row Cache)、块索引缓存(Block IndexCache)以及布隆过滤器缓存(Bloom Filter Cache)。
2)多租户
将多个数据库实例管理和运维的成本和复杂性降低到和⼀个数据库实例相当
充分利⽤系统资源,使得同样的资源可以服务更多的业务。通过将波峰、波⾕期不同的业务系统部署到⼀个集群,以实现对系统资源最⼤限度的使⽤
租⼾之间的隔离性,在资源使⽤⽅⾯表现为租⼾独占其资源配额
ObServer 的⼯作线程执⾏SQL请求时,只要超过⼀个时间⽚(10ms左右),就会主动陷⼊调度器。
3)MySQL兼容
a.接口层面
OceanBase⼴泛使⽤的接口主要是JDBC。通过不断增强在前后台协议上和MySQL的兼容性,⽬前,使⽤MySQL的驱动即可⽆障碍地访问OceanBase
b.数据模式层面
完整地⽀持了数据库(database)、表(table)、视图(view)、⾃增列(autoincrement)等SQL标准的以及MySQL专有的数据模式,并且在数据库系统中实现了多租⼾(multi-tenant)。
c.语句/数据类型层面
⽬前的主流产品在SQL语句层⾯⼤多遵守ISO/IEC 9075 标准定义的⼀系列规范,最新的版本是SQL 2011
d.事务层面
系统⽀持的事务隔离级别以及并发控制⽅⾯的表现。OceanBase采⽤的是多版本的并发控制协议,读写不等待,⽀持Read Committed隔离级别
2.架构领先
1)可扩展性
OceanBase基于分布式系统实现,可以很方便地进行扩容和缩容,且能做到用户无感知
OceanBase所具备的集群内动态负载均衡、多机分布式查询、全局索引的能力更进 一步加强了其可扩展性
对于用户的分库表方案,OceanBase还提供了分区表和二级分区的功能,可以完全取代 MySQL
2)高可用性
同一数据保存在多台( >=3)服务器中的半数以上服务器上(例如3台中的2台),每一笔写事务也必须到达半数以上服务器才生效。因此,当少数服务器故障时不会有任何数据丢失,能够做到RPO等于零
OceanBase底层实现的Paxos高可用协议,在主库故障后,剩余的服务器会很快自动选举出新的主库, 实现自动切换,并继续提供服务
OceanBase的多副本特性和Paxos高可用协议将多样的异地多活、多城市多中心部署的高可用方案变为可能。通过典型的两地三中心 、三地五中心部署 ,OceanBase可以满足用户跨 IDC、跨城容灾的多种业务需求
3)管控服务(RootService)
a.定义
云数据库OceanBase的RootService和PartitionService⼀样,是OBServer进程的⼀个功能模块,OceanBase系统中有⼀个初始分区(__all_core_table),所有的其它分区都能由该分区逐级索引到。初始分区的Leader所在的OBServer⾃动提供RootService服务。
b.功能
服务器与Zone管理
RootService与所有OBServer维持租约,管理集群中的所有OBServer,处理OBServer上下线和Zone上下线
分区管理
RootService管理集群中分区数据分布,发起分区复制、迁移以及分裂、合并等操作
RootService执⾏分区管理操作时需要确保负载均衡
每日合并控制
OceanBase中的动态数据和静态数据在每天的指定时间(通常为应⽤的访问低峰期间)进⾏数据合并操作
每⽇合并由RootService整体协调,整个集群中的所有OBServer同时进⾏
OceanBase中实现了按zone错峰合并策略,即合并之前先将本zone全部分区的Leader切到其它zone,等到合并完成后再切回来
DDL执行
RootService负责执⾏DDL操作,包括创建表格、删除表格、增加列、删除列、修改列的属性以及增加索引等
系统自举
BootStrap是系统的初始化安装过程,主要⽤于创建系统内部表,并初始化系统配置
3.定制化产品组件
1)OceanBase云平台
是 OceanBase数据库集群的云管控平台,涵盖资源和容量管理、集群和实例生命周期管理、OpenAPI以及基于实时计算的性能监控和告警等功能模块,为用户提供一站式OceanBase数据库运维管控服务。用户及第三方也可以通过OCP提供的OpenAPI定制开发适合自身需求的管控工具和平台。
2)OBProxy
a.定义
应⽤可以通过ObProxy访问OceanBase服务。应⽤与ObProxy之间采⽤标准的MySQL协议
b.功能
反向代理功能
将请求转发到数据所在的 OBServer,并将OBServer 的响应结果转发给客⼾端;
防连接闪断,保证 OBServer 宕机或升级不影响客⼾端正常请求
兼容所有 MySQL 客⼾端
运维需求
ObProxy⽀持热升级
能够⾃动配置更新
⽀持安全性需求,如配置IP ⽩名单,防SQL注⼊,流量控制等
⽀持部署在独⽴的服务器或者直接部署在客⼾端
3)备份恢复工具
a.高可用
AgentServer备份恢复工具是没有状态的,可以单机部署,也可以多机部署
b.高性能
备份速度完全取决于备份介质的上传和下载速度,AgentServer⼯具本⾝不是性能瓶颈,在单台万兆机上进⾏备份任务,可以将⽹卡全部⽤满,达到700MB/s
c.灵活易用
备份恢复任务既⽀持集群级备份恢复,也⽀持租⼾级的备份恢复
d.多用途
除了为数据库数据做冷备外,还能⽀持很多其他的业务场景。例如,可以⽤作镜像库
e.多目标
⽀持多种存储介质,可以是OSS(阿⾥云对象存储服务 Object Storage Service,简称 OSS)或者是磁盘阵列
4)历史库平台
a.定义
历史库平台是⼀站式数据存储、归档的解决⽅案,为数据提供了更⻓⽣命周期管理能⼒
通过历史库管控平台,⽤⼾可以⽅便地配置迁移任务,指定规则将符合条件的⾮活跃数据从在线数据库(OceanBase/Oracle/MySQL)迁移到成本更低的历史OceanBase数据库集群中
b.产品特点
可视化管理:提供运维、管理、监控⻚⾯
低存储成本:低成本SATA盘机型&采⽤⾼压缩算法存储,成本降低⾄原来的10%
⽆需额外部署成本:历史库客⼾端通常部署在历史库集群中
⾼可⽤服务:任何节点宕机不影响整体服务
多维度限速:根据需求不同提供集群、数据表等多维度的限速,避免迁移任务对线上应⽤的影响
多样化迁移配置:根据需求不同可以提供表单迁移、关联表级联迁移功能
c.产品结构
在线数据库:⽤于存放应⽤经常需要访问的数据,通常会采⽤更为⾼规格配置的服务器,提供⾼性能的处理能⼒。⽬前已⽀持OceanBase,MySQL,Oracle作为数据源
历史数据库集群:⽤于存放应⽤产⽣的终态数据,根据应⽤需求不同,既可以作为数据归档存储的集群不对应⽤提供访问,也可以满⾜应⽤的访问需求。采⽤成本更低的SATA盘来搭建OceanBase数据库集群
历史库客⼾端:⽤于处理⽤⼾发起的迁移、校验、删除任务。内部实现了多维度的限速,根据需求不同可以灵活地提供集群限速和表限速功能,最⼤程度的避免了任务对在线库应⽤流量的影响。
历史库管控平台:⽤⼾对历史库进⾏各项操作的运维管理平台,提供权限管理、任务配置、任务监控等功能
四、容灾部署方案
1.容灾能力
服务器级无损容灾
机房级无损容灾
地区级无损容灾
2.部署方式
1)异地三机房
如果采⽤异地三机房部署,每次数据库事务提交都会增加⼀次异地同步延时
国内不同地区之间的机房延时(例如上海到深圳)在⼏⼗毫秒左右,而每⼀笔业务往往包含多个数据库事务。因此,可能需要对业务进⾏针对性改造,减少每⼀笔业务包含的数据库事务个数
2)同城三机房
通过Paxos协议的原理可以知道,为了⽀持机房级容灾,⾄少需要有三个机房;否则,当⼀个机房出现故障时,另外⼀个机房⽆法单独构成多数派,也就⽆法实现⽆损切换
三个机房中,⼀个机房为主库,另外两个机房为备库。APP和主库部署在同⼀个机房
对于同城三机房部署,每次事务提交都需要⾄少强同步到另外⼀个机房的某个备副本
3)两地三中心
假设深圳有两个机房,上海⼀个机房。对于每个分区,深圳机房分别部署两个副本,上海机房只部署⼀个副本,形成2 + 2 + 1部署。每个分区总共包含五个副本,正常情况下,只需要强同步深圳的三个副本即可
当上海机房出现故障时,仍然只需要强同步深圳的三个副本,系统⽆影响。当深圳机房 出现故障时,例如深圳2机房故障,此时,系统总共只有三个副本。如果不做处理,每个事务提交时都需要做⼀次深圳到上海的跨地区同步,⽹络延时不可接受。OceanBase的做法是利⽤Paxos协议做⼀次成员变更操作,将深圳2机房的副本从Paxos选举组中剔除,副本总数由五个变成三个。这
样,以后只需要同步三个副本中的两个即可,避免了跨地区同步
4)双机房热备
主机房和备机房分别独⽴部署了OceanBase集群,主机房的集群称为主集群,备机房的集群称为备集
双机房热备⽅案⽀持服务器级⽆损容灾,不⽀持机房级⽆损容灾。
3.部署成本
1)交叉部署
这三个机房的OceanBase机器资源都给⽤上,避免浪费
2)日志副本
即使选择交叉部署,每个副本仍然需要保存完整的SSTable和MemTable,占⽤存储空间和内存。
考虑到很多副本只是为了⾼可⽤,因此,可以只写重做⽇志(redo log),这些副本称为⽇志副本
五、产品优势
1.低成本
使用云数据库OceanBase,在同等情况下,要比使用MySQL等传统关系数据库节省大量的硬件成本
2.弹性可扩展
云数据库OceanBase是一款真正意义的分布式关系型数据库,由一个个独立的通用计算机作为系统各个节点,数据根据容灾、可用性自动分布在各个节点,OceanBase总是可以不断的扩展节点的数量,满足业务需求
3.持续可用
当某个节点出现异常时,云数据库OceanBase可以自动剔除此服务节点,对应的数据服务由其他节点提供。甚至当某个数据中心出现异常,云数据库OceanBase可以在短时间内将服务节点切换到其他数据中心,保证业务持续可用
4.零数据丢失
云数据库OceanBase每一次事务提交,对应日志总是会在多个(三个)数据节点实时同步,并持久化
5.云平台
用户所有的业务接⼊都可以通过OceanBase云平台(OCP)使⽤⼀键上云组件将原有的MySQL业务⼀键迁移到OceanBase,在云平台上动态增加或减少租⼾的资源,执⾏备份恢复。OceanBase 与OCP⼀起提供DBaaS服务
OCP平台还提供诊断监控、运⾏报表、智能告警以及资源调度等服务。即使⽤⼾写的SQL语句不太合理,OCP平台也能够⾃动发现并且提供优化建议
DBaaS服务层还提供了丰富的API,可以根据⾃⾝的业务流程进⾏定制
六、产品架构
1.应用层
1)多租户支持
OceanBase设计为一个集群服务多个业务,即DBaaS的模式。每个业务会创建一个或者多个租户,租户之间互相隔离,可以设置每个租户允许使用的Session数、CPU、内存或者磁盘IOPS
2)SQL引擎
OceanBase基于底层的分布式系统实现一个SQL引擎,包括SQL解析器、SQL重写器、基于成本的SQL优化器和SQL执行器。并基于分布式系统的特性,进行并行优化
针对分布式事务,OceanBase通过研究经典的两阶段提交实现,做了相应的优化,一个最大的不同是多了一个 CLEAR 阶段
2.代理层
1)智能访问代理
ObProxy 是一个高性能且易于运维的反向代理服务器,用户的请求会首先发给系统中的智能访问代理,它会根据用户请求的数据解析SQL,识别SQL操作哪个分区,然后把该SQL转发到它所操作的分区所在的服务器。在数据转发过程中,ObProxy 作为一个数据管道对客户端透明。
3.数据服务层
1)集群角色
子集群(zone ),包含多台物理机器(OBServer)
每个zone会有一台OBServer,包含总控服务(RootService),提供集群管理、数据分布管理、合并控制、系统自举等功能
所有OBServer都可以提供分区服务(PartitionService),该服务管理多个数据分区
2)数据分布
OceanBase中存储的数据分布在一个 Zone的多个数据节点上,其他Zone存放了数据多个副本。
3)存储引擎
OceanBase设计为准内存数据库,将数据划分为基线数据和修改增量。基线数据放到固态盘,而修改增量在内存中,通过这种方式,使得热点数据和事务操作都发生在内存中,从而获得接近内存数据库的事务处理性能
4)高可用
OceanBase最底层的技术就是通过Paxos协议实现的分布式选举和多库多活。Paxos协议的好处在于节点是多活的,当服务节点出现故障时,其它正常的节点可以在几秒内替代这个故障的节点,很快恢复服务,而且完全不丢数据






