摘要:我们将推出「产品模块原理系列」内容,其中包含了OceanBase最核心的SQL引擎、存储引擎、内存管理、分布式并行计算引擎等重要的技术原理,很多内容还是第一次对外发布哦~第一期我们先简要为大家介绍OceanBase数据库产品大家族的成员们,更多内容敬请期待!
前言
本文通过文字和图表等形式简要介绍了OceanBase特性、产品家族及相关概念,旨在指导读者对OceanBase数据库产品和相关组件功能有一个大致的了解,帮助读者在后续学习过程中有一个清晰明确的架构方向,以达到快速深入掌握OceanBase使用技巧的目的。
本文主要分为三个部分:OceanBase简介,OceanBase产品家族,OceanBase家族各产品概述。
由于本文未深入涉及相关产品功能的原理使用操作细节,建议在阅读完本文后持续关注OceanBase公众号该系列的相关技术文章,并执行具体实验加深对OceanBase相关知识点的理解。
OceanBase简介
OceanBase是由阿里巴巴和蚂蚁金服自主研发的金融级分布式关系数据库,具有数据强一致、高可用、高性能、在线扩展、高度兼容 SQL 标准和主流关系数据库、低成本等特点。
OceanBase在阿里经济体内部,目前除支持蚂蚁金服、网商银行、PayTM等核心交易系统外,还同时支撑了阿里集团数条大业务线和上百条中小业务,如淘宝收藏夹,阿里妈妈广告等。
OceanBase在外部输出方面,目前服务的外部客户已达数十个,主要集中在金融行业,支撑包括互联网核心在内的各类关键业务,如南京银行、西安银行、常熟银行、人保健康险等。同时OceanBase作为AntStack的核心服务为蚂蚁科技输出提供了优秀的标准数据库能力,相关产品包括Mpaas、Bpaas、IFAA、DAAS等。
OceanBase提供了如下诸多特性:
1)强一致
数据多副本通过 Paxos 协议同步事务日志,多数派成功事务才能提交。缺省情况下读、写操作在主副本进行,保证强一致
- 分布式事务
- ACID 强一致
- 多重数据校验
2)高可用
数据采用多副本存储,少数副本故障不影响数据可用性。通过“三地五中心”部署实现城市级故障自动无损容灾
- 基于 Paxos 协议,少数派故障,数据不丢,服务不停
- RPO=0;RTO<30s
3)高可扩展
集群节点全对等,每个节点都具备计算和存储能力,无单点瓶颈。可线性、在线扩展和收缩
- 水平扩展,在线扩容缩容,服务不停
- 单集群规模超 100 台,数据量超 2PB
- 单表最多记录数超 3200 亿条
4)高性能
存储采用读写分离架构,计算引擎全链路性能优化,准内存数据库性能
- 准内存数据库性能
- 4200 万次/秒处理峰值的记录
5)高度兼容
兼容常用 MySQL 功能及 MySQL 前后台协议,业务零修改或少量修改即可从 MySQL 迁移至 OceanBase
- 高度兼容 MySQL 5.6 版本功能
- 基于 MySQL 业务零修改/部分修改迁移
- 逐步兼容 Oracle
6)低成本
使用 PC 服务器和低端 SSD,高存储压缩率降低存储成本,高性能降低计算成本,多租户混部充分利用系统资源
- 基于普通 PC 服务器,高存储压缩率
- 结合整体业务改造可使IT成本降低为传统方案的 1/10 - 1/5
OceanBase与其他数据库类型特性区别见下表:
图1:OceanBase与其他数据库类型特性区别
OceanBase产品家族
OceanBase提供全系列应用开发运维产品线,主要包括以下五个:
产品名称 |
产品描述 |
OceanBase数据库(OceanBase DataBase Server) |
分布式关系型数据库 |
OceanBase云平台(OceanBase Cloud Platform) |
云平台,提供可视化监控、运维、报警等功能 |
OceanBase开发者中心(OceanBase Developer Center) |
开发者中心,提供数据库日常操作、用户操作权限管控、OceanBase小工具集等功能 |
OceanBase访问代理(OceanBase Proxy) |
客户端轻量级访问代理 |
OceanBase java驱动(OceanBase Connector Java) |
兼容MySQL的OceanBase JDBC Driver |
OceanBase 备份恢复工具包(OceanBase Backup/Restore Toolkits) |
备份恢复工具集,提供全量、增量数据备份和恢复功能 |
OceanBase 迁移服务(OceanBase Migration Service) |
提供了异构/同构RDBMS到OceanBase数据迁移/同步的服务 |
注:试用版本下载目前仅支持1.4.6.2版本,且不包含OCP产品,如需全功能体验,可联系商务洽谈。同时,2.2试用版本即将上线官网,敬请期待!
图2:OceanBase产品家族关系图
产品家族关系参见下图。以java应用为例,用户(app users)使用的数据库应用程序(APP1,APP2,APP3)分别通过mysql java驱动连接本地OceanBase访问代理(OceanBase Proxy)、mysql java驱动连接远程OceanBase访问代理(OceanBase Proxy)和使用OceanBase java驱动(OceanBase Connector Java)直连OceanBase数据库(OceanBase DataBase Server)三种连接方式连接使用OceanBase;应用开发者(Developer)使用OceanBase开发者中心(OceanBase Developer Center)对应用访问数据库进行日常数据操作;数据库管理员(DBA)通过OceanBase云平台(OceanBase Cloud Platform)对数据库进行监控运维等操作,并通过OceanBase云平台(OceanBase Cloud Platform)执行OceanBase备份恢复工具包(OceanBase Backup/Restore Toolkits)的部署操作,后依赖部署成功的备份恢复服务和相关存储服务(目前支持OSS对象存储和NFS网络文件系统),再次通过OceanBase云平台(OceanBase Cloud Platform)执行OceanBase备份恢复操作;当需要从异构/同构关系型数据库同步和复制数据时,可使用OceanBase迁移服务(OceanBase Migration Service)配置源于目标关系后启动相关任务。其他产品技术细节可在后续产品概述章节学习了解。
OceanBase家族各产品概述
1. OceanBase数据库概述
OceanBase数据库(OceanBase DataBase Server),是OceanBase家族中的核心产品,因为其核心定位和组件众多复杂,被形象地称为OB kernel。主要解决怎么做存储,怎么做事务,怎么做查询,怎么做高可用几个关键问题,目标是让OceanBase同时具备可扩展、高可用、低成本的核心技术优势,满足金融级业务的客观实际需求。
OceanBase数据库采用 Share-Nothing 架构,各个OceanBase节点之间完全对等,每个OceanBase节点都有自己的 SQL 引擎和存储引擎。OceanBase集群基础架构见下图。
图3:OceanBase集群基础架构图
OceanBase 2.x版本在1.4.x版本分布式技术架构的基础上,同时提供了大量新特性功能,进一步增强了OceanBase作为金融级分布式数据库的能力,相关功能包括Oracle模式、全局一致性快照、全局索引、复制表功能等,其他新增功能及细节请参考公众号2.x版本相关文章。
OceanBase数据库相关概念:
- OceanBase节点(OB服务器,OBServer)
指一台运行OBServer服务/进程的服务器容器,可能是物理服务器,虚机,容器。按照标准的部署方式,OBServer进程和OceanBase节点的关系是1:1。
- 租户(Tenant)
OceanBase通过租户实现资源隔离,采用“单集群多租户”的管理模式。在一个OceanBase数据库集群之中,可以提供若干个灵活配置计算存储资源的数据库服务实例。这些不同的实例叫租户,因此又称租户实例。每个租户不感知其他租户存在,提供一套完整独立的数据库服务,每个OceanBase集群有一个系统租户和若干个用户租户。系统租户下存放OceanBase数据库管理的各种集群内部元数据信息;用户租户存放用户的各种数据和隶属租户数据库元信息。
- 资源池(Resource Pool)
一个租户可以拥有若干个资源池,相关资源池集合描述了该租户所能使用的所有资源。一个资源池由具有相同资源规格(Unit Config)的若干个UNIT(资源单元)组成。一个资源池只能属于一个租户。每个UNIT描述了位于一个Server上的一组计算和存储资源,可以视为一个轻量级虚拟机,包括若干CPU资源,内存资源,磁盘资源等。一个租户在同一个Server上最多有一个UNIT。实际上,从概念上讲,副本是存储在UNIT之中,UNIT是副本的容器。
- 数据库(Database)
数据库是按数据结构来组织、存储和管理数据的仓库。数据库下包括若干表、索引,以及数据库对象的元数据信息。
- 表(Table)
最基本的数据库对象,OceanBase的表都是关系表。每个表由若干行记录组成,每一行有相同的预先定义的列。用户通过SQL语句对表进行增、删、查、改等操作。通常,表的若干列会组成一个主键,主键在整个表的数据集合内唯一。
- 分区(Partition)
分区是物理数据库设计技术,它的操作对象是表。实现分区的表,我们称之为分区表。表分布在多个分区上。当一个表很大的时候,可以水平拆分为若干个分区,每个分区包含表的若干行记录。根据行数据到分区的映射关系不同,分为hash分区,range分区(按范围),key分区等。每一个分区,还可以用不同的维度再分为若干分区,叫做二级分区。例如,交易记录表,按照用户ID分为若干hash分区,每个一级hash分区再按照交易时间分为若干二级range分区。
- 表组(TableGroup)
表格组。每个表都可能有自己所属的表格组。TableGroup是一个逻辑概念,它和物理数据文件没有关联关系,TableGroup只影响表分区的调度方法,OceanBase会优先把属于同一个TableGroup的相同分区号的调度,调度到同一台节点上,以减少跨节点分布式事务。
- 副本(Replica)
OceanBase数据库是以表分区(partition)为原子粒度进行管理的,为了数据安全和提供高可用的数据服务,每个分区数据在物理上存储多份,每一份叫做分区的一个副本。每个副本,包括存储在磁盘上的静态数据(SSTable)、存储在内存的增量数据(MemTable)、以及记录事务的日志三类主要的数据。根据存储数据种类的不同,副本有几种不同的类型,以支持不同业务在在数据安全,性能伸缩性,可用性,成本等之间的选择。
- 全能型副本(Full Replica)
目前支持的普通副本,拥有事务日志,MemTable和SSTable等全部完整的数据和功能,可随时快速切换为leader对外提供服务。
- 日志型副本(Log Replica)
只包含日志的副本,没有MemTable和SSTable。它参与日志投票并对外提供日志服务,可以参与其他副本的恢复,但自己不能变为主提供数据库服务。
- 只读型副本(Read Replica)
包含完整的日志,MemTable和SSTable等,但是它的日志比较特殊。它不作为paxos成员参与日志的投票,而是作为一个观察者实时追赶paxos成员的日志,并在本地回放。这种副本可以在业务对读取数据的一致性要求不高的时候提供只读服务。因其不加入paxos成员组,又不会造成投票成员增加导致事务提交延时的增加。
- 主/从副本(Leader/Follower)
主/从副本定义了某一时刻某表分区副本的角色。对于OceanBase每个分区至少三副本,副本之间使用Paxos协议同步Leader的Redo到Follower,策略上三个成员里只要有超过半数以上成员接收到Redo并落盘成功确认后,Leader上的事务才可提交。每个分区的全部副本(三副本,五副本等)是一个独立的Paxos Group,交付自行独立选主的能力,当一个Oceanbase节点故障时,只有对应Oceanbase节点内部作为Leader的observer服务中断,OB集群服务会自动选出新的Leader。
- 地域(Region)
OceanBase支持数据跨地域(Region)部署,应对地域级容灾需求。一个Region包含一个或者多个可用区(Zone)。
- 区,可用性区(Zone,Availabilty Zone)
Zone是AvailabilityZone的简写。一个OceanBase集群,由若干个Zone组成。Zone的含义是可用性区,通常指一个机房(数据中心,IDC)。为了数据的安全和高可用性,一般会把数据的多个副本分布在多个Zone上。对于OceanBase来说,可以实现单个Zone的故障不影响数据库服务。一个Zone包括若干OBServer服务器。
- 主可用区(Primary Zone)
同一partition的数据副本(replica)分布在多个Zone中,其中作为主副本(leader)的partition所在的Zone称为Primary Zone。可以为分区指定一个Zone的列表,当分区需要切主的时候,容灾策略会按照这个列表的顺序决定新主的偏好位置。如果不设定primary zone,系统会根据负载均衡的策略,在多个全功能副本里自动选择一个作为leader。
- 只读可用区(只读Zone,Read Zone)
只读Zone是一种特殊的Zone,在这个Zone里,只部署只读副本。通常当多数派副本故障的时候,OceanBase会停止服务,但在这种情况下,只读Zone能继续提供“弱一致性”读(“读Zone”,“读库”)。这也是OceanBase提供读写分离的一种方案。
- MySQL模式(MySQL兼容性模式,MySQLmode)
为降低MySQL数据库迁移OceanBase引发的业务系统改造成本,使业务数据库设计人员、开发人员、数据库管理员等可复用积累的技术知识经验,快速上手使用OceanBase所做的一种租户类型功能,目前高度兼容MySQL语法,常用系统表、函数保持一致。
- Oracle模式(Oracle兼容性模式,Oracle mode-OceanBase 2.X)
为降低Oracle数据库迁移OceanBase引发的业务系统改造成本,使业务数据库设计人员、开发人员、数据库管理员等可复用积累的技术知识经验,快速上手使用OceanBase所做的一种租户类型功能,逐步兼容Oracle语法,常用系统表、函数保持一致。
- 全局一致性快照(Global Consistent Snapshot-OceanBase 2.X)
在没有实现全局一致性快照前,分布式数据库无法实现跨节点的一致性读和保证因果序。OceanBase 1.4.x版本下,应用系统设计和开发人员需要保证一条SQL语句中访问的多个表、多个分区都在同一个OceanBase节点上,同时对于依赖操作顺序的业务系统,无法保证两个前后事务分别修改两个节点上两张表的数据反映顺序。OceanBase 2.x版本实现的全局一致性快照功能,从根本上解决了这些问题。相对于Google Truetime基于原子钟的硬件实现,OceanBase的全局时间戳(GTS)服务是纯软件实现的,不依赖特定的硬件设备,也不对客户方的部署环境提额外的要求,使得OceanBase能够服务更广泛的专有云客户。2.X版本全局时间戳打开后,跨节点读写、因果序的行为和单机数据库完全一致。
- 全局索引(Global Index-OceanBase 2.X)
为应对业务不带分区键条件查询SQL的高性能需求,同时保证数据一致性,OceanBase 2.x版本提供了全局索引的功能。在全局索引的创建和使用上,OceanBase基于代价做选择,创建时可基于基本表,也可基于索引。
- 复制表功能(Duplicated Table-OceanBase 2.X)
为应对应用访问频率高更新低频率同时总能访问到最新数据的小表访问需求,同时要保证数据一致性,目前只能选择强一致性读访问Leader数据的方案。但由于访问频率高,Leader容易成为性能瓶颈。为了解决“小表广播”需求场景问题,OceanBase 2.x版本结合自身架构提供了复制表功能,将相关小表的副本复制到表所属租户的所有OBServer上。该表称为复制表,这些副本称为复制副本。复制表的更新事务在提交时保证将数据同步到所有的全功能副本及复制副本,确保在更新事务commit成功之后,在租户任意OBServer上能读到该事务修改的数据。
2. OceanBase云平台概述
OceanBase云平台(以下简称OCP)致力于降低用户使用OceanBase的门槛及成本,为用户提供高效、稳定、易用的数据库服务。通过OCP可以一键安装、部署、升级OceanBase集群,监控集群的运行状态,创建和维护运维任务,并且对应用开发者透明。
OCP由运维链路、监控链路、诊断链路、数据链路、高可用链路、基础设施等若干子系统组成。每个子系统又切分成数十个甚至上百个小服务,服务间弱依赖,以可插拔式的灵活结构为使用者提供了个性化定制能力,构建符合使用者风格的高效数据库管控平台。OCP产品架构见下图:
图4:OCP产品功能模块架构图
3. OceanBase开发者中心概述
OceanBase开发者中心(以下简称ODC)是为OceanBase数据库量身打造的企业级数据库开发平台,提供数据库日常操作、企业数据资产管控、业务去 O、Devops 落地等能力。旨在帮助企业安全、高效的使用数据库,提升开发人员与DBA 的协作效率。
ODC由基础能力和应用中心两大部分组成。基础能力部分包含了元数据,任务引擎,流程引擎,安全引擎,变更引擎,通知中心,权限中心,资源管理中心等各功能组件;应用中心则包含了与数据库相关的各种功能选件。
ODC产品架构见下图:
图5:ODC产品各功能模块架构图
4. OceanBase访问代理概述
OBProxy作为OceanBase专用反向代理服务器,为前端用户请求提供了高性能高准确率的路由转发服务,为后端OBServer服务提供了高可用易扩展的容灾保障。相对于其他数据库的代理服务器,OBProxy根据实际单机环境和OceanBase多集群部署的特点,采用异步框架和流式转发的设计,具备有限资源占用下百万的QPS能力和海量部署时便捷的运维能力。
OceanBase访问代理相关概念:
- 逻辑数据中心(LDC, Logical Data Center)
LDC是对IDC(Internal Data Center, 互联网数据中心)的一种逻辑划分。OceanBase在多地多中心部署时,会以Region和Zone的单位对所有OBServer服务器进行划分,此时OceanBase的客户端路由和OceanBase内部的RPC路由被称为LDC路由。
- 地域/互联数据中心(Region/IDC)
每台OBServer服务器都具有Region/IDC属性,其中Region记录OB集群地域信息,通常代表一个城市,IDC记录OB集群的机房信息。一个OB集群包含若干个Region,每个Region包含若干个IDC,每个IDC部署若干个OBServer服务器。根据不同Region和IDC,OB客户端与OBServer服务器,或者OBServer服务器与OBServer服务器之间的位置关系可以分为3种:同Region同IDC,同Region不同IDC,不同Region。三者优先级依次降低。
- 强一致性读/弱一致性读(Strong Read Consistentcy / Weak Read Consistentcy)
强一致性读是默认的一种OceanBase SQL执行方式,即SQL必须转发到涉及Partition的Leader 所在的OBServer服务器上才能执行,用以保证获取到实时最新数据。弱一致性读是相对于强一致性读来说的。即SQL只需在涉及Partition的OBServer服务器上执行即可,不强制是Leader。如需使用弱一致性select,主要通过两种方式。一种是带read_consistency(weak) hint的select语句,另一种是在当前session中修改ob_read_consistency的系统变量取值为weak。
5. OceanBase java驱动概述
OceanBase MySQL模式下,完全兼容MySQL原生的JDBC 驱动(mysql-connector-java),同时OceanBase基于 mysql-connector-java(5.1.40版本)的代码扩展出了OceanBase专属的 JDBC 驱动(oceanbase-client),该驱动完全兼容MySQL JDBC的使用方式并且可以自动识别OceanBase的运行模式(MySQL/Oracle mode),协议层兼容 2 种模式,兼容 OB2.x协议。
如下为JDBC连接串代码样例。连接串的前缀需要设置为jdbc:oceanbase,其他部分使用方式与原生的MySQL 使用方式保持一致。
String url = "jdbc:oceanbase://<ip>:<port>/SYS?useUnicode=true&characterEncoding=utf-8"; String username = "SYS@oracle"; String password = ""; Connection conn = null; try { Class.forName("com.alipay.oceanbase.obproxy.mysql.jdbc.Driver"); conn = DriverManager.getConnection(url, username, password); PreparedStatement ps = conn.prepareStatement("select to_char(sysdate,'yyyy-MM-dd HH24:mi:ss') from dual;"); ResultSet rs = ps.executeQuery(); rs.next(); System.out.println("sysdate is:" + rs.getString(1)); rs.close(); ps.close(); } catch (Exception e) { e.printStackTrace(); } finally { if (null != conn) { conn.close(); } }
6. OceanBase备份恢复工具包概述
OceanBase是一个读写分离的系统,内部数据按照存储方式,划分为基于 SSTable 格式的基线数据和基于MemTable 格式的增量数据。基线数据是当前次合并落盘的数据之和,被切分为多个分片并复制多个副本,均匀的分散存储在各个OBServer 的数据文件中。增量数据是当前合并时间点以后的所有更新数据,一般会存储在MemTable 的内存表中,同时也会实例化为 Commit Log 文件的形式存放在硬盘上。因此,OceanBase的物理备份就是把某次合并的基线数据,以及该次合并后的增量数据 Commit Log 拷贝到异地机房的存储系统中。目前支持的存储介质有:阿里云对象存储OSS 、基于NFS的文件系统。
OceanBase的备份恢复支持数据库上的任何操作,支持的数据包括用户权限、表定义、系统变量、用户信息、视图信息等逻辑数据以及所有的物理数据。
OceanBase的备份恢复目前支持的最小粒度是租户,也就是说,可以按需只备份恢复某个租户而不是整个集群,从而增加了备份恢复的灵活性,节省了空间。同时OceanBase的备份恢复也可以恢复到任意时间点。
OceanBase备份恢复服务架构见下图:
图6:OceanBase备份恢复服务架构图
OceanBase备份恢复工具包相关概念:
- 备份元数据库/恢复元数据库(Backup Metadb/ Restore Metadb)
备份元数据库包含参数表backup_base_profile以及控制备份任务的四张表,分别是base_data_backup, base_data_backup_task, base_data_backup_task_history, inc_data_backup。恢复元数据库包含控制恢复任务的四张表,分别是oceanbase_restore, base_data_restore, inc_data_restore, oceanbase_restore_history。通常会将备份元数据库和恢复元数据库部署在同一个数据库中。
- 备份工具程序/恢复工具程序(AgentServer/agentrestore.jar)
AgentServer 是备份工具,是一个常驻进程,每隔一段时间查询元数据库MetaDB中的base_data_backup表有无备份任务,来控制整个基线、增量数据备份的发起、取消,也会随着任务的推进更新备份任务四张表的状态。agentrestore.jar是恢复工具,顾名思义是java编写的jar包,也是常驻进程,每隔一段时间查询元数据库MetaDB中的控制表,负责调度整个恢复任务的发起,也会随着任务的推进更新恢复任务四张表的状态。
- OCP备份恢复功能(OCP Backup And Restore)
目前除通过命令行方式部署OceanBase备份恢复工具包以外,OCP也提供了完整的备份恢复功能。用户可通过OCP页面对备份恢复工具包执行部署安装,使用已部署好的备份恢复服务快速方便地执行备份和恢复操作,同时依赖OCP提供监控链路执行统一的监控报警。
7.OceanBase迁移服务
OceanBase迁移服务(OceanBase Migration Service,简称OMS)提供了异构/同构关系型数据库系统到OceanBase数据库的数据同步/复制能力,以最低的风险,最小的开销,最高的效率实现异构/同构数据库向Oceanbase进行实时数据迁移/同步操作,目前支持的源端类型包括MySQL、Oracle、OceanBase、DB2。
OceanBase迁移服务可在业务应用全程无感知,不中段的前提下执行数据迁移/同步,同时保证数据的一致性和事务的完整性。OceanBase迁移服务提供可视化的集中管控平台,通过简单的配置完成数据的实时迁移,对源数据库和目标系统的影响开销可忽略不计。
OceanBase迁移服务同时提供正向切换和反向切换能力。用户通过OMS完成在线迁移数据工作后,在执行业务应用切换OB前,可通过OMS自动启用反向同步链路,再执行应用切换到Oceanbse数据库。此时所有在切换后后发生在OceanBase数据库上的数据变更都将实时同步至切换前的源端数据库,以此来应对紧急回切的真实需求场景,最大程度的降低业务迁移风险。
OMS产品各功能模块架构见下图。
图7:OMS产品各功能模块架构图