本文整理自 OceanBase 首席架构师竹翁在 OceanBase 首期读书会的分享。本篇内容主要分为四个部分：OceanBase 数据库概览、数据库系统的可扩展性、OceanBase 分布式数据库对象和 OceanBase 分区特点。
一、OceanBase 数据库概览
伴随着 OceanBase 在去年6月1日的正式开源，不少用户希望能全面了解 OceanBase，《 OceanBase 数据库系统概念》这本用户手册便是在这样的背景下诞生的。该手册面向主要面向使用 OceanBase 的应用开发者、DBA、应用架构师、OceanBase 社区版开发者等广泛人群。这本书系统地、详细地讲解了 OceanBase 的概念和原理，即 OceanBase 是什么、不是什么、有什么、没有什么、为什么、怎么实现，希望为大家学习和使用 OceanBase 带来更多参考。
熟悉 Oracle 的同学可能知道，这本书的书名也是在向《Oracle 数据库系统概念》致敬。如果你不了解 Oracle，不了解 MySQL 也没有关系，只要你在大学计算机课程中学过数据库系统概念，就可以直接拿着 OceanBase 这本书作为下一阶段学习的入门。整体大纲如下：
- OceanBase 数据库简介
- 多租户架构
- 数据库对象
- 分布式数据库对象
- 数据链路
- 用户接口和查询语言
- 事务管理
- 存储架构
- 数据可靠性和高可用
- 数据库安全
- OBServer 节点架构
我们认为 OceanBase 最与众不同的地方在于 OceanBase 数据库是多租户的一个架构。很多用户对 OceanBase 产生问题的根源在于大家还没有理解 OceanBase 多租户的本质。所以我们在介绍完数据库系统的简介后，最先去讲的是多租户概念。接着在数据库对象这一层面，我们把 MySQL 和 Oracle 的概念彻底分开来讲。因此在行文描写上，我们讲解地会比较精细。如果想彻底搞清楚 MySQL 和 Oracle 的差别，非常推荐大家阅读本书。
OceanBase 在多年发展过程中，我们坚持以分布式数据库的核心特性——高可用和可扩展在迭代发展。在《分布式数据库对象》章节，我们主要讲解了三个概念——集群、分区、分区的副本。OceanBase 具备基于原生分布式的水平扩展能力，采用基于无共享集群的分布式架构，通过 Paxos 共识协议实现数据多副本的一致性。整个系统没有任何单点故障，保证系统的持续可用。可扩展性和高可用性是其最大的优势。
二、数据库系统的可扩展性
系统的可扩展性是指，当应用对系统处理量的需求变化时，系统在性能和成本等方面随之增加和降低的能力。一般情况下，单机数据库更关注垂直扩展性，分布式数据库更关注水平扩展性，而 OceanBase 作为分布式数据库，在保持水平扩展性的同时，还兼顾了单机数据库的垂直扩展性能。OceanBase 通过分片的方式，扩展其存储能力。当一个节点宕机或者数据丢失，还可以继续提供服务。实现了多副本、复制表与读写分离，增强了 OceanBase 的可靠性。
回顾几个经典数据库的扩展性。如上图所示，左边是单机 Oracle，右边是 Oracle RAC 集群。Oracle RAC 集群的特点是共享存储。集群内部有多个数据库节点，节点之间会共享 RAC存储。
与此同时，所有数据库节点之间，有一个内部的私有网络。节点和节点之间，可以快速进行数据交换。在小规模的数据存储时，这个架构有非常好的扩展性，且每个节点支持数据库的读写服务。
Aurora 的存储做了扩展，在 Replica 节点，实现了一写多读。它的兼容性较好，在一定程度上可以解决中等规模的存储要求，但不支持高并发写入。所以业界一般认为 Aurora 不是一个分布式数据库。
在 OceanBase 0.5时，其架构主要是上下两层。上层的 MergeServer 接收 SQL 请求，是无状态服务。为了优化吞吐率，我们可以做横向扩展。在存储方面，有两种节点组成，即 ChunkServer 和 UpdateServer。
ChunkServer 可以自动分裂，水平扩展存储。 UpdateServer 无分布式事务，其 Paxos 支持强一致的高可用。
OceanBase 1.0到3.0时，使用了对等节点，支持无共享集群。OBServer 包含了 SQL、存储、事务，支持单OBServer进程，管理简单，读写请求性能可扩展，可以按分区做数据分片扩展。与此同时，OceanBase 支持多 ZONE 多活扩展和单集群规模。在 TPC-C 时，OceanBase 使用1557节点。
三、OceanBase 分布式数据库对象
OceanBase 为了数据安全和提供高可用的数据服务，每个分区数据在物理上存储多份，每一份就是分区的一个副本。
分区副本包括存储在磁盘上的静态数据（ SSTable ）、存储在内存的增量数据（ MEMTable）、以及记录事务的日志三类主要的数据。根据存储数据种类的不同，副本有几种不同的类型，以支持不同业务在数据安全、性能伸缩性、可用性、成本等之间的选择。
如上图所示，图中共有三个 ZONE。如果三个 ZONE 不在同一个数据中心，建议将 leader 聚在同一个 ZONE，减少数据延时。如果三个 ZONE，只把机器分成了三组，在单机情况下，提供自动容灾，可以将其打散。
每台机器的蓝色节点，意味着每台机器都可以同时提供读写，防止资源浪费。为了防止机器宕机，三个 ZONE 一般在同一个数据中心。这就实现了租户间多活和租户内的多活。
四、OceanBase 分区特点
在逻辑层面，OceanBase 分区和 Oracle 是一致的。分区之后，做了大量优化，支持分区裁剪和分区感知 JOIN。如果分区个数过少，会导致资源不足，扩容复杂；当分区个数过多，可能会导致分布式查询过多，消耗资源。
OceanBase 的索引分成两种，即局部索引和全局索引。其中全局索引有一定的限制。用户需要注意局部前缀，局部非前缀和全局前缀。在索引分区，用户需注意是否和主表分区一致，OLTP 查询性能和大查询性能的影响。
上图是t1、t2两张表，每个表有 a、b 两列。当用户查询事例时，t1.a=t2.b。所以，用户可以以a列做分区，在b列添加一个索引，即局部的非前缀索引。这个局部非前缀索引，会导致查询比无分区的时候低效。这种情况可以使用全局索引改善。与此同时，在 OceanBase 优化器里，第六行的 BC2HOST，实际上做了一个小表广播。
表结构的设计步骤，如上图所示。首先，定义表结构。其次，考虑查询性能，读写性能。第三，确定分区方式，即一级分区或二级分区。然后，建立索引分区，将一组表变成表组。
对于一些支持分布式特性的数据库，负载均衡对用户完全透明。资源调度和负载均衡分为两层。多租户的资源可以看作很多虚拟容器，我们叫做 UNIT。每个机器上，有很多虚拟容器。每个 UNIT 属于一个租户使用。在当前版本中，没有限制租户的磁盘用量。
所以通过结合数据库本身的特性，充分利用了整个集群资源。在调度过程中，主要考虑两个因素。即 CPU 和内存。然后，按照 CPU 和内存都达到均衡的维度，在每个 zone 内做调度，使同租户的 UNIT 不重叠。
租户的负载均衡最终要实现读写负载均衡和磁盘使用率均衡。在同一个表组内，把各个分区捆绑在一起。以每个组为调度的基本单位。每个组以个数为单位做均衡。主要在 ZONE 和租户内进行调度。
二级分区以 hash 为维度，个数均衡为目标。在个数均衡的基础上，通过观察每个分区或副本的磁盘使用量。在不打破个数均衡的情况下，实现动态平衡。
弱一致性读主要用于 select 只读事物，不能保证读到最新提交的数据，但可以保证其原子性，支持读备副本和只读副本。其中，弱一致性支持指非单调的最终一致性和单调读的前缀一致性以及有界旧单调读。
只读事务的扩展性主要包括强一致性读的复制表，弱一致性读的只读副本。复制表的强同步，适合读多写少的小表，从而避免分布式查询。当事务提交时，等待所有副本回放完成。
弹性扩缩容分为垂直扩容，水平扩缩容和按需预扩缩容。垂直扩容可以在线替换节点，动态调整 UNIT 规格。水平扩缩容可以动态添加删除节点，动态调整租户 UNIT 数量，支持自动负载均衡。按需扩缩容能够快速可靠弹入弹出，主要用于大促、红包等资源短期扩容场景。
高并发、低时延的 OLTP 数据库，其性能指标主要考虑吞吐率和时延。如果查询涉及多个分区访问，时延的影响是不可忽略的。如果数据库的分布数据库不能控制数据所在分区，其性能会有一定损失。所以低时延，必须考虑本地化；可控制，必须实现分布式事务的比例可预期。
TPC-C 是国际最权威的 OLTP 评测。OceanBase 是第一个通过 TPC-C 的分布式数据库，也是第一个通过 TPC-C 的中国数据库。OceanBase 在稳态运行期间 tpmC 抖动小于1%，平均23分钟完成一次 checkpiont。
结语
分区和副本是 OceanBase 与众不同的最基本的概念，也是初学者需要掌握的主要概念。我们需要在设计相关特性时兼顾易用性与可控性，通过自动管理这两种对象，并提供给管理员灵活配置手段，OceanBase 能够具备极高的扩展性和高可用能力。本文围绕《OceanBase 数据库系统概念》的第4章——分布式数据库对象的内容，介绍了这些概念背后的原理，希望能对读者了解 OceanBase 起到一定的帮助。
最后的最后，如果你有任何问题都可以和我们联系。
联系我们
欢迎广大 OceanBase 爱好者、用户和客户随时与我们联系、反馈，方式如下：
社区版官网论坛
社区版项目网站提 Issue
