OceanBase 架构原理深入
OceanBase 架构原理深入
整体架构全景
一、Paxos 协议与选主流程
每个分区的三个副本构成一个Paxos 组：
分区 P0 的 Paxos 组： Zone1: OBServer-A ← Leader（处理读写） Zone2: OBServer-B ← Follower Zone3: OBServer-C ← Follower写入流程（强一致）
[!tip] 与 Oracle 对比
类似Data Guard 最大保护模式，但不需要所有备库确认，只需多数派（2/3）确认即可提交。
选主流程（Leader 故障时）
[!important] 高可用指标
- RTO < 30秒（故障切换时间）
- RPO = 0（零数据丢失）
二、LSM-Tree 存储引擎
数据完整生命周期
读取流程
[!note] 性能特点
- 写性能极好：顺序追加写，避免随机 IO
- 读性能：依赖合并和缓存来优化，冷数据读取需合并多层
与 Oracle 对比
| 对比项 | Oracle | OceanBase |
|---|---|---|
| 存储结构 | B+Tree | LSM-Tree |
| 写入方式 | 随机写（in-place update） | 顺序追加写 |
| 写性能 | 受随机 IO 限制 | 写放大小，吞吐高 |
| 类比操作 | 表碎片整理 + 统计信息收集 | 每日合并（Major Compaction） |
每日合并管理
-- 手动触发合并（sys 租户下执行）ALTERSYSTEM MAJOR FREEZE;-- 查看合并进度SELECT*FROMoceanbase.CDB_OB_MAJOR_COMPACTION;-- 设置合并时间窗口（凌晨2点开始）ALTERSYSTEMSETmajor_freeze_duty_time='02:00';[!warning] 注意
合并期间 IO 压力较大，建议设置在业务低峰期执行。
三、分布式事务（2PC + Paxos）
单分区事务（最常见，最快）
SQL 只涉及一个分区 → 直接在该分区 Leader 上执行 → 通过 Paxos 同步给 Follower → 提交无需跨节点协调，性能接近单机数据库。
跨分区事务
[!tip] 核心优势
相比 MySQL 分库分表，OceanBase原生支持分布式事务，对应用完全透明，无需业务层处理分布式事务逻辑。
四、SQL 执行完整流程
分区裁剪（Partition Pruning）
[!tip] 与 Oracle 对比
与 Oracle 分区表的 Partition Pruning 原理完全一致。
-- 表按 user_id 哈希分区-- ✅ 可裁剪到单个分区，性能最好SELECT*FROMordersWHEREuser_id=12345;-- ❌ 无法裁剪，扫描所有分区，性能差SELECT*FROMordersWHEREorder_date='2024-01-01';