挂马网站 名单,seo点击器,企业网站开发语言,中国电信网站备案 流程OceanBase作为一款原生分布式数据库#xff0c;其核心的技术特性之一是高可扩展性#xff0c;其具体表现在两个方面#xff1a;
首先#xff0c;是灵活的扩缩容能力#xff0c;包括垂直扩缩容和水平扩缩容#xff1a;
垂直扩缩容#xff…OceanBase作为一款原生分布式数据库其核心的技术特性之一是高可扩展性其具体表现在两个方面
首先是灵活的扩缩容能力包括垂直扩缩容和水平扩缩容
垂直扩缩容指通过调整服务节点上的资源规格来改变服务能力的方法。举例来说当服务节点在CPU或内存资源上遭遇瓶颈时我们可以通过灵活地调整每个节点的CPU配置和内存大小迅速提升服务能力。水平扩缩容指通过增减服务节点的数量来实现服务能力的调整。例如从单个服务节点扩展为两个服务节点可以实现服务能力的扩容。然而只支持服务节点数量的变化是不够的为了实现业务读写服务能力的水平扩缩容还需要支持数据重分布比如从单个服务节点扩展为两个服务节点让数据均衡地分布在两个服务节点上。反之当两个服务节点缩容为单个服务节点时需要让数据重分布到单个服务节点上。
其次是数据动态均衡能力即在服务节点不变的情况下通过调整数据分布以实现各个服务节点负载动态均衡的能力。例如随着表和分区的动态创建和删除不同服务节点上服务的分区个数会有很大差异导致服务节点的负载不均衡基于分区动态均衡能力可以实现分区在各个服务节点上均衡分布从而实现负载均衡。
无论是水平扩缩容还是数据的动态均衡本质上都是通过调整数据的分布以实现服务节点的负载均衡。因此我们将水平扩缩容和数据动态均衡的能力统称为负载均衡能力。
OceanBase 各版本的负载均衡有何不同
OceanBase从1.x版本开始就具备灵活的扩展性支持以分区为单位将数据打散分布在多个服务节点上实现了动态扩缩容和分区自动均衡。 OceanBase 4.0版本升级为单机分布式一体化架构后引入了自适应日志流概念扩展性更加灵活支持单机和分布式形态的动态变换。目前OceanBase 4.0和OceanBase 4.1 的扩展能力还不够完善由于分区和日志流是静态的绑定关系不支持动态调整分区分布从而限制了自动负载均衡的能力不支持部署形态的灵活变换。
OceanBase 4.2版本是首个完整实现单机分布式一体化架构的版本具有里程碑意义。
OceanBase采用分区转移技术实现了日志流的分裂和合并支持了以分区为单位进行跨节点的数据搬迁完善了负载均衡策略补齐了可扩展性能力真正实现了单机和分布式形态的动态变换。
OceanBase支持多租户机制不同租户间资源隔离支持租户级别的水平扩缩容和分区均衡下面将详细介绍OceanBase 4.2版本租户级别的负载均衡特性。
OceanBase v4.2租户级别的负载均衡特性 水平扩缩容 OceanBase支持从两方面来描述租户的服务能力
Unit Number即每个Zone上提供服务的Unit个数。Primary Zone即提供读写服务的Zone列表。
用户通过动态调整Unit Number和Primary Zone可以实现租户的读写服务能力在Zone内和Zone间的水平扩缩容。负载均衡模块将根据用户服务能力的配置自适应调整日志流和分区分布。
用户可以通过下面的命令来调整租户的Primary Zone。
SQL ALTER TENANT tenant PRIMARY_ZONEzone1,zone2;zone3;
SQL ALTER TENANT tenant PRIMARY_ZONERANDOM;
当Primary Zone为RAMDOM时调整Locality参数也会导致Primary Zone的变化。例如Locality为从Fzone1,Fzone2,Fzone3变更为Fzone1,Fzone2,Rzone3时RANDOM的Primary Zone配置意味着Primary Zone从zone1,zone2,zone3变更为了zone1,zone2。
SQL ALTER TENANT tenant PRIMARY_ZONERANDOM;
SQL ALTER TENANT tenant LOCALITYFzone1,Fzone2,Rzone3;
用户可以通过下面的命令来调整租户每个Zone的Unit的个数4.0版本开始OceanBase要求每个Zone的Unit个数必须一样因此仅支持租户级别调整Unit个数的命令。为了方便统一管理各个Zone的Unit引入了Unit Group机制每个Zone相同编号的Unit属于同一个Unit Group。Unit个数的扩缩容本质上是以Unit Group为单位创建和删除Unit。
; 对于缩容场景随机选择一个Unit Group删除
SQL ALTER RESOURCE TENANT tenant_name UNIT_NUM xxx;; 对于缩容场景删除 指定的Unit Group
SQL ALTER RESOURCE TENANT tenant_name UNIT_NUM xxx DELETE UNIT_GROUP ( id_list )
相比之前的版本4.2版本新增支持了Unit缩容场景可以统一减少每个Zone的Unit个数。发起缩容操作后默认情况下系统会随机选择一个Unit Group执行删除用户也可以指定Unit Group列表删除特定的Unit集合。Unit Group的列表可以在 DBA_OB_UNITS 表中查询。
分区均衡
分区均衡指在表和分区动态变化的情况下通过动态调整分区分布实现分区个数以及存储空间在服务节点上的均衡。
OceanBase 支持多种表类型包括非分区表、一级分区表和二级分区表。不同类型的表的均衡策略不一样。为了方便描述均衡效果OceanBase为不同的表分区划分了均衡组在各个均衡组内要实现分区个数均衡和存储空间均衡。均衡组之间没有关系内部自适应调整均衡组之间的分布关系。默认情况下OceanBase的分区均衡策略如下。
一级分区表每个一级分区表是一个独立的均衡组表的所有一级分区打散分布在各个服务节点上。二级分区表每个一级分区下的所有二级分区形成一个独立的均衡组每个一级分区下的所有二级分区打散分布在各个服务节点上。非分区表所有的非分区表统一考虑有且只有一个均衡组所有的非分区表打散分布在各个服务节点上。
另外为了更加灵活描述不同表数据之间的聚集和打散关系引入了TableGroup机制。
TableGroup机制 用户手册OceanBase分布式数据库-海量数据 笔笔算数
OceanBase从1.x版本开始就引入了Table Group概念Table Group是一个逻辑对象代表一组表的集合他们在物理存储上有临近关系。Table Group的引入是为了解决Partition Wise Join需求。多张具有关联关系的表往往遵守相同的分区规则通过将相同规则的分区聚集分布在一起可以实现Partition Wise Join极大地优化读写性能。
从4.2版本开始TableGroup概念有较大调整。
首先不再支持Table Group上的分区属性不再通过分区属性限制一个Table Group的表的分区方式也不再支持Table Group相关的分区管理操作。
其次为了兼容老版本创建Table Group的语法带分区属性创建Table Group时并不会报错会忽略分区属性。在OceanBase 4.0和OceanBase 4.1中如果创建了带分区属性的Table Group升级到4.2版本后将默认转换为不带分区属性的Table Group行为上自动兼容。
再次视图也进行了调整DBA_OB_TABLEGROUPS的分区属性字段将不再有含义展示为NULLDBA_OB_TABLEGROUP_PARTITIONS/DBA_OB_TABLEGROUP_SUBPARTITIONS视图将废弃不再展示数据。CDB相关视图调整同上。
最后Table Group内分区的聚集和打散语义不再相同OceanBase 4.2版本为Table Group引入了SHARDING属性用于控制Table Group内表数据的聚集和打散关系。
那么什么是SHARDING属性在不同场景中它的取值和意义分表是什么
Table Group中SHARDING属性的取值
Table GroupSHARDING属性有三种取值NONE、PARTITION、ADAPTIVE。下面基于场景来描述OceanBase 4.2版本Table GroupSHARDING属性的取值和意义。
SHARDING属性的取值和意义
场景1Table Group内所有表聚集在一起。
用户希望将任意类型的表聚集在一台机器上以满足业务单机访问的需求。采用SHARDING NONE的Table Group可以实现将任意类型的表聚集在一起。
SHARDING NONE的Table Group含义如下
支持加入任意分区类型的表包括非分区表、一级分区表、二级分区表。加入Table Group的所有表的所有分区聚集在一起系统保证调度在一台机器上。
场景2Table Group内表数据水平打散。
当单机无法承载单个业务的数据时用户希望将数据打散分布在多台机器实现水平扩展。OceanBase默认为不同分区类型的表提供了水平扩展和自动负载均衡的能力。
非分区表所有的非分区表打散均匀分布在多台机器上。一级分区表表的所有一级分区打散分布在多台机器上。二级分区表每个一级分区的所有二级分区打散分布在多台机器上不同一级分区间随机打散。
默认情况下不同表之间数据是随机分布的但无妨。如果希望多张具有关联关系的表数据分布相同则需要明确不同表分区之间的对齐规则从而将不同表的分区聚集在同一台server实现Partition Wise Join提升性能。采用SHARDING不为NONE的Table Group可以满足该需求。
SHARDING NONE的Table Group描述了所有表的所有分区聚集在同一台server并且不限制表的分区类型。
SHARDING不为NONE时Table Group内每一张表的数据打散分布在多台机器上。为了保证所有表的数据分布相同Table Group要求所有表的分区方式一致包括分区类型、分区个数、分区Value。系统会调度具有相同分区属性的分区聚集对齐分布在同一台Server从而实现Partition Wise Join。
下面描述不同SHARDING取值的含义以及对Table Group内表的影响。
PARTITION按一级分区打散如果是二级分区表一级分区下的所有二级分区聚集在一起。 分区方式要求一级分区的分区方式相同如果是二级分区表也只校验一级分区的分区方式。因此一级分区表和二级分区表可以同时存在只要他们的一级分区的分区方式相同即可。分区对齐规则相同一级分区Value的分区聚集在一起包括一级分区表的一级分区和二级分区表的对应一级分区下的所有二级分区。ADAPTIVE自适应打散方式。如果Table Group内是一级分区表则按一级分区打散如果Table Group内是二级分区表则每个一级分区下的二级分区打散。 分区方式要求要么全部是一级分区表要么全部是二级分区表。如果是一级分区表则要求一级分区的分区方式相同如果是二级分区表则要求一级和二级分区方式都相同。分区对齐规则对于一级分区表一级分区Value相同的分区聚集在一起对于二级分区表一级分区Value相同并且二级分区Value相同的分区聚集在一起。
了解了SHARDING属性的取值和意义后我们以具体示例来看如何使用。
SHARDING属性的取值示例
示例一SHARDING NONE。
SHARDING NONE的Table Group内无论何种分区方式的表的分区都会聚集为一个Partition Group分布在一台机器上。 SQL CREATE TABLEGROUP TG1 SHARDING NONE;# 非分区表
SQL CREATE TABLE T_NONPART (pk int primary key) tablegroup TG1;# 一级分区表
SQL CREATE TABLE T_PART_2 (pk int primary key) tablegroup TG1 partition by hash(pk) partitions 2;# 二级分区表
SQL CREATE TABLE T_SUBPART_2_2 (pk int, c1 int, primary key(pk, c1)) tablegroup TG1 partition by hash(pk) subpartition by hash(c1) subpartitions 2 partitions 2; TablePartition Group0T_NONPARTP0T_PART_2P0, P1T_SUBPART_2_2P0SP0, P0SP1, P1SP0, P1SP1 示例二SHARDING PARTITION。
SHARDING PARTITION的Table Group里所有表都会看成是一级分区表要求所有表的一级分区方式相同而一级分区属性相同的分区会聚集成一个Partition Group。
SQL CREATE TABLEGROUP TG1 SHARDING PARTITION;# 一级分区表
SQL CREATE TABLE T_PART_2 (pk int primary key) tablegroup TG1 partition by hash(pk) partitions 2;# 二级分区表
SQL CREATE TABLE T_SUBPART_2_2 (pk int, c1 int, primary key(pk, c1)) tablegroup TG1 partition by hash(pk) subpartition by hash(c1) subpartitions 2 partitions 2; TablePartition Group01T_PART_2P0P1T_SUBPART_2_2P0SP0, P0SP1P1SP0, P1SP1 示例三SHARDING ADAPTIVE
Table Group要求所有表的一级和二级分区方式完全一致。一级分区表和二级分区表不支持在一个Table Group中。
一级分区表的Table Group
SQL CREATE TABLEGROUP TG_PART SHARDING ADAPTIVE;# 一级分区表
SQL CREATE TABLE T1_PART_2 (pk int primary key) tablegroup TG_PART partition by hash(pk) partitions 2;# 一级分区表
SQL CREATE TABLE T2_PART_2 (pk int primary key, c1 int) tablegroup TG_PART partition by hash(pk) partitions 2; TablePartition Group01T1_PART_2P0P1T2_PART_2P0P1 二级分区表的Table Group
SQL CREATE TABLEGROUP TG_SUBPART SHARDING ADAPTIVE;# 二级分区表
SQL CREATE TABLE T1_SUBPART_2_2 (pk int, c1 int, primary key(pk, c1)) tablegroup TG_SUBPART partition by hash(pk) subpartition by hash(c1) subpartitions 2 partitions 2;# 二级分区表
SQL CREATE TABLE T2_SUBPART_2_2 (pk int, c1 int, c2 int, primary key(pk, c1)) tablegroup TG_SUBPART partition by hash(pk) subpartition by hash(c1) subpartitions 2 partitions 2; TablePartition Group00011011T1_SUBPART_2_2P0SP0P0SP1P1SP0P1SP1T2_SUBPART_3_3P0SP0P0SP1P1SP0P1SP1 相关视图 视图名称说明DBA/CDB_OB_TABLE_LOCATIONS分区副本分布包含分区详细信息。最常用的视图之一DBA/CDB_OB_LS_LOCATIONS日志流副本分布DBA/CDB_OB_BALANCE_JOBS正在执行的负载均衡任务如扩容、缩容、分区均衡等DBA/CDB_OB_BALANCE_JOBS_HISTORY负载均衡任务历史DBA/CDB_OB_BALANCE_TASKS正在执行的LS均衡任务如LS分裂、LS合并等DBA/CDB_OB_BALANCE_TASK_HISTORYLS均衡任务历史DBA/CDB_OB_TRANSFER_TASKS正在执行的分区转移transfer任务tablet级别DBA/CDB_OB_TRANSFER_TASK_HISTORY分区转移transfer任务历史GV$OB_UNITSunit分布及资源使用情况GV$OB_SERVERSserver分布及资源使用情况
负载均衡配置参数enable_rebalance 在上述负载均衡过程中涉及一个控制参数enable_rebalance该参数在OceanBase 4.2前的版本用于控制租户间的均衡是否开启。为了支持控制租户内的均衡我们决定将enable_rebalance配置项变更为租户级别不同租户下的配置项控制不同的均衡操作。
1. 在系统租户下控制是否做租户间均衡。
false不会进行后台的unit迁移操作但是在机器永久下线或者处于DELETING状态时unit迁移不受配置项控制。true机器可以通过unit迁移达到均衡态。 2. 在用户租户下控制是否做租户下的均衡。
false租户内不在进行负载均衡操作已经在进行中的均衡操作会取消。用户如果发起扩缩容操作时会报错例如 租户的Unit Number增大缩小。第一优先级的Primary Zone发生变化如果第一优先级的Primary Zone不发生变化则不会报错。Primary Zone为RANDOM的情况下F副本个数发生变化。true 租户内可以执行负载均衡操作如下。
# 均衡都关闭
alter system set enable_rebalance false tenant ALL;#只开启租户间均衡
alter system set enable_rebalance true tenantsys;#关闭租户间均衡但是可以进行租户内均衡
alter system set enable_rebalance false tenantsys;
alter system set enable_rebalance true tenantmysql_tenant; 总结
OceanBase 4.2版本的分区转移功能支持了以分区为单位灵活的跨节点搬迁数据的能力弥补了因OceanBase 4.0版本架构升级而引入的问题即无法在日志流间负载均衡的缺陷真正实现了单机分布式一体化的灵活转化。
分区转移的源端日志流会有数秒卡DDL和用户写入后续会优化为支持用户写入。 如果分区转移有跨节点的负载均衡任务那么耗时和分区个数和数据量正相关。 需要转移的分区个数越多转移的速度就越慢需要转移的数据量越大跨节点拷贝的速度也会越慢主要受限于磁盘、网络的带宽瓶颈网络限速默认参数为实际带宽的60%。
需要说明的是OceanBase 4.2版本的分区转移不支持活跃事务预计在4.3版本实现支持。但是提供了两种模式以满足不同使用的场景。
第一种模式是非紧急状态下的负载均衡默认配置下分区转移操作在业务低峰期没有活跃事务的时候执行。此操作对于业务是基本无感知的。
第二种模式是紧急运维负载均衡需要用户手动开启分区转移主动杀事务的配置分区转移会主动“杀死”对应日志流上的活跃事务保证分区转移的顺利进行但会对业务运行有一定影响。
另外分区转移期间禁止部分DDL操作如删除分区/Truncate分区、/删除表/Truncate表分区分裂、合并添加、删除局部索引以及第一次添加LOB列都会引发阻塞。
