• LSM-Tree 原生优势： 传统的 B+ 树数据库更新时会产生大量随机 IO。而 OceanBase 基于 LSM-Tree 架构，最近的增量更新（主要是 TP事务）直接写入内存（MemTable），这部分数据是以行存格式保留的，能提供极高的并发 TPS（事务处理）。
• SSTable 多种形态演进： 当内存数据刷盘并进行大合并（Major Compaction）生成基线数据 SSTable 时，OceanBase 开始施展魔法。在 OceanBase 4.3 版本中，它原生地引入了微块级别的列存（Column Store）引擎。
• 一份数据，两种表达： 数据在落盘时，可以保存为行列混合存储或者纯列存格式（不仅大幅提升了压缩比，甚至可达十倍压缩）。当分析型的大宽表查询（如 SUM、GROUP BY）到来时，系统直接拉取列存微块，利用向量化引擎，大幅度加速扫描。

• 全并行计算架构： 当一个报表型的超级大 SQL 发送给 OceanBase 时，优化器会将其拆解为多个并行执行的任务。OceanBase可以榨干所有节点（OBServer）的 CPU 核数，将任务分发到各个拥有数据碎片的节点进行分布式下推计算（聚合、过滤提前在本地做），最后在总控节点瞬间汇总。
• 向量化执行引擎（Vectorized Execution）： 原本的火山模型是一行一行处理数据，而 OceanBase 在拉取底层“列存微块”时，采用 CPU级别的向量化指令（SIMD），一次性处理一批（Batch）几十上百行的数据，大幅降低 CPU 开销。

• TP / AP 智能分流： 在同一个节点内，优化器根据代价评估能够自动判断这是一个点查（走主键索引、回表拉取行存）还是一个全表扫描的 AP查询（直接引导读取列存微块，进行批量分析）。
• 读写请求物理路由： 如果架构规划上为了极致的稳定性，还可以通过配置部署，要求“只读列存副本（F 副本或者 R 副本）”专门利用 CPU去接手海量的历史数据分析，做到主副本全力负责 TP 写，而 AP 读请求毫秒级自动路由至对应副本。

• 租户级别的隔离： 上一题我们讲了 Resource Pool，内存和 CPU 是严格按租户隔离的。
• 大查询与小查询的精细控制（Resource Manager）： OceanBase 甚至可以实现在**同一个租户内**的资源控制！通过绑定不同的数据库账号，或者打上Hint，将交易 SQL 和分析大 SQL 分配到不同的资源组（Cgroups技术）。比如限制那个跑报表的账号最多只能用 20% 的 CPU 核数。无论分析型大 SQL怎么折腾，绝对不会影响占有核心 CPU 的在线交易订单（TP业务）的极速写入！

想了解更多干货，可通过下方扫码关注

可扫码添加上智启元官方客服微信👇