OceanBase 初识：为什么需要一个“既能跑又能跳“的数据库

status: 学习中OceanBase 初识为什么需要一个既能跑又能跳的数据库从一个真实场景说起想象你在运营一个电商平台。双十一零点订单像洪水一样涌入OLTP 场景用户下单、支付、库存扣减 → 要求极低延迟、强一致性OLAP 场景实时大屏展示销售额、热销商品排行 → 要求复杂查询、大数据量聚合传统做法是什么搭两套系统MySQL 处理交易OLTPClickHouse/Hive 做分析OLAP中间用 Kafka ETL 同步数据这套架构的问题数据延迟分析数据总是滞后几分钟甚至几小时维护成本两套系统的运维、监控、备份数据一致性同步链路出问题时两边数据对不上资源浪费OLTP 高峰时 OLAP 闲置反之亦然[!question] 核心问题能不能有一个数据库既能处理高并发交易又能跑复杂分析查询这就是 OceanBase 要解决的问题。OceanBase 是什么OceanBase 是一个原生分布式数据库最大的特点是HTAPHybrid Transactional/Analytical ProcessingTPTransaction Processing像 MySQL 一样处理在线交易APAnalytical Processing像 ClickHouse 一样做实时分析HHybrid在同一份数据上同时支持两种负载用一个比喻传统数据库像专业运动员短跑选手跑得快但跳不高跳高选手跳得高但跑不快。OceanBase 像十项全能选手虽然单项可能不是第一但综合能力最强。为什么 OceanBase 能做到这一点1. 存储引擎的秘密LSM-TreeOceanBase 使用LSM-TreeLog-Structured Merge-Tree存储引擎而不是 MySQL 的 B Tree。关键区别B Tree写入时直接修改磁盘上的数据页 → 随机写慢LSM-Tree写入先进内存MemTable批量刷盘 → 顺序写快写入流程 用户写入 → MemTable内存 → 定期合并 → SSTable磁盘 ↓ WAL 日志保证持久化为什么这对 HTAP 重要TP 负载写多读少 → LSM-Tree 的顺序写优势明显AP 负载读多写少 → LSM-Tree 的列式存储SSTable扫描效率高2. 多副本架构Paxos 协议OceanBase 使用Paxos协议实现多副本强一致三副本部署 Zone1: Leader主 ← 处理读写 Zone2: Follower从 ← 同步复制 Zone3: Follower从 ← 同步复制关键点写入必须在多数派2/3确认后才返回成功 → 强一致性任意一个副本挂掉自动选主 → 高可用不同于 MySQL 的异步复制主从延迟问题3. 分区与负载隔离OceanBase 支持表分区Partition和租户隔离Tenant物理集群 ├── 租户 AOLTP 业务 │ ├── CPU: 50 核 │ ├── 内存: 200GB │ └── 表分区: 按用户 ID 哈希分布 └── 租户 BOLAP 业务 ├── CPU: 30 核 ├── 内存: 100GB └── 读取租户 A 的数据共享存储好处TP 和 AP 负载物理隔离互不影响同一份数据不需要 ETL 同步资源可以动态调整OceanBase 与 MySQL 的关系[!tip] 兼容性OceanBase 高度兼容 MySQL 协议和语法大部分 MySQL 应用可以无缝迁移。相同点SQL 语法 99% 兼容 MySQL支持 JDBC/ODBC 驱动支持事务ACID不同点OceanBase 是分布式架构MySQL 是单机OceanBase 使用 LSM-TreeMySQL 使用 B TreeOceanBase 原生支持 HTAPMySQL 需要外部组件迁移成本应用层几乎不需要改代码运维层需要学习分布式数据库的运维方式适用场景适合 OceanBase 的场景需要同时支持交易和分析如电商、金融数据量大单机 MySQL 扛不住TB 级以上对可用性要求高金融级希望简化架构减少组件数量不适合的场景数据量小几十 GB单机 MySQL 够用纯 OLAP 场景ClickHouse 更合适团队没有分布式数据库运维经验小结OceanBase 的核心价值一体化OLTP OLAP减少数据搬运高可用多副本强一致金融级可靠性弹性扩展分布式架构水平扩展MySQL 兼容迁移成本低