数据分布

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

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

同构 Zone 和异构 Zone 模式

OceanBase 数据库 V4.x 之前版本（不包含 V4.2.5 版本中，V4.2.5 BP5 版本及其之后的 BP 版本、V4.4.2 及其之后的版本）在租户管理上增加了限制，要求同一个租户所有 Zone 的 Unit 个数相同，即同构 Zone 模式。

在当前版本中，放开限制，不再要求同一个租户所有 Zone 的 Unit 个数必须相同，即支持租户的异构 Zone 模式。

相较于同构 Zone 模式，异构 Zone 模式在使用上主要有以下区别：

• 日志流分布不再与 Unit Group 绑定，各 Zone 的副本不再需要限制在对称的 Unit 上。均衡算法按照 Unit 的粒度控制各日志流的分布：

  • 在租户各 Zone 内，每个 Unit 上的日志流个数相等（不同 Zone 间，Unit 上的日志流个数可能不相同）。

  • UNIT_NUM 相同的 Zone 内，其日志流以同构方式聚合。

• 租户下各资源池的 UNIT_NUM 可以不同，但是最多只能有两种不同的 UNIT_NUM。

• 支持使用 ALTER RESOURCE POOL 语句单独修改租户下某一个资源池的 UNIT_NUM，以实现资源池粒度的扩缩容。

• 使用 ALTER RESOURCE TENANT 语句通过减少 UNIT_NUM 进行缩容时，不支持指定 UNIT_GROUP 进行删除。

• 使用日志流运维命令 ALTER SYSTEM CREATE LS 和 ALTER SYSTEM MODIFY LS 时，不支持指定 UNIT_GROUP 参数。

Unit Group 介绍

租户的同构 Zone 模式中，要求同一个租户所有 Zone 的 Unit 个数相同。系统为每个 Zone 的 Unit 进行了编号，不同 Zone 之间相同编号（UNIT_GROUP_ID）的 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 的服务能力对等。

• 不支持按 Zone 个性化配置租户的 Unit 个数，只能按照 Unit Group 维度整体调整，比如需要为租户水平扩容资源，调大 Unit 个数，只能所有 Zone 统一扩容；相应的，租户缩容的场景，只能按 Unit Group 整体删除 Unit。通过 Unit Group 机制，保证了不同 Zone 上的数据分布是同构的。

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

obclient(root@sys)[oceanbase]> SELECT UNIT_ID, TENANT_ID, UNIT_GROUP_ID, ZONE, SVR_IP, SVR_PORT FROM oceanbase.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_LIST 内只需要创建单个日志流即可。当 Primary Zone 为多个 Zone 时，租户的 UNIT_LIST 内需要创建多个日志流来实现服务能力水平扩展。这些日志流具有相同的分布属性，他们共同组成一个日志流组，日志流组内的日志流个数等于 Primary Zone 的 Zone 个数。

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

日志流组内的日志流个数随着租户 Primary Zone 配置的变化而动态变化。

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

obclient(root@sys)[oceanbase]> SELECT TENANT_ID, LS_ID, STATUS, PRIMARY_ZONE, LS_GROUP_ID, UNIT_LIST FROM oceanbase.CDB_OB_LS where TENANT_ID=1004;

查询结果如下：

+-----------+-------+--------+--------------+-------------+-----------+
| TENANT_ID | LS_ID | STATUS | PRIMARY_ZONE | LS_GROUP_ID | UNIT_LIST |
+-----------+-------+--------+--------------+-------------+-----------+
|      1004 |     1 | NORMAL | z1;z2        |           0 |           |
|      1004 |  1001 | NORMAL | z1;z2        |        1001 | 1013,1014 |
|      1004 |  1008 | NORMAL | z1;z2        |        1007 | 1025,1026 |
|      1004 |  1013 | NORMAL | z2;z1        |        1001 | 1013,1014 |
|      1004 |  1014 | NORMAL | z2;z1        |        1007 | 1025,1026 |
+-----------+-------+--------+--------------+-------------+-----------+
5 rows in set

总结

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

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

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

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

• 租户支持同构 Zone 模式和异构 Zone 模式。

  • 同构 Zone 模式下：

    • 系统为每个 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 个日志流。如下图所示。

      

  • 异构 Zone 模式下：

    • 系统按照 Unit 的粒度控制各日志流的分布。在租户各 Zone 内，每个 Unit 上的日志流个数相等（不同 Zone 间，Unit 上的日志流个数可能不相同）。

    • 日志流组内所有日志流分布在对应的 UNIT_LIST 上，日志流 Leader 打散在 Primary Zone 上。

      如下图所示，假设租户有 2 个 Zone，配置为 unit_num =1 和 unit_num =2，且 primary_zone ='zone1'，在均衡状态下，用户日志流总数为 2。其中 LS1 的 UNIT_LIST 为 (UNIT1, UNIT2)，LS2 的 UNIT_LIST 为 (UNIT1, UNIT3)。

      从图中可知，LS1 和 LS2 在 zone1 内是分布在同一 Unit 上，而在 zone2 内却分布在不同的 Unit，可见，异构 Zone 下，日志流在各个 Zone 内的副本的分布聚合方式是可以不同的。

      

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