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


Share-Nothing 架构
每个OceanBase节点都有自己的 SQL 引擎和存储引擎。


OceanBase 2.x版本在1.4.x版本分布式技术架构的基础上，同时提供了大量新特性功能，
进一步增强了OceanBase作为金融级分布式数据库的能力，相关功能包括Oracle模式、全局一致性快照、全局索引、复制表功能等


相关概念

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.0版本实现的全局一致性快照功能，从根本上解决了这些问题。
相对于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上能读到该事务修改的数据。


OceanBase访问代理概述

OBProxy作为OceanBase专用反向代理服务器，为前端用户请求提供了高性能高准确率的路由转发服务，为后端OBServer服务提供了高可用易扩展的容灾保障。
相对于其他数据库的代理服务器，OBProxy根据实际单机环境和OceanBase多集群部署的特点，采用异步框架和流式转发的设计，具备有限资源占用下百万的QPS能力和海量部署时便捷的运维能力。


访问代理相关概念

逻辑数据中心（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。


OceanBase备份恢复工具包概述

OceanBase是一个读写分离的系统，内部数据按照存储方式，划分为基于 SSTable 格式的基线数据和基于MemTable 格式的增量数据。
基线数据是当前次合并落盘的数据之和，被切分为多个分片并复制多个副本，均匀的分散存储在各个OBServer 的数据文件中。
增量数据是当前合并时间点以后的所有更新数据，一般会存储在MemTable 的内存表中，同时也会实例化为 Commit Log 文件的形式存放在硬盘上。
因此，OceanBase的物理备份就是把某次合并的基线数据，以及该次合并后的增量数据 Commit Log 拷贝到异地机房的存储系统中。
目前支持的存储介质有：阿里云对象存储OSS 、基于NFS的文件系统。

OceanBase的备份恢复支持数据库上的任何操作，支持的数据包括用户权限、表定义、系统变量、用户信息、视图信息等逻辑数据以及所有的物理数据。

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提供监控链路执行统一的监控报警。