OceanBase 数据库概览-数据库介绍
集群节点全对等，每个节点都具备计算和存储能力，无单点瓶颈。支持线性扩展，在线扩展，单一数据库集群最大超过 1500 台服务器。
数据采用多副本存储，少数副本故障不影响数据可用性，RPO = 0（Recovery Point Objective，零数据丢失），RTO < 30秒（Recovery Time Objective，故障恢复时间小于 30 秒）。
数据多副本通过 Paxos 协议同步事务日志，多数派成功才能提交。缺省情况下读、写操作在主副本进行保证强一致。
- 支持 MySQL 5.6 版本全部语法，可以实现 MySQL 业务无缝切换。
- 支持绝大部分的 Oracle 数据类型和对象、SQL 语法、函数、过程性语言等功能
面向海量事务处理的分布式数据库系统 OceanBase 数据库采用了 Zone（可用区）的概念.
每个 Zone 是一个机房内的一组服务器，包含多台 OceanBase 数据库服务器（OBServer）。
每台 OBServer 包含 SQL 引擎、事务引擎和存储引擎，并服务多个数据分区.
其中，每个 Zone 有一台 OBServer 会同时使能总控服务（RootService），用于执行集群管理、服务器管理、自动负载均衡等操作。
OBServer 上会运行 SQL 引擎、事务引擎和存储引擎，用户的 SQL 查询经过 SQL 引擎解析优化后转化为事务引擎和存储引擎的内部调用。
对于跨服务器操作，OceanBase 数据库还会执行强一致的分布式事务，从而在分布式集群上实现数据库事务 ACID。
OceanBase 数据库采用 Shared-Nothing 架构，各个节点之间完全对等，每个节点都有自己的 SQL 引擎、事务引擎、存储引擎，运行在普通 PC 服务器组成的集群之上，具备可扩展、高可用、高性能、低成本等核心特性。
OceanBase 数据库支持数据跨地域（Region）部署，每个地域可能位于不同的城市，距离通常比较远，所以 OceanBase 数据库可以支持多城市部署，也支持多城市级别的容灾。
一个 Region 可以包含一个或者多个 Zone.
Zone 是一个逻辑的概念，它包含了 1 台或者多台运行了 OBServer 进程的服务器（以下简称 OBServer）。
每一个 Zone 上包含一个副本（全功能副本或者日志副本），由于 OceanBase 数据库的数据副本是以分区为单位的，所以同一个分区的数据会分布在多个 Zone 上。
每个分区的主副本所在服务器被称为 Leader，所在的 Zone 被称为 Primary Zone。
如果不设定 Primary Zone，系统会根据负载均衡的策略，在多个全功能副本里自动选择一个作为 Leader。
每个 Zone 会提供两种服务：总控服务（RootService）和分区服务（PartitionService）。
其中每个 Zone 上都会存在一个总控服务，运行在某一个 OBServer上，整个集群中只存在一个主总控服务，其他的总控服务作为主总控服务的备用服务运行。
总控服务负责整个集群的资源调度、资源分配、数据分布信息管理以及 Schema 管理等功能。
分区服务用于负责每个 OBServer 上各个分区的管理和操作功能的模块，这个模块与事务引擎、存储引擎存在很多调用关系。
OceanBase 数据库基于 Paxos 的分布式选举算法来实现系统的高可用，最小的粒度可以做到分区级别。集群中数据的一个分区（或者称为副本）会被保存到所有的 Zone 上，整个系统中该副本的多个分区之间通过 Paxos 协议进行日志同步。每个分区和它的副本构成一个独立的 Paxos 复制组，其中一个分区为主分区（Leader），其它分区为备分区（Follower）。所有针对这个副本的写请求，都会自动路由到对应的主分区上进行。主分区可以分布在不同的 OBServer 上，这样对于不同副本的写操作也会分布到不同的数据节点上，从而实现数据多点写入，提高系统性能。
在内存中针对不同的数据访问行为，OceanBase 数据库设计了多种缓存结构。
除了常见的数据块缓存之外，也会对行进行缓存，行缓存会极大加速对单行的查询性能。
为了避免对不存在行的“空查”，OceanBase 数据库对行缓存构建了布隆过滤器，并对布隆过滤器进行缓存。
当内存的增量数据达到一定规模的时候，会触发增量数据和基线数据的合并，把增量数据落盘。
同时每天晚上的空闲时刻，系统也会启动每日合并。
另外，由于基线是只读数据，而且内部采用连续存储的方式，OceanBase 数据库可以根据不同特点的数据采用不同的压缩算法，既能做到高压缩比，又不影响查询性能，大大降低了成本。
OceanBase 数据库的 SQL 引擎是整个数据库的数据计算中枢，和传统数据库类似，整个引擎分为解析器、优化器、执行器三部分。
Region 指一个地域或者城市（例如杭州、上海、深圳等），一个 Region 包含一个或者多个 Zone，不同 Region 通常距离较远。OceanBase 支持一份数据的多个副本跨 Region 部署。
Zone 是 Availability Zone 的简称。一个 OceanBase 集群，由若干个可用区（Zone）组成。通常由一个机房内的若干服务器组成一个 Zone。为了数据安全性和高可用性，一般会把数据的多个副本分布在不同的 Zone 上，可以实现单个 Zone 故障不影响数据库服务。
运行 OBServer 进程的物理机。一台物理机上可以部署一个或者多个 OBServer。在 OceanBase 内部，server 由其 IP 地址和服务端口唯一标识。
一个租户拥有若干个资源池，这些资源池的集合描述了这个租户所能使用的所有资源。一个资源池由具有相同资源规格（Unit Config）的若干个 UNIT（资源单元）组成。一个资源池只能属于一个租户。每个 UNIT 描述了位于一个 Server 上的一组计算和存储资源，可以视为一个轻量级虚拟机，包括若干 CPU 资源，内存资源，磁盘资源等。
一个租户在同一个 Server 上最多有一个 UNIT。实际上，从概念上讲，副本是存储在 UNIT 之中，UNIT 是副本的容器。
OceanBase 数据库集群由一个或多个 Region 组成，
Region 由一个或多个 Zone 组成，
Zone 由一台或多台服务器组成。
Region 对应物理上的一个城市或地域，
当 OceanBase 数据库集群由多个 Region 组成时，数据库的数据和服务能力就拥有地域级容灾能力，当集群只有一个 Region 时，如果出现整个城市级别的故障，则会影响数据库的数据和服务能力。
Zone 对应一个有独立网络和供电容灾能力的数据中心，
在一个 Region 内的多个 Zone 间 OceanBase 数据库集群拥有 Zone 故障时的容灾能力。通常情况下，OceanBase 数据库集群的一个 Zone 内只会有数据的一份拷贝，如果整个集群只有一个 Zone，则集群没有容灾能力。
如果实际的运行环境只有一个数据中心的若干台机器，则可以将若干台机器划分成虚拟的 Zone，OceanBase 数据库会在这些虚拟的 Zone 之间具备容灾能力。
OceanBase 数据库的无损容灾能力还可以方便集群的运维操作.
数据中心或者服务器需要替换和维修时，可以直接下线对应的数据中心或服务器进行替换和维修，并补充进新的数据中心或服务器，OceanBase 数据库系统会自动进行数据的复制和均衡，整个过程可以保证数据库服务的使用不受影响。
OceanBase 数据库集群的每台服务器上会运行 observer 进程，observer 进程负责整个数据库服务的各项功能，包括资源管理与租户创建，数据分布的管理，数据副本之间的 Paxos 协议，单机或分布式的数据查询与修改等。
OceanBase 数据库是多租户的分布式数据库，用户可以在一个集群内部创建多个相互独立的租户，每个租户是一个独立的数据库服务，用户可以指定需要的硬件资源，创建数据库服务的账号、表格、存储过程等对象。
租户的硬件资源以资源池（Resource Pool）的形式进行描述，资源池是由资源单元（Resource Unit）组成，资源单元是数据库服务内部分配的 CPU、内存、硬盘等硬件资源。
资源单元对应 CPU、内存、存储空间、IOPS 这几个物理资源，是 OceanBase 数据库服务内部的资源容器。
资源单元会在集群内自动负载均衡，任何一个资源单元一定会放置在一个资源足够容纳它的服务器上。
当集群内的服务器下线前，其上的资源单元必须迁移到其他服务器上，如果集群内其他服务器的资源不足以容纳将要下线的服务器上的资源单元，会导致服务器下线无法成功。
资源单元配置是描述资源单元的配置信息，每一个资源单元配置会描述一种规格的 CPU、内存、存储空间、IOPS。修改资源配置可以动态调整资源单元的计算资源，进而调整对应租户的资源。
资源池由具有相同资源单元配置的若干个资源单元组成。
一个资源池只能属于一个租户。
一个租户可以拥有一个或多个资源池，这些资源池的集合描述了这个租户所能使用的所有物理机器资源。
一个租户在同一个服务器 上最多有一个资源单元。
传统数据库支持分区表.
常见的分区方式包括 Hash 分区、Range 分区、List 分区，且支持二级组合分区。
OceanBase 数据库沿用了分区表的使用方式，但是分区可以均匀分布在数据库任意节点上。
OceanBase 数据库以分布式分区表数据模型为基础，一方面，数据存储和处理能力能够水平扩展，享受分布式技术的红利，另一方面，使用者不感知后端的分布式架构，可以像使用单机数据库一样使用分布式数据库，具有完整的全局索引和全局约束。
OceanBase 数据库通过引入表格组（table group）来尽可能地减少分布式事务。
表格组用于聚集经常一起访问的多张表格。例如，有用户基本信息表（user）和用户商品表（user_item），这两张表格都按照用户编号哈希分布，只需要将二者设置为相同的表格组，系统后台就会自动将同一个用户所在的 user 表分区和 user_item 表分区调度到同一台服务器。这样，即使操作某个用户的多张表格，也不会产生跨机事务。这种设计兼具分布式系统的扩展性和关系数据库的易用性和灵活性，符合 DBA 的使用习惯。
主均衡策略解决的整体思路为：在某个均衡组中，根据副本的分布情况，实时挑选主，挑选主的结果为：primary_zone 上资源单元上分布的主的数量均衡。
租户是一个逻辑概念，在 OceanBase 数据库里是资源分配的单位，是数据库对象管理和资源管理的基础。
对于系统运维，尤其是对于云数据库的运维有着重要的影响。租户在一定程度上相当于传统数据库的“实例”概念。
租户之间是完全隔离的。
在数据安全方面，不允许跨租户的数据访问，确保用户的数据资产没有泄露的风险。
在资源使用方面表现为租户“独占”其资源配额。
总体上来说，租户（tenant）既是各类数据库对象的容器，又是资源（CPU、Memory、IO 等）的容器。
OceanBase 系统中包含两大类的租户：系统租户和普通租户。
(这不就是实例instance的概念吗?按照此理解)
普通租户具备一个实例所应该具有的所有特性：
- 可以创建自己的用户
- 可以创建数据库（database）、表（table）等所有客体对象
- 有自己独立的 information_schema 等系统数据库
- 有自己独立的系统变量
- 数据库实例所具备的其他特性
多租户隔离有不同的实现方式，这些实现方式的效果是类似的。
OceanBase 数据库采用的是在数据库内部实现一个 SQL 虚拟机，
这种方案的好处是 DB 内把很多业务统一管理，把整个管理机制做得对用户特别透明。
另外隔离的开销比较低，单台服务器可以服务更多的租户，降低云服务的整体成本。
租户隔离分为三个部分：CPU、IO 还有内存，网络目前还不是瓶颈，不做隔离。
OceanBase 数据库是分布式系统.
多租户除了单机层面怎么做隔离，还涉及到在多机层面如何做调度。
OceanBase 数据库的负载均衡分为两个层面：
第一个层面是租户负载均衡，即把每个租户的资源容器分布到很多台 OBServer 上面去。
第二个层面是分区负载均衡.
如果租户只在一台服务器，第二个层面是没有必要的。如果租户在多台服务器上，需要把这个租户的分区均匀地分布到它的资源容器中。OceanBase 数据库内部会尽量使得小租户只在一台服务器上，避免分布式事务。当租户需要的资源逐步增加时，OceanBase 数据库也能做到自动扩展，对用户是透明的
OceanBase 数据库概览
事务管理
分布式事务
关于OceanBase的2PC的理论,需要进一步要求.
分布式查询
在分布式数据库里，查询优化器会依据数据的分布信息生成分布式的执行计划。
存储架构
LSM Tree
B-tree
Hash table
转储和合并
当 MemTable 的内存使用达到一定阈值时，就需要将 MemTable 中的数据存储到磁盘上以释放内存空间，这个过程称之为“转储”。
在转储之前首先需要保证被转储的 MemTable 不再进行新的数据写入，这个过程称之为“冻结”（Minor Freeze）.
冻结会阻止当前活跃的 MemTable 再有新的写入，并同时生成新的活跃 MemTable。
合并操作（Major Compaction）是将动静态数据做归并，会比较费时。当转储产生的增量数据积累到一定程度时，通过 Major Freeze 实现大版本的合并。
转储和合并的最大区别在于，合并是集群上所有的分区在一个统一的快照点和全局静态数据进行合并的行为，是一个全局的操作，最终形成一个全局快照。
读写流程
与传统数据库的刷脏页机制不同，OceanBase 数据库的存储引擎基于 LSM Tree 架构，对于数据块的写主要是在转储和合并阶段。
在 MemTable 转储为 SSTable 时，也会在静态数据中记录当前的 clog 日志回放点，在转储完成之后，对应 clog 日志回放点之前的日志在理论上就可以被回收了，但通常这些日志文件并不会被立即删除，而是等到日志空间不足时再进行日志文件的重用。