OceanBase-一款功能无敌的多模数据库

点击上方“小强的进阶之路”，选择“星标”公众号

优质文章，及时送达

预计阅读时间: 5分钟

NoSQL历史

KV型NoSql（代表----Redis）：解决快速的读写问题，但是会丢失数据

搜索型NoSql（代表----ElasticSearch）：支持快速的全文搜索，同时可以各种方式的分词查询等。但是不能随意扩展结构。

列式NoSql（代表----HBase）：支持海量无限级数据源的存储。运维复杂

文档型NoSql（代表----MongoDB）：按照文档类型存储，使用方便，不支持事务。支持嵌套数据类型，例如JSON、BSON等。

关系型和非关系型数据库对比

BASE是NoSQL数据库通常对可用性及一致性的弱要求原则:

1、Basically Availble --基本可用

2、Soft-state --软状态/柔性事务。“Soft state” 可以理解为“无连接”的, 而 “Hard state” 是“面向连接”的，使用简单的RPC协议，没有传统JDBC接口的“重”连接，几乎不受连接数的限制。

3、Eventual Consistency --最终一致性， 也是ACID的最终目的。

一致性是指每次发出相同请求时，数据库查询都返回相同的数据。强一致性意味着返回最新的数据，但由于内部一致性方法，它可能会导致更高的延迟。对于最终的一致性，查询结果不太一致，但它们更快，延迟更低。

关系型数据库管理系统，SQL代表结构化查询语言，通用的SQL语言使得操作关系型数据库非常方便。“没有SQL”（不使用SQL来查询）或者不仅仅是SQL（使用SQL和非SQL查询方式）。

因为数据是按行存储，即使只针对其中某一列进行运算，关系型数据库也会将整行数据从存储设备中读入内存，导致I/O较高。

多模数据库

多模数据库：是指在单个数据库系统中支持非结构化和结构化数据在内的多种数据类型，将能实现结构化、

半结构化和非结构化数据的统一管理。

OceanBase为什么支持多模型?

1、NoSQL的API和SQL可以同时操作同一份数据；

2、NoSQL数据模型拥有ACID事务能力和严格的一致性模型

3、同一个租户可以同时支持API和SQL；

4、OBKV共享OB生态体系:离线能力、高可用能力、极致性能、极优成本；

OceanBase多模型怎么做?

1、OB在SQL层面支持MySQL和Oracle两种SQL语法；

2、在OB关系型的基础上拓展了NoSQL能力，通过SDK提供的API，应用可以不使用SQL就能直接读写存储在OB中的数据；

3、tableAPI支持表模型和KV模型；

4、HBaseAPI支持Hbase模型；

表模型和Hbase模型

KV模型本质上是一种简化的关系表模型，建表时只有K和V两列，并进行K或者K的前缀进行分区。

tableAPI bypass SQL层，直接访问存储层，数据访问路径短，相同功能时性能更优。且语义简单，更容易优化。API接口使用简单，不需要复杂的ER映射。

但tableAPI提供的Query接口功能无法和SQL同日而语，只能提供 get、scan、limit等有限功能，如果需要聚合、排序等复杂功能，应该使用SQL。也不提供交互式的事务等复杂事务功能。

整体架构

OceanBase数据库集群有一个或多个Region组成， Region由一个或多个Zone组成，Zone由一个或多台ObServer组成；

Zone通常由一个机房内的若干服务器组成；为了数据安全性和高可用性，一般会把数据的多个副本分布在不同的 Zone 上，可以实现单个 Zone 故障不影响数据库服务；一台物理机上可以部署一个或者多个OBServer。

OceanBase数据库支持数据跨地域（Region）部署，每个地域可能位于不同的城市，距离通常比较远，所以OceanBase数据库可以支持多城市部署，也支持多城市级别的容灾。一个Region 可以包含一个或者多个 Zone，Zone 是一个逻辑的概念，它包含了 1 台或者多台运行了 OBServer进程的服务器（以下简称 OBServer）。每一个 Zone 上包含一个副本（全功能副本或者日志副本），由于 OceanBase数据库的数据副本是以分区为单位的，所以同一个分区的数据会分布在多个Zone 上。

每个Zone提供总控服务和分区服务；总控服务负责整个集群的资源调度、资源分配、数据分布信息管理以及 Schema 管理等功能；分区服务负责每个 OBServer上各个分区的管理和操作功能的模块；

每个 Zone 上都会存在一个总控服务，运行在某一个 OBServer上，整个集群中只存在一个主总控服务，其他的总控服务作为主总控服务的备用服务运行。分区服务与事务引擎、存储引擎存在很多调用关系。

ObServer包含SQL引擎、事务引擎和存储引擎，服务于多个数据分区；

OceanBase基于Paxos的分布式选举算法实现高可用，最小的粒度可以做到分区级别。

集群中数据的一个分区（或者称为副本）会被保存到所有的 Zone 上，整个系统中该副本的多个分区之间通过 Paxos协议进行日志同步。每个分区和它的副本构成一个独立的 Paxos复制组，其中一个分区为主分区（Leader），其它分区为备分区（Follower）。

SQL引擎

OceanBase数据库的 SQL 引擎是整个数据库的数据计算中枢，和传统数据库类似，整个引擎分为解析器、优化器、执行器三部分。当SQL 引擎接受到了 SQL 请求后，经过语法解析、语义分析、查询重写、查询优化等一系列过程后，再由执行器来负责执行。所不同的是，在分布式数据库里，查询优化器会依据数据的分布信息生成分布式的执行计划。如果查询涉及的数据在多台服务器，需要走分布式计划，这是分布式数据库SQL 引擎的一个重要特点。

1、在收到用户发送的 SQL 请求串后，Parser 会将字符串分成一个个的“单词”，并根据预先设定好的语法规则解析整个请求，将SQL 请求字符串转换成带有语法结构信息的内存数据结构，称为“语法树”（Syntax Tree）。

2、当生成“语法树”之后，Resolver 会进一步将该语法树转换为带有数据库语义信息的内部数据结构。在这一过程中，Resolver 将根据数据库元信息将 SQL 请求中的 token 翻译成对应的对象（例如库、表、列、索引等），生成“语句树”。

3、在查询优化中，经常利用等价改写的方式，将用户 SQL 转换为与之等价的另一条 SQL，以便于优化器生成最佳的执行计划，这一过程称为“查询改写”。Transformer 在 Resolver 之后，分析用户 SQL 的语义，并根据内部的规则或代价模型，将用户 SQL 改写为与之等价的其他形式，并将其提供给后续的优化器做进一步的优化Transformer的工作方式是在原 Statement Tree 上做等价变换，变换的结果仍然是一棵“语句树”。

4、优化器是整个 SQL 优化的核心，其作用是为 SQL 请求生成最佳的执行计划。在优化过程中，优化器需要综合考虑SQL 请求的语义、对象数据特征、对象物理分布等多方面因素，解决访问路径选择、联接顺序选择、联接算法选择、分布式计划生成等多个核心问题，最终选择一个对应该SQL 的最佳执行计划。SQL 的执行计划是一棵由多个操作符构成的“执行树”。

5、优化器负责生成最佳的执行计划，但其输出的结果并不能立即执行，还需要通过代码生成器将其转换为可执行的代码，这个过程由 Code Generator 负责。

6、当 SQL 的执行计划生成后，Executor 会启动该 SQL 的执行过程。对于不同类型的执行计划，Executor 的逻辑有很大的不同：对于本地执行计划，Executor 会简单的从执行计划的顶端的算子开始调用，由算子自身的逻辑完成整个执行的过程，并返回执行结果；对于远程或分布式计划，Executor 需要根据预选的划分，将执行树分成多个可以调度的线程，并通过RPC 将其发送给相关的节点执行。

7、执行计划的生成是一个比较复杂的过程，耗时比较长，尤其是在 OLTP 场景中，这个耗时往往不可忽略。为了加速 SQL 请求的处理过程，SQL 执行引擎会将该 SQL 第一次生成的执行计划缓存在内存中，后续的执行可以反复执行这个计划，避免了重复查询优化的过程。

存储引擎

OceanBase数据库的存储引擎采用了基于 LSM-Tree 的架构，把基线数据和增量数据分别保存在磁盘（SSTable）和内存（MemTable）中，其中 SSTable是只读的，一旦生成就不再被修改，存储于磁盘；MemTable支持读写，存储于内存。数据库 DML 操作插入、更新、删除等首先写入 MemTable，等到 MemTable达到一定大小时转储到磁盘成为 SSTable。在进行查询时，需要分别对 SSTable和 MemTable进行查询，并将查询结果进行归并，返回给 SQL 层归并后的查询结果。

在内存中针对不同的数据访问行为，OceanBase数据库设计了多种缓存结构。内存实现了 Block Cache 和 Row cache，来避免对基线数据的随机读。行缓存会极大加速对单行的查询性能。为了避免对不存在行的“空查”，OceanBase数据库对行缓存构建了布隆过滤器，并对布隆过滤器进行缓存。

在转储之前首先需要保证被转储的 MEMTable不再进行新的数据写入，这个过程称之为冻结（Minor Freeze），冻结会阻止当前活跃的 MEMTable再有新的写入，并同时生成新的活跃 MEMTable。

转储和合并的最大区别在于，合并是集群上所有的分区在一个统一的快照点和全局静态数据进行合并的行为，是一个全局的操作，最终形成一个全局快照。

高可用

1、高可用设计考虑两方面

•宕机或意外中断，能够自动恢复可用性，减少业务受影响时间•少数节点发生故障导致这部分节点的数据无法读取时，保证业务数据不会丢失•

2、OceanBase数据库底层实现了 Paxos高可用协议，在主库故障后，剩余的服务器会很快自动选举出新的主库，并继续提供服务。

3、同一数据保存在多台（>= 3）服务器中的半数以上服务器上，每一笔写事务必须到达半数以上服务器才生效，因此当少数服务器故障时不会有任何数据丢失。

End

推荐阅读：

工作中一些原则体会

程序员因接外包坐牢 456 天！两万字长文揭露心酸真实经历

清华大学两名博士生被开除：你不吃学习的苦，就要吃生活的苦

明天见(｡･ω･｡)ﾉ♡