OceanBase 的分布式数据库对象
摘要：本文整理自OceanBase 首席架构师杨志丰，在OceanBase读书会的分享。
本篇内容主要分为五个部分：
1.OceanBase数据库概览
2.数据库系统的可扩展性
3.OceanBase分布式数据库对象
4.OceanBase分区特点
5.社区用户问答
一、OceanBase数据库概览
《OceanBase数据库系统概念》的受众主要包括使用 OceanBase 的应用开发者、DBA、应用架构师、OceanBase 社区版开发者等广泛人群。这本书将系统地、详细地讲解 OceanBase 的概念和原理。希望成为大家学习和使用 OceanBase 的权威参考。
OceanBase具备基于原生分布式的水平扩展能力。采用基于无共享集群的分布式架构，通过 Paxos 共识协议实现数据多副本的一致性。整个系统没有任何单点故障，保证系统的持续可用。可扩展性和高可用性是其最大的优势。
二、数据库系统的可扩展性
系统的可扩展性是指，当应用对系统处理量的需求变化时，系统在性能和成本等方面随之增加和降低的能力。OceanBase不但是一套非常高效的分布式事务引擎，而且兼顾了单机事物的性能。
通过水平扩展和垂直扩展的并发能力，增加了OceanBase的扩展性。
OceanBase通过分片的方式，扩展其存储能力。当一个节点宕机或者数据丢失，还可以继续提供服务。实现了多副本、复制表与读写分离，增强了OceanBase的可靠性。
如上图所示，左边是单机Oracle，右边是Oracle RAC集群。Oracle RAC集群的特点是共享存储。集群内部有多个数据库节点，节点之间会共享RAC存储。
与此同时，所有数据库节点之间，有一个内部的私有网络。节点和节点之间，可以快速进行数据交换。在小规模的数据存储时，这个架构有非常好的扩展性，且每个节点支持数据库的读写服务。
Aurora的存储做了扩展，在Replica节点，实现了一写多读。它的兼容性较好，在一定程度上可以解决中等规模的存储的要求，但不支持高并发写入。所以业界一般认为Aurora不是一个分布式数据库。
在OceanBase0.5时，其架构主要是上下两层。上层的MergeServer接收SQL请求，是无状态服务。为了优化吞吐率，可以做横向扩展。在存储方面，有两种节点组成，即ChunkServer和UpdateServer。
ChunkServer可以自动分裂，水平扩展存储。UpdateServer无分布式事务，其Paxos支持强一致的高可用。
TiDB的架构主要分为两层。在Server层，其本身是无状态的。在分布式的Tikv层，Region支持自动分裂，Muti-raft负责复制，优化了其吞吐率。
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给一个租户使用。在当前版本中，没有限制租户的磁盘用量。
所以通过结合数据库本身的特性，充分利用了整个集群资源。在调度过程中，主要考虑两个因素。即CPU和内存。然后，按照CPU和内存都达到均衡的维度，在每个zone内做调度，使同租户的UNIT不重叠。
租户的负载均衡最终要实现读写负载均衡和磁盘使用率均衡。在同一个表组内，把各个分区捆绑在一起。以每个组为调度的基本单位。每个组以个数为单位做均衡。主要在ZONE和租户内进行调度。
二级分区以hash为维度，个数均衡为目标。在个数均衡的基础上，通过观察每个分区或副本的磁盘使用量。在不打破个数均衡的情况下，实现动态平衡。
强一致性读主要用于select只读事物，不能保证读到最新一提交的数据，但可以保证其原子性，支持读备副本和只读副本。其中，弱一致性是指非单调的最终一致性和单调独的前缀一致性以及有界旧单调度。
只读事务的扩展性主要包括强一致性读的复制表，弱一致性读的只读副本。复制表的强同步，适合读多写少的小表，从而避免分布式查询。当事务提交时，等待所有副本回放完成。
弹性扩缩容分为垂直扩容，水平扩缩容和按需预扩缩容。垂直扩容可以在线替换节点，动态调整UNIT规格。水平扩缩容可以动态添加删除节点，动态调整租户UNIT数量，支持自动负载均衡。按需扩缩容能够快速可靠弹入弹出，主要用于大促、红包等资源短期扩容场景。
高并发、低时延的OLTP数据库，其性能指标主要考虑吞吐率和时延。如果查询涉及多个分区访问，时延的影响是不可忽略的。如果数据库的分布数据库不能控制数据所在分区，其性能会有一定损失。所以低时延，必须考虑本地化；可控制，必须实现分布式事务的比例可预期。
TPC-C是国际最权威的OLTP评测。OceanBase是第一个通过TPC-C的分布式数据库，也是第一个通过TPC-C的中国数据库。OceanBase在稳态运行期间tpmC抖动小于1%，平均23分钟完成一次checkpiont。
五、社区用户问答
Q：分片和复制功能类似吗？
A：分片和复制是两个维度。分片是把数据做分制。第一行数据在第一个分片，第二行数据在第二个分片，以此类推。分片和复制在数据一致性的表现，是不一样的。
Q：总的分区具体加多少？10%或者20%？
A：分区加多少，取决于未来业务的发展。分区要保证有足够的空间，应对未来的业务增长。每一个物理的分区不要超过100G。
Q：索引和主键有什么区别？
A：OB的表结构叫索引组织表，主表以主件为维度做排序。所以主件确定之后，是很难变更的。
Q：OB建索引是不是很慢？
A：OceanBase建索引的速度，取决于数据量。建索引的过程对业务没有任何影响。
