数据分布

数据分区是基于建表语句创建的逻辑对象，是划分和管理表数据的一种机制。每个租户由若干个 Unit 组成，日志流根据一定的规则分布于这些 Unit 上，从而决定了归属于日志流的数据分区在 Unit 上的分布。本小节介绍数据及其流量的分布规则。

OceanBase 数据库支持普通表和分区表。分区表又分为一级分区表和二级分区表，分区表由一个或多个分区组成。普通表由一个分区组成，可以看做分区表的特例。OceanBase 数据库的基本分区策略包括范围（Range）分区、列表（List）分区、哈希（Hash）分区、Key 分区等。

Unit Group 介绍

OceanBase 数据库 V4.0 开始在租户管理上增加了限制，要求同一个租户所有 Zone 的 Unit 个数相同。系统为每个 Zone 的 Unit 进行了编号，相同编号的 Unit 组成一个 Unit Group。Unit Group 具有以下特性：

• 每个 Unit Group 分配唯一 ID，通过 oceanbase.DBA_OB_UNITS 视图的 UNIT_GROUP_ID 字段可以查看该 ID。
• 一个日志流只属于一个 Unit Group，并且只分布于该 Unit Group 的 Unit 上。因此 Unit Group 内所有 Unit 以日志流为单位，分布了相同的数据分区，从而框定了一组数据。同时，也就要求每个 Zone 的服务能力对等。
• OceanBase 数据库 V4.0 开始不再支持按 Zone 个性化配置租户的 Unit 个数，只能按照 Unit Group 维度整体调整，比如需要为租户水平扩容资源，调大 Unit 个数，只能所有 Zone 统一扩容；相应的，租户缩容的场景，只能按 Unit Group 整体删除 Unit。通过 Unit Group 机制，保证了不同 Zone 上的数据分布是同构的。

通过 oceanbase.DBA_OB_UNITS 视图可以查询所有的 Unit，及其所归属的 Unit Group。例如：

obclient> select UNIT_ID,TENANT_ID,UNIT_GROUP_ID,ZONE,SVR_IP,SVR_PORT from DBA_OB_UNITS where TENANT_ID = 1004;
+---------+-----------+---------------+--------------+-------------+----------+
| UNIT_ID | TENANT_ID | UNIT_GROUP_ID | ZONE         | SVR_IP      | SVR_PORT |
+---------+-----------+---------------+--------------+-------------+----------+
|    1004 |      1004 |          1003 | sa128_obv4_1 | xx.xx.xx.47 |     2882 |
|    1005 |      1004 |          1003 | sa128_obv4_2 | xx.xx.xx.81 |     2882 |
|    1006 |      1004 |          1003 | sa128_obv4_3 | xx.xx.xx.19 |     2882 |
+---------+-----------+---------------+--------------+-------------+----------+
3 rows in set

日志流组介绍

日志流组的概念是为了适配 Primary Zone 打散在多个 Zone 上而引入的。当 Primary Zone 为单个 Zone 时，Unit Group 内只需要创建单个日志流即可。当 Primary Zone 为多个 Zone 时，Unit Group 内需要创建多个日志流来实现服务能力水平扩展。这些日志流具有相同的分布属性，他们共同组成一个日志流组，日志流组内的日志流个数等于 Primary Zone 的 Zone 个数。

因此，一个日志流属于一个日志流组，不可更改；日志流组与 Unit Group 一一对应；日志流组内所有日志流分布在对应的 Unit Group 上，日志流 Leader 打散在 Primary Zone 上。

日志流组内的日志流个数随着租户 Primary Zone 配置的变化而动态变化，日志流组生命期与 Unit Group 绑定。

通过 oceanbase.CDB_OB_LS 视图可以查看集群所有租户的日志流，及其所归属的日志流组。例如：

obclient> select TENANT_ID,LS_ID,STATUS,PRIMARY_ZONE,UNIT_GROUP_ID,LS_GROUP_ID from CDB_OB_LS where TENANT_ID=1004;
+-----------+-------+--------+----------------------------------------+---------------+-------------+
| TENANT_ID | LS_ID | STATUS | PRIMARY_ZONE                           | UNIT_GROUP_ID | LS_GROUP_ID |
+-----------+-------+--------+----------------------------------------+---------------+-------------+
|      1004 |     1 | NORMAL | sa128_obv4_1;sa128_obv4_2,sa128_obv4_3 |             0 |           0 |
|      1004 |  1001 | NORMAL | sa128_obv4_1;sa128_obv4_2,sa128_obv4_3 |          1003 |        1001 |
+-----------+-------+--------+----------------------------------------+---------------+-------------+
2 rows in set

总结

综上所述，对本节介绍的众多细粒度概念做一总结：

• Unit 是物理资源的抽象，每个 Unit 占据节点上一定的物理资源，包括 CPU、内存、存储空间等资源项。Unit 是资源调度的基本单位，可以调整 Unit 在同一个 Zone 内不同节点的分布，从而达到节点负载均衡和节点容灾的目的。

• 每个租户由若干 Unit 组成，通过设置租户的 Unit Number 和 Primary Zone，定义了一组承载业务流量的 Unit 集合，其个数为两者个数之乘积。每个 Unit 放置于一个节点上，从而可以方便的实现租户容量的水平扩展。

• 日志流框定了一组数据，包括若干数据分区和有序的 RedoLog 日志流。通过 Paxos 协议实现了多副本日志同步，保证副本间数据的一致性，从而实现了数据的高可用。日志流也是事务的提交单位，事务修改在单个日志流内完成时可以采用一阶段原子提交；事务修改跨多个日志流时，采用 OceanBase 数据库优化的两阶段提交协议完成原子提交，日志流是分布式事务的参与者。日志流具有位置属性和角色属性，日志流内所有数据分区继承其属性。

• 系统为每个 Zone 的 Unit 进行编号，相同编号的 Unit 组成一个 Unit Group。Unit Group 框定了一组日志流，这些日志流只分布于该 Unit Group 的 Unit 上。

• 日志流组与 Unit Group 一一对应，在每个日志流组中，日志流的个数由 Primary Zone 的 Zone 个数决定。从而 Primary Zone 的 Zone 列表中的每个 Zone 都可以分布着日志流组中一个日志流的 Leader。

  假设租户配置为 unit_num =2，primary_zone ='Z1,Z2,Z3'，则该租户定义了 2 个 Unit Group、2 个 日志流组和 6 个日志流。如下图所示。
  

OceanBase 数据库从多个层面将数据和流量灵活分布于多个节点上，Unit 可以在 Zone 内节点之间迁移以实现节点负载均衡和节点容灾。