一篇搞懂 OceanBase 的技术内核
之前的文章我们介绍了 OceanBase 的基本概念。这篇我们深入几个核心技术点，看看它到底"厉害"在哪里。
LSM-Tree：写性能的秘密武器
传统数据库大多使用 B+Tree 作为存储结构，B+Tree 读性能好，但每次写入都可能触发页面分裂，写放大严重。
OceanBase 选择了 LSM-Tree（Log-Structured Merge-Tree）。它的思路是：
- 写入时：数据先追加到内存中的 MemTable（类似一个有序缓冲区），写一条日志（Redo Log），就返回成功。写入极快。
- 后台合并（Compaction）：当 MemTable 写满后，OceanBase 会将它冻结并刷到磁盘，形成一个 SSTable（不可变的有序文件）。后台定期将多个小的 SSTable 合并成大的，同时清理过期数据。
- 读取时：先查 MemTable，再按从新到旧的顺序查 SSTable，用 Bloom Filter 加速跳过不相关的文件。
这种架构让 OceanBase 的写入吞吐量远高于传统 B+Tree 数据库，特别适合高并发写入场景。
增量数据与基线数据
OceanBase 把数据分为两层：
- 增量数据（MemTable + 最近的转储文件）：最新修改的数据，体积小，访问频繁。
- 基线数据（Major SSTable）：经过每日合并（Daily Major Compaction）后的完整数据集，体积大但结构规整。
每日合并是 OceanBase 的一个特色机制：每天凌晨，系统会把所有增量数据与基线数据做一次完整合并，生成新的基线。这既控制了增量数据的膨胀，也让全局查询性能保持稳定。
HTAP：一套引擎同时搞定交易和分析
HTAP（Hybrid Transactional/Analytical Processing）是近年数据库领域的热门方向。传统做法是交易用一套数据库（如 MySQL），分析用另一套（如 ClickHouse），中间靠 ETL 同步数据，延迟高、链路复杂。
OceanBase 的 HTAP 能力体现在：
- 行存 + 列存：同一份数据可以同时以行存（适合点查和交易）和列存（适合聚合分析）两种格式存储。优化器根据查询类型自动选择最优路径。
- 资源隔离：分析查询可以路由到专门的只读副本，不抢占交易负载的 CPU 和 IO。
- 一份数据，零 ETL：不需要额外的数据同步链路，实时分析直接查同一套集群。
容灾架构："三地五中心"
OceanBase 最具话题性的能力之一是支持城市级容灾。
它的多副本机制基于 Paxos 协议，可以灵活部署为多种架构：
|-------|--------------|-------------|
| 架构 | 说明 | 容灾能力 |
| 同城三机房 | 同一城市三个机房，三副本 | 任一机房故障自动切换 |
| 三地五中心 | 三个城市五个机房，五副本 | 任一城市故障自动切换 |
| 两地三中心 | 两个城市三个机房 | 主城市双机房+异地灾备 |
"三地五中心"是金融行业常用的最高等级容灾方案。即使一个城市整体不可用（自然灾害、大面积断电等），OceanBase 也能在剩余节点中自动选出新主，继续提供服务，且数据不丢不错。
分布式事务：两阶段提交 + 一阶段优化
分布式数据库绕不开分布式事务。OceanBase 的做法是：
- 标准两阶段提交（2PC）：跨分区事务先 Prepare，再 Commit，保证原子性。
- 一阶段提交优化：如果事务只涉及一个分区（绝大多数情况），直接走一阶段提交，省去 Prepare 的网络开销，延迟大幅降低。
- TSO（Timestamp Oracle）：全局时间戳服务为事务分配单调递增的时间戳，保证全局事务的因果序。
这意味着大部分事务享受单机般的低延迟，只有真正跨分区的事务才付出分布式协调的代价。
小结
OceanBase 的技术栈可以用三个词概括：写快（LSM-Tree） 、能分析（HTAP） 、不怕挂（Paxos 多副本）。它不是对 MySQL 的简单改造，而是一个从存储引擎到事务模型都重新设计的分布式数据库。对于正在做数据库选型或架构升级的团队，值得认真评估。