Greenplum、OceanBase、Oracle 和 TiDB 这四种数据库的核心架构区别

详细架构区别分析

1. Greenplum:
   • 架构模型: 纯 MPP (Shared-Nothing)。数据被水平分区并分布在多个 Segment 节点上。查询由 Coordinator 节点接收、解析、优化，然后并行分发到所有相关的 Segment 节点上执行，各节点处理自己的本地数据，最后结果汇总到 Coordinator 返回给客户端。
   • 存储引擎: 基于 PostgreSQL (堆表存储)。主要面向列存储优化 (支持列存表、压缩)，但也支持行存表。存储与计算紧密耦合在每个 Segment 上。
   • 事务处理: 提供 ACID 事务，但主要针对分析型负载优化，不适合高并发 OLTP。MVCC 实现源自 PostgreSQL。
   • 扩展性: 水平扩展 (Scale-Out)。通过增加 Segment 节点来处理更大数据和更高分析查询负载。扩展性好。
   • 高可用: 通常通过 Segment 镜像 (主备同步复制) 实现。Master/Coordinator 也需要高可用配置。故障切换有一定管理开销。
   • 一致性: 最终一致性 (对于镜像同步) 或强一致性 (事务内)。分布式事务协调开销相对较大。
   • 适用场景: 大规模数据仓库、商业智能、复杂分析查询、ETL 处理。
2. OceanBase:
   • 架构模型: 分布式 Shared-Nothing。核心组件包括：
     • OBServer: 每个节点包含 SQL 引擎 (Parser/Optimizer/Executor) 和存储引擎。
     • RootService: 集群管理、元数据管理、负载均衡、DDL 协调。
     • Paxos 协议: 核心创新点。每个数据分区 (Partition) 的多个副本 (通常 3 个，跨不同 Zone/机房) 组成一个 Paxos 组，通过 Multi-Paxos 协议实现强一致性和高可用。读写请求由 Leader 副本处理。
   • 存储引擎: 基于 LSM-Tree 的行列混合存储 (Delta + SSTable)。增量数据在内存 (MemTable) 和磁盘 (Mini SSTable) 中按行存储。后台合并生成按列存储的 SSTable (基线数据)。这种设计兼顾了 OLTP 的写入性能和 OLAP 的扫描性能。
   • 事务处理: 强一致的分布式事务。通过全局时间戳服务 (GTS) 和 Paxos 组保证 ACID。专为高并发 OLTP 设计，同时支持 OLAP。
   • 扩展性: 水平扩展 (Scale-Out)。通过增加 OBServer 节点轻松扩展存储和计算能力。RootService 自身也是分布式高可用的。
   • 高可用: 基于 Paxos 的 RPO=0 (零数据丢失)。Leader 故障时，Paxos 组内自动选举新 Leader，通常在秒级完成，对应用透明。
   • 一致性: 强一致性 是默认且核心保证。读写都在 Leader 副本进行，保证线性一致性。
   • 适用场景: 对数据一致性、高可用性要求极高的核心 OLTP 系统 (如金融交易、支付)，以及需要实时分析 HTAP 场景。
3. Oracle (以 RAC 为代表):
   • 架构模型:
     • 单机: 经典的单节点架构，所有组件 (SQL 引擎、缓存、存储管理) 在一个实例中。
     • RAC (Real Application Clusters): Shared-Disk 架构。多个数据库实例 (运行在不同服务器上) 同时访问共享的存储 (如 SAN/NAS)。实例之间通过高速互联网络 (如 InfiniBand) 和 Cache Fusion 机制同步数据块缓存。
   • 存储引擎: 行存储 (堆组织表或索引组织表)。有强大的缓存 (Buffer Cache) 机制。支持分区表。
   • 事务处理: 业界领先的 OLTP 引擎。高度优化的锁机制、UNDO/REDO、高效的 MVCC 实现。RAC 允许实例级扩展以提升 OLTP 并发能力。
   • 扩展性:
     • 单机: 垂直扩展 (Scale-Up)，受限于单服务器硬件。
     • RAC: 提供有限的水平扩展能力 (主要针对读和部分写并发)。但存储是单一共享点，容易成为瓶颈，且 Cache Fusion 的同步开销限制了大规模扩展 (通常建议 2-4 节点，最大支持更多但复杂度高)。
   • 高可用: RAC 提供实例级高可用。一个实例故障，其他实例接管其工作负载。需要配合 ASM (存储管理)、Data Guard (异地容灾) 等实现更全面的高可用和容灾。RPO/RTO 取决于配置。
   • 一致性: 强一致性。单实例内部或 RAC 通过 Cache Fusion 保证数据一致性。
   • 适用场景: 传统企业核心 OLTP 系统、ERP/CRM、需要强大单机性能或 RAC 有限扩展/高可用的关键业务系统。也有用于数据仓库 (需额外组件如 Exadata, Partitioning, In-Memory)。
4. TiDB:
   • 架构模型: 分布式 Shared-Nothing。核心组件解耦：
     • TiDB Server: 无状态的 SQL 层。负责 SQL 解析、优化、执行计划生成。不存储数据。应用直接连接 TiDB Server。
     • TiKV: 分布式、强一致的 Key-Value 存储引擎。数据以 Region (数据分片) 为单位组织，通过 Raft 协议实现多副本复制 (通常 3 副本) 和强一致性。每个 Region 的 Leader 处理读写。
     • Placement Driver (PD): 集群的“大脑”。负责元数据存储、Region 调度、负载均衡、全局 TSO 分配 (分布式事务时间戳)。
   • 存储引擎: TiKV 基于 RocksDB (LSM-Tree) 的 KV 存储。TiFlash 是可选的列存引擎 (通过 Raft Learner 异步复制 TiKV 的数据)，专门用于加速 AP 查询。HTAP 的核心在于 TiKV (行存, OLTP) + TiFlash (列存, OLAP) 的分离架构。
   • 事务处理: 支持分布式事务 (基于 Percolator 模型，使用 PD 的 TSO)。默认隔离级别是 SI (快照隔离)，通过优化支持 RC (已提交读)。为 OLTP 优化，同时通过 TiFlash 支持 OLAP。
   • 扩展性: 水平扩展 (Scale-Out)。可独立扩展 TiDB Server (计算)、TiKV (TP 存储和计算)、TiFlash (AP 存储和计算)。扩展性好。
   • 高可用: 基于 Raft 协议，Region 副本级别的高可用。Leader 故障自动切换。PD 自身也通过 Raft 实现高可用。RPO=0 (TiKV), RTO < 30s。
   • 一致性: 强一致性 (对于 TiKV 读写)。TiFlash 通过异步复制提供最终一致性 (可配置为 Follower Read 或指定时间戳读保证一致性)。
   • 适用场景: 需要水平扩展和高可用性的 OLTP 应用，需要实时分析能力的 HTAP 场景，替代 MySQL 分库分表的场景，云原生应用。

关键区别总结表

简单来说：

• Greenplum: 专为大数据分析而生，是 PostgreSQL 的 MPP 扩展版，擅长并行处理海量数据的复杂查询。
• OceanBase: 追求极致强一致、高可用和高性能的分布式 HTAP，尤其适合金融等对数据零丢失要求严苛的核心交易系统。
• Oracle (RAC): 成熟、功能强大的单机/共享存储 OLTP 王者，拥有最丰富的企业级特性和生态，但在大规模分布式扩展性和成本上存在挑战。
• TiDB: 开源的、云原生设计的分布式 HTAP 数据库，架构清晰（计算存储分离），水平扩展性好，兼容 MySQL 协议，适合需要同时处理交易和分析的互联网规模应用。

选择哪种数据库取决于您的具体业务需求（是 OLTP 为主、OLAP 为主还是 HTAP）、数据规模、对一致性/可用性的要求、扩展性需求、技术栈兼容性以及预算成本等因素。