数据库07：TiDB / OceanBase

TiDB 和 OceanBase 是国内最具代表性的 NewSQL 数据库，它们的目标是在分布式场景下提供和传统关系型数据库一样的 SQL 体验，同时支持水平扩展。

这篇文章围绕四个核心点：分布式 SQL 架构、HTAP 混合负载、Raft 一致性协议、水平扩展，理解 NewSQL 数据库的设计思路和适用边界。

NewSQL：分布式时代的关系型数据库

传统关系型数据库（MySQL）在分布式场景下面临两个核心问题：

1. 扩展性差：单节点容量有限，分库分表复杂度高
2. 一致性难保证：跨节点事务需要分布式事务协议

NewSQL 数据库解决了这两个问题，让开发者可以像使用单机数据库一样使用分布式数据库。

NewSQL vs 传统方案

维度	MySQL + 分库分表	TiDB / OceanBase
SQL 兼容性	需要适配分片规则	完整 MySQL 兼容性
事务支持	分布式事务复杂	原生分布式事务
水平扩展	需要手动拆分	自动水平扩展
数据一致性	最终一致性	强一致性
运维复杂度	高（分片管理）	低（自动管理）

TiDB vs OceanBase

维度	TiDB	OceanBase
开源模式	完全开源	社区版开源，商业版收费
架构设计	计算存储分离	计算存储分离
一致性协议	Raft	Paxos
HTAP 支持	通过 TiFlash 实现	原生 HTAP
生态成熟度	社区活跃，工具完善	阿里内部验证，生态较少
适用场景	互联网业务，快速迭代	金融级业务，稳定性优先

分布式 SQL 架构

TiDB 和 OceanBase 都采用计算存储分离的架构，但实现细节有所不同。

TiDB 架构

TiDB Server（计算层）
  ├── PD（Placement Driver，元数据管理）
  └── TiKV（存储层，基于 Raft）

组件职责：

• TiDB Server：SQL 解析、优化、执行，无状态
• PD：集群元数据管理，调度数据分片
• TiKV：分布式存储引擎，基于 Raft 保证一致性

OceanBase 架构

OBServer（计算存储一体化）
  ├── RootService（集群管理）
  └── Zone（可用区）

组件职责：

• OBServer：同时负责计算和存储，支持弹性伸缩
• RootService：集群管理、负载均衡、故障恢复
• Zone：可用区级别的高可用单元

数据分片

数据库	分片方式	特点
TiDB	按 Key Range 自动分片	动态调整，自动平衡
OceanBase	按 Tablet 分片	更细粒度的分片管理

HTAP：混合负载的挑战

HTAP（Hybrid Transactional/Analytical Processing）是 NewSQL 的重要特性，它让同一个数据库可以同时支持 OLTP 和 OLAP 负载。

HTAP 架构

OLTP 请求 ──→ TiDB Server ──→ TiKV（行存）

OLAP 请求 ──→ TiDB Server ──→ TiFlash（列存）
                              └── TiKV（行存）

TiFlash：列式存储引擎

TiFlash 是 TiDB 的列式存储引擎，专为 OLAP 场景设计：

• 列式存储：高压缩率，高效聚合
• 实时同步：与 TiKV 实时同步，数据一致
• MPP 执行：支持大规模并行处理

HTAP 适用场景

场景	说明
实时报表	基于最新数据生成报表
实时分析	用户行为分析、业务监控
数据仓库	替代传统数仓，降低成本
混合负载	同一数据库同时处理交易和分析

HTAP 挑战

• 资源竞争：OLTP 和 OLAP 共享资源，可能互相影响
• 数据一致性：行存和列存之间需要实时同步
• 查询优化：需要区分 OLTP 和 OLAP 查询，选择不同执行路径

Raft：分布式一致性协议

TiDB 使用 Raft 协议保证数据一致性，OceanBase 使用 Paxos 协议。两者都是分布式一致性协议，但 Raft 更简单易懂。

Raft 核心概念

1. 节点角色：

   • Leader：负责接收客户端请求，复制日志到 Followers
   • Follower：被动接收日志，响应 Leader 心跳
   • Candidate：选举期间的临时角色

2. 日志复制：

   • Leader 接收请求，写入日志
   • 复制日志到多数派 Followers
   • 多数派确认后，提交日志

3. 选举机制：

   • Follower 超时未收到心跳，转为 Candidate
   • Candidate 向其他节点发起投票
   • 获得多数票的 Candidate 成为 Leader

Raft vs Paxos

维度	Raft	Paxos
复杂度	简单，容易理解和实现	复杂，难以实现
选举机制	随机超时，避免冲突	多轮投票，可能活锁
日志复制	强领导者，简化复制	无强领导者，复杂
适用场景	分布式存储、服务发现	学术界研究、金融系统

水平扩展：按需伸缩

NewSQL 数据库的核心优势是水平扩展，可以根据业务需求动态调整集群规模。

扩展方式

方式	TiDB	OceanBase
计算扩展	添加 TiDB Server	添加 OBServer
存储扩展	添加 TiKV Node	添加 OBServer
自动伸缩	支持（通过 PD）	支持（通过 RootService）

扩缩容流程

1. 扩容：

   • 添加新节点到集群
   • PD/RootService 检测到新节点
   • 自动迁移部分数据到新节点

2. 缩容：

   • 标记节点为待下线
   • PD/RootService 迁移节点上的数据
   • 数据迁移完成后，下线节点

数据迁移特点

• 在线迁移：迁移过程中不影响业务
• 增量同步：只迁移变化的数据
• 自动平衡：迁移完成后，数据均匀分布

项目判断清单

• 需要分布式 SQL，不想分库分表 → TiDB / OceanBase
• 需要 HTAP 混合负载 → TiDB（TiFlash）或 OceanBase
• 需要金融级稳定性 → OceanBase
• 需要快速迭代和社区支持 → TiDB
• 需要完全开源 → TiDB
• 数据量超过单库限制 → TiDB / OceanBase
• 需要弹性伸缩 → TiDB / OceanBase