OceanBase流量分布

已于 2025-05-21 09:21:58 修改
阅读量720 收藏 6
点赞数 22
分类专栏： 数据库 # 关系型数据库 运维 文章标签： oceanbase java 开发语言
于 2025-05-21 09:20:38 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/NIIT0532/article/details/148103966
版权

在 OceanBase 数据库中，Leader 承担事务中的读写请求，因此每个分区 Leader 的分布决定了流量在每个节点上的分布。

流量介绍

数据库系统在应用架构中承担了数据存储和查询的功能，应用的读写请求称为数据库流量。数据库流量分为写流量、强一致读流量和弱一致读流量，写流量和强一致读流量由 OceanBase 数据库的 Leader 副本提供服务，弱一致读流量由 Leader 副本和 Follower 副本提供服务。ODP 提供了数据库流量的路由选择能力，ODP 实现了一个简单的 SQL Parser 模块，解析出 SQL 中的库名、表名及 hint，从而根据业务 SQL、路由规则、及 OBServer 节点的状态，选择最合适的一个 OBServer 节点转发请求。

Primary Zone 介绍

流量分布通过 Primary Zone 来描述，Primary Zone 描述了 Leader 副本的偏好位置，而 Leader 副本承载了业务的强一致读写流量，即 Primary Zone 决定了 OceanBase 数据库的流量分布。假设某张表 t1 的 primary_zone="Zone1"，则 RootService 会尽量将 t1 表的 Leader 调度到 Zone1 上来。

说明

副本描述的对象是数据，而 Primary Zone 描述的对象是承载数据的容器，从而该容器下的数据继承容器的 Primary Zone 属性所描述的 Leader 偏好位置。OceanBase 数据库当前版本仅支持租户级别的 Primary Zone，而 OceanBase 数据库 V3.x 还支持表级、DB级、Table Group 级别配置 Primary Zone。

Primary Zone 实际上是一个 Zone 的列表，列表中包含多个 Zone。该列表用如下方式为 Zone 配置优先级：

当 Primary Zone 列表包含多个 Zone 时，用 ';' 分隔的具有从高到低的优先级；用 ',' 分隔的具有相同优先级，表示流量打散在多个 Zone 上，这几个 Zone 同时提供服务。

例如：'hz1,hz2;sh1,sh2;sz1' 表示 hz1 和 hz2 具有相同的优先级，并且优先级高于 sh1/sh2 和 sz1；sh1 和 sh2 具有相同优先级，并且优先级高于 sz1。

OceanBase 数据库当前版本仅支持租户级别的 Primary Zone，不再支持表级、DB 级、Table Group 级配置 Primary Zone。如果创建租户时未指定 primary_zone，默认填写为 RANDOM，表示各个 Zone 优先级相同。

租户的 Primary Zone 属性可以通过系统租户下 oceanbase.DBA_OB_TENANTS 视图的 PRIMARY_ZONE 字段查看。示例如下：

obclient> SELECT * FROM oceanbase.DBA_OB_TENANTS limit 10;
+-----------+-------------+-------------+----------------------------+----------------------------+--------------+---------------+-------------------+--------------------+--------+---------------+--------+-------------+-------------------+------------------+---------------------+---------------------+---------------------+---------------------+--------------+----------------------------+
| TENANT_ID | TENANT_NAME | TENANT_TYPE | CREATE_TIME                | MODIFY_TIME                | PRIMARY_ZONE | LOCALITY      | PREVIOUS_LOCALITY | COMPATIBILITY_MODE | STATUS | IN_RECYCLEBIN | LOCKED | TENANT_ROLE | SWITCHOVER_STATUS | SWITCHOVER_EPOCH | SYNC_SCN            | REPLAYABLE_SCN      | READABLE_SCN        | RECOVERY_UNTIL_SCN  | LOG_MODE     | ARBITRATION_SERVICE_STATUS |
+-----------+-------------+-------------+----------------------------+----------------------------+--------------+---------------+-------------------+--------------------+--------+---------------+--------+-------------+-------------------+------------------+---------------------+---------------------+---------------------+---------------------+--------------+----------------------------+
|         1 | sys         | SYS         | 2023-05-17 18:10:19.940353 | 2023-05-17 18:10:19.940353 | RANDOM       | FULL{1}@zone1 | NULL              | MYSQL              | NORMAL | NO            | NO     | PRIMARY     | NORMAL            |                0 |                NULL |                NULL |                NULL |                NULL | NOARCHIVELOG | DISABLED                   |
|      1001 | META$1002   | META        | 2023-05-17 18:15:21.455549 | 2023-05-17 18:15:36.639479 | zone1        | FULL{1}@zone1 | NULL              | MYSQL              | NORMAL | NO            | NO     | PRIMARY     | NORMAL            |                0 |                NULL |                NULL |                NULL |                NULL | NOARCHIVELOG | DISABLED                   |
|      1002 | mysql001    | USER        | 2023-05-17 18:15:21.461276 | 2023-05-17 18:15:36.669988 | zone1        | FULL{1}@zone1 | NULL              | MYSQL              | NORMAL | NO            | NO     | PRIMARY     | NORMAL            |                0 | 1684398681521302749 | 1684398681521302749 | 1684398681345969089 | 4611686018427387903 | NOARCHIVELOG | DISABLED                   |
|      1003 | META$1004   | META        | 2023-05-17 18:18:19.927859 | 2023-05-17 18:18:36.443233 | zone1        | FULL{1}@zone1 | NULL              | MYSQL              | NORMAL | NO            | NO     | PRIMARY     | NORMAL            |                0 |                NULL |                NULL |                NULL |                NULL | NOARCHIVELOG | DISABLED                   |
|      1004 | oracle001   | USER        | 2023-05-17 18:18:19.928914 | 2023-05-17 18:18:36.471606 | zone1        | FULL{1}@zone1 | NULL              | ORACLE             | NORMAL | NO            | NO     | PRIMARY     | NORMAL            |                0 | 1684398681335427475 | 1684398681335427475 | 1684398681144712832 | 4611686018427387903 | NOARCHIVELOG | DISABLED                   |
|      1005 | META$1006   | META        | 2023-05-18 15:48:57.441320 | 2023-05-18 15:49:12.820051 | zone1        | FULL{1}@zone1 | NULL              | MYSQL              | NORMAL | NO            | NO     | PRIMARY     | NORMAL            |                0 |                NULL |                NULL |                NULL |                NULL | NOARCHIVELOG | DISABLED                   |
|      1006 | mq_t1       | USER        | 2023-05-18 15:48:57.447657 | 2023-05-18 15:49:12.857944 | zone1        | FULL{1}@zone1 | NULL              | MYSQL              | NORMAL | NO            | NO     | PRIMARY     | NORMAL            |                0 | 1684398680916392609 | 1684398680916392609 | 1684398680742451346 | 4611686018427387903 | NOARCHIVELOG | DISABLED                   |
+-----------+-------------+-------------+----------------------------+----------------------------+--------------+---------------+-------------------+--------------------+--------+---------------+--------+-------------+-------------------+------------------+---------------------+---------------------+---------------------+---------------------+--------------+----------------------------+
7 rows in set

Region 属性

在 OceanBase 数据库中，Zone 有一个 Region 属性（DBA_OB_ZONES 视图的 REGION 字段），表示该 Zone 所处的地区，每个 Zone 仅能配置一个 Region，但一个 Region 内可包含多个 Zone。Primary Zone 的设置隐含的包含了 Leader 偏好的 Region 位置。具体指用户设置 Primary Zone 时包含两层语义：

  • 被指定的 Primary Zone 为 Leader 的偏好 Zone 的 Region。

  • 被指定 Primary Zone 所在的 Region 为 Leader 偏好的 Region。

具体地，Leader 会被优先调度到最高优先级的 Zone 上去，如果最高优先级的 Zone 上的副本不能成为 Leader，会优先选择同一个 Region 内的其他 Zone 作为 Leader 的位置，从而保证业务访问 OceanBase 数据库尽量不跨城。

Primary Zone 改写

用户设置的 Primary Zone 会由 OceanBase 数据库基于各个 Zone 所在的 Region 进行改写，改写规则如下：

  1. 将用户设置的 Primary Zone 中的所有 Zone 对应的 Region 列出。例如：primary_zone 为 hz1,hz2;sh1,sh2;sz1 对应的 primary_region 的列表为 hz,hz;sh,sh;sz。

  2. 将 primary_region 中重复的 Region 去掉，去掉规则为保留第一个出现的 Region，其他 Region 后续重复的 Region 移除，例如 hz1,hz2;sh1,sh2;sz1，其 primary_region 转化为列表 hz;sh;sz。

  3. 依据 primary_region 中各 Region 的优先级，对 primary_zone 进行补充，补充规则如下：将 Primary Zone 中各 Region 对应的 Zone 都取出，重新排列，高优先级 Region 内 Zone 比低优先级 Region 内 Zone 的优先级高，同一 Region 内 Zone 的优先级高低参考原始 Primary Zone 中的优先级。

例如：假设共有 9 个 Zone，sh1、sh2、sh3 三个 Zone 在 Region SH，hz1、hz2、hz3 三个 Zone 在 Region HZ，sz1、sz2、sz3 三个 Zone 在 Region SZ。

  • 用户设置的 primary_zone 为 'sh1;hz1;hz2;sz1'；按照改写规则 1 得到 primary_region 为 'SH;HZ;HZ;SZ'。按照改写规则 2 得到 primary_region 为 'SH;HZ;SZ'。按规则 3 得到改写后 primary_zone 为 'sh1;sh2,sh3;hz1;hz2;hz3;sz1;sz2,sz3'。

    解释如下：

    三个 Region 的优先级为 SH > HZ > SZ。Region SH 中的 Zone 的优先级高于 Region HZ 和 Region SZ 中 Zone 的优先级。Region HZ 中的 Zone 的优先级高于 Region SZ 中 Zone 的优先级。各 Region 内每个 Zone 的优先级为：在 Region SH 中 sh1 > sh2 = sh3，在 Region HZ 中 hz1 > hz2 > hz3，在 Region SZ 中 sz1 > sz2 = sz3。因此最终得到新的 Primary Zone 为 'sh1;sh2,sh3;hz1;hz2;hz3;sz1;sz2,sz3'。Leader 会优先分布在 sh1 上，当 sh1 发生故障时，Leader 会依照上面的 Primary Zone 优先级依次分布在 sh2 和 sh3。

  • 用户设置的 primary_zone 为 'sh1,sh2;hz1;hz2;sz1'；按照改写规则 1 得到 primary_region 为 'SH,SH;HZ;HZ;SZ'。按照改写规则 2 得到 primary_region 为 'SH;HZ;SZ'。按规则 3 得到改写后 primary_zone 为 'sh1,sh2;sh3;hz1;hz2;hz3;sz1;sz2,sz3'。

    解释如下：

    三个 Region 的优先级为 SH > HZ > SZ。Region SH 中的 Zone 的优先级高于 Region HZ 和 Region SZ 中 Zone 的优先级。Region HZ 中的 Zone 的优先级高于 Region SZ 中 Zone 的优先级。各 Region 内每个 Zone的优先级为：在 Region SH 中 sh1 = sh2 > sh3，在 Region HZ 中 hz1 > hz2 > hz3，在 Region SZ 中 sz1 > sz2 = sz3。因此最终得到新的 Primary Zone 为 'sh1,sh2;sh3;hz1;hz2;hz3;sz1;sz2,sz3'。Leader 会优先平均分布在 sh1 和 sh2 上，当 sh1 和 sh2 发生故障时，Leader 会依照上面 Primary Zone 优先级依次分布在 sh3。

  • 用户设置的 primary_zone 为 'sh1,hz1;hz2;sz1'；按照改写规则 1 得到 primary_region 为 'SH,HZ;HZ;SZ'。按照改写规则 2 得到 primary_region 为 'SH,HZ;SZ'。按规则 3 得到改写后 primary_zone 为 'sh1,hz1;hz2;sh2,sh3,hz3;sz1;sz2,sz3'。

    解释如下：

    三个 Region 的优先级为 SH = HZ > SZ。Region SH 和 Region HZ 中的 Zone 的优先级高于 Region SZ 中 Zone 的优先级。sh1 = hz1 > hz2 > sh2 = sh3 = hz3 > sz1 > sz2 = sz3。因此最终得到新的 Primary Zone 为 'sh1,hz1;hz2;sh2,sh3,hz3;sz1;sz2,sz3'。Leader 会优先平均分布在 sh1 和 hz1 上，当 sh1 和 hz1 发生故障时，Leader 会依照上面 Primary Zone 优先级依次分布在 hz2。

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

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

Unit Group 介绍

OceanBase 数据库 V4.0 开始在租户管理上增加了限制，要求同一个租户所有 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 的服务能力对等。

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

sys 租户下，通过 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 绑定。

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

obclient> select TENANT_ID,LS_ID,STATUS,PRIMARY_ZONE,UNIT_GROUP_ID,LS_GROUP_ID from oceanbase.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 个日志流。如下图所示。

    1

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

OceanBase分布式关系数据库架构与技术
fzq0625的博客
06-02 319
否则，将更多流量分配给基线计划.单一类型资源的多机负载均衡比较容易，只需要计算单一资源的利用率，并通过资源单元的迁移达到每个节点上的资源均衡. 当系统中有多种资源需要进行分配和均衡时，仅使用其中一种资源的占用率去进行分配和均衡很难达到较好的分配和均衡效果，为此，在多种资源（CPU 、 内存）均衡和分配时，为每种资源分配一个权重，作为计算节点总的资源占用率时该资源所占的百分比. 而每种资源的权重，依赖于集群中该资源的总体使用率，即某种资源使用的越多，则该资源的权重就越高.
OceanBase详解
热门推荐
qq_22162093的博客
07-27 3万+
OceanBase是阿里开发的分布式关系型(SQL)数据库，其目标是支持数百TB的数据量以及数十万TPS、数百万QPS的访问量，无论是数据量还是访问量，即使采用非常昂贵的小型机甚至是大型机，单台关系数据库系统都无法承受。 案例：OceanBase分布式关系数据库渡过了一个成功的双十一：支持了支付宝核心的交易、支付、会员和账务等，并且创造了新的纪录：交易创建17.5万笔/秒、交易支付12万笔/秒、全天累计支付10.5亿笔 1、特性 1.1、高扩展性 传统关系型数据库，比如Oracle或者MySQL功能已经很完
OceanBase创建租户
zhuyu19911016520
01-24 3238
租户是集群之上的递进概念，OceanBase 数据库采用了多租户架构。集群偏部署层面的物理概念，是 Zone 和节点的集合，租户则偏向于资源层面的逻辑概念，是在物理节点上划分的资源单元，可以指定其资源规格，包括 CPU、内存、日志盘空间、IOPS 等。租户类似于传统数据库的数据库实例，租户通过资源池与资源关联，从而独占一定的资源配额，可以动态调整资源配额。在租户下可以创建 Database、表、用户等数据库对象。
OceanBase-概述
yxkong的专栏
12-07 4533
前段时间学习了下tidb的体系架构，了解了其运行原理；今儿了解下OceanBase；先看下官网：https://www.oceanbase.com/在OceanBase的产品分类里，一共有三大块，分布式数据库、工具体系、生态产品；（一个产品好不好用周边很关键）；介绍：兼容 MySQL 的单机分布式一体化数据库，具有原生分布式架构，支持金融级高可用、透明水平扩展、分布式事务、多租户和语法兼容等企业级特性。OceanBase 内核通过大规模商用场景的考验，已服务众多行业客户；面向未来携手社区生态伙伴，共建开源开
OceanBase租户管理：创建与删除
Sebastien23的博客
04-18 1134
OceanBase数据库中的（Tenant）可以类比为传统Oracle数据库的（Instance）。租户通过资源池与CPU、内存、磁盘空间、IO等物理资源关联。在租户下可以创建database、table、user等数据库对象。
OceanBase：OBServer节点管理
m0_37559973的博客
11-21 1670
ceanBase 数据库是单进程软件，进程名为 observer。通常一台物理或者虚拟服务器运行一个 observer 进程，由 IP 和端口作为唯一标识，称之为节点。
OceanBase 从架构到实战应用的技术探索
hello.reader
10-14 1588
OceanBase 是蚂蚁集团自主研发的一款分布式关系型数据库，专为应对金融级别的高并发、高可用性需求而设计。它不仅支持强一致性事务处理，还具备高扩展性，能够应对大规模的数据存储和高频率的查询请求。作为一款新型数据库，OceanBase 具有高容错性和稳定性，同时能够在多种复杂的业务场景中提供低延迟的数据访问服务。OceanBase 的核心架构采用了分布式设计，数据通过分片（Sharding）技术进行存储和管理。
OceanBase架构浅析_OceanBase分布式数据库
计算机毕业论文源码，学生个人网页制作html源码。贴近用户做网络推广和互联网优化。
10-19 1645
OceanBase简介,OceanBase是阿里集团研发的可扩展的关系数据库，实现了数千亿条记录、数百TB数据上的跨行跨表事务，截止到2012年8月，支持了收藏夹、直通车报表、天猫评价等OLTP和OLAP在线业务，线上数据量已经超过一千亿条。 　　从模块划分的角度看，OceanBase可以划分为四个模块：主控服务器RootServer、更新服务器UpdateServer、基线数据服务器ChunkServer以及合并服务器MergeServer。OceanBase系统内部按照时间线将数据划分为基线数据和
OceanBase租户管理
Made In SQL
05-20 751
OceanBase数据库采用多租户架构，适用于资源整合和SaaS服务等场景，降低了运维复杂度。租户是逻辑资源单元，通过资源池与物理资源关联，可动态调整资源配额。资源规格、资源单元（Unit）和资源池是理解租户的关键概念。Unit是资源调度的基本单位，具有节点、Zone、Region等位置属性。资源池由多个Unit组成，是资源分配的基本单位。租户容量可通过垂直扩缩容（调整Unit资源规格）和水平扩缩容（调整Unit个数和分布）动态调整。OceanBase V4.0引入Meta租户，管理用户租户的私有数据，提升
深入解析 OceanBase 4.3关键能力
OceanBase分布式数据库的博客
05-24 1861
OceanBase 4.3.1 Beta 版于 5 月 17 日发布。该版本带来了大量基础性 OLAP 能力的增强，其中包括用户期待已久的全文索引支持、物化视图增强支持实时物化视图和自动 SQL 改写、外表增强支持分区表分目录存储。
云数据库 OceanBase
HaoHao_010的博客
12-04 1347
OceanBase 是一款高性能、高可靠、可扩展的分布式关系型数据库，尤其适用于需要大规模数据处理和高并发访问的企业和行业，如金融、电商等。凭借其强大的分布式架构、事务支持和兼容性，OceanBase 为用户提供了高效、灵活、可靠的数据管理和存储解决方案。它不仅能够有效应对传统关系型数据库在大规模数据处理中的瓶颈，还能为企业提供高可用、弹性伸缩的数据库支持。
OceanBase 存储引擎详解
seeyousoonhhh的博客
03-18 2482
作者简介：沈炼，蚂蚁集团技术风险部数据库高级专家 毕业于东南大学，2014年以来从事 OceanBase 在蚂蚁的架构工作，目前职责包括蚂蚁 OceanBase 高可用体系建设 和 OceanBaseKV 在蚂蚁的架构及研发工作，对标业界的“自治数据库”和“多模型数据库”，致力于让 OceanBase 走得更稳、更远、更快。在蚂蚁 OceanBase 体系中，沈炼先后负责 蚂蚁核心链路上 OceanBase 、 OceanBase 高可用体系建设、 OceanBaseKV 架构及研发。沈炼对互联网金融场景
OceanBase官方文档阅读笔记（一）
cfuckfuck的博客
06-03 4822
什么是OceanBase? OceanBase 数据库是阿里巴巴和蚂蚁集团不基于任何开源产品，完全自研的原生分布式关系数据库软件，在普通硬件上实现金融级高可用，首创“三地五中心”城市级故障自动无损容灾新标准，具备卓越的水平扩展能力，全球首家通过 TPC-C 标准测试的分布式数据库，单集群规模超过 1500 节点。 产品具有云原生、强一致性、高度兼容 Oracle/MySQL 等特性， 承担支付宝 100% 核心链路，在国内几十家银行、保险公司等金融客户的核心系统中稳定运行。 TTPC（transact
TiDB、OceanBase、PolarDB-X、CockroachDB 二级索引写入性能测评
阿里云云栖号
09-02 2210
二级索引是关系型数据库相较于NoSQL数据库的一个关键差异。二级索引必须是强一致的，因此索引的写入需要与主键的写入放在一个事务当中，事务的性能是二级索引性能的基础。
OceanBase数据库-租户
weixin_50502586的博客
05-18 333
若想要统一管理，共用一套资源，则需要在数据库下创建多个用户，每个用户分配不同的权限，操作不同数据库表，但是，这也只是。，能够单独创建数据库、表等，租户之间的物理资源能够独立分配，实现了物理资源和逻辑资源的隔离。下，假如有多个系统，每个系统需要单独维护自己的数据库实例，无法统一运维管理。OceanBase有三种租户类型：系统租户、用户租户、Meta租户。租户可以等同于传统数据库的数据库实例，拥有自己的资源配置。描述用户租户的租户，存储和管理用户租户的私有数据。用户创建的租户，支持完整的数据库功能。
如何用 OceanBase 的 LOAD DATA 旁路导入进行大表迁移
OceanBase分布式数据库的博客
05-19 760
在日常工作中，我们时常会遇到需要将某个大数据量的单表进行迁移的情况。ceanBase针对此类需求引入了一项新功能——旁路导入。最新版本的OBdumper/OBloader工具已经能够支持旁路导入。本文将对LOAD DATA旁路导入进行解读。
如何处理 collation 导致的索引失效 | OceanBase SQL调优实践
最新发布
OceanBase分布式数据库的博客
05-20 631
本文结合用户的提问，介绍了如何处理 collation （字符排序规则或者叫比较规则）导致的索引失效
如何分析动态采样引起的计划不稳定 | OceanBase SQL 调优实践
OceanBase分布式数据库的博客
05-17 891
在OceanBase社区论坛中，用户提出了关于动态采样和DAS执行的问题。用户发现，在未收集统计信息时，出现执行计划不稳定。本文进行了相关的原因分析。
OceanBase 开发者大会：详解 Data × AI 战略，数据库一体化架构再升级
OceanBase分布式数据库的博客
05-19 1080
OceanBase 2025 开发者大会与5月17日在广州举行。会上，OceanBase CTO 杨传辉系统性地阐述了公司的 Data×AI 战略，并发布了三大产品：PowerRAG、共享存储，以及OceanBase桌面版。
oceanbase主备
03-25
### OceanBase 数据库的主备配置与同步机制 OceanBase 数据库通过多副本架构实现高可用性和数据一致性，其主备配置和同步机制基于 Paxos 协议来保障数据的安全性与可靠性。以下是关于 OceanBase 主备配置、同步机制以及部署方案的具体说明： #### 1. 多副本架构 OceanBase 使用分布式架构设计，在集群中每个分区组（Partition Group, PG）都会维护多个副本，通常至少有三个副本。这些副本分布在不同的服务器上，形成一个 Paxos 组合[^2]。 #### 2. 同步机制 OceanBase 的同步机制依赖于 Paxos 协议，该协议确保在分布式环境中达成一致共识。具体来说： - 当客户端发起写请求时，事务会被提交到 Leader 副本。 - Leader 将操作日志广播给 Follower 副本，并等待多数派确认后才返回成功响应。 - 这种方式被称为 **强同步复制**，能够有效防止单点故障并提供较高的数据安全性。 #### 3. 主备配置 为了进一步提升系统的可靠性和容灾能力，OceanBase 支持跨地域的数据中心级备份解决方案——即异地多活或多数据中心部署模式。在这种场景下： - 不同地区的机房之间可以通过异步或半同步的方式进行增量数据传输； - 如果源端发生灾难，则目标站点可以快速接管业务流量而无需长时间恢复过程[^4]。 #### 4. 部署方案 对于生产环境中的大规模应用需求而言，推荐采用三地五中心甚至更多数量节点组成的复杂拓扑结构来进行全方位防护。例如，“两地三中心”的典型布局如下所示： - 在同城设立两个高性能计算资源池作为主要工作单元； - 另外在一个较远距离的城市建立第三个低延迟互联线路连接起来的小规模冗余保护单位[^1]。 ```bash # 示例命令：创建租户时指定zone信息以支持多地部署 obclient -h$HOST -u$USER -p$PASSWORD \ -e "CREATE RESOURCE UNIT ru_test MIN_CPU 1 MAX_CPU 2 MEMORY_SIZE '2G'; CREATE TENANT t_test ZONE_LIST=('zone1','zone2','zone3') PRIMARY_ZONE='RANDOM' RESOURCE_UNIT=ru_test;" ```
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值