OceanBase本质上是一个基线加增量的存储引擎，跟关系数据库差别很大。存储机制是LSM树（Log-Structured Merge Tree，日志结构合并树），这也是大多数NoSQL使用的存储机制。OceanBase采用了一种读写分离的架构，把数据分为基线数据和增量数据，其中增量数据放在内存里（MemTable），基线数据放在SSD盘（SSTable）。
虽然不是刻意设计的，但OceanBase确实比传统数据库更适合像双十一、秒杀以及优惠券销售等短时间突发大流量的场景：
短时间内大量用户涌入，短时间内业务流量非常大，数据库系统压力非常大
一段时间（几秒钟、几分钟、或半个小时等）后业务流量迅速或明显回落
OceanBase是“基线数据（硬盘）”+“修改增量（内存）”的架构，如下图所示。
整个数据库以硬盘（通常是SSD）为载体，对数据的修改都是增量数据，只写内存，新近的增、删、改数据（修改增量）在内存，所以DML是完全的内存操作，性能非常高。而基线数据在保存在硬盘上，因此OceanBase可以看成一个准内存数据库。
这样做的好处有：
写事务在内存（除事务日志必须落盘外），性能大大提升。
没有随机写硬盘，硬盘随机读不受干扰，高峰期系统性能提升明显；对于传统数据库，业务高峰期通常也是大量随机写盘（刷脏页）的高峰期，大量随机写盘消耗了大量的IO，特别是考虑到SSD的写入放大，对于读写性能都有较大的影响。
基线数据只读，缓存（cache）简单且效果提升。
读数据的时候，数据可能会在内存里有更新过的版本，在持久化存储里有基线版本，需要把两个版本进行合并，获得一个最新版本。同时在内存实现了Block Cache和Row cache，来避免对基线数据的随机读。当内存的增量数据达到一定规模的时候，会触发增量数据和基线数据的合并，把增量数据落盘（称为转储，又叫minor freeze）。同时每天晚上的空闲时刻，系统也会自动每日合并(简称合并，major freeze)。
OB为何采用这种特殊架构，简要来说，就是基于这样一条理论基础——尽管数据库本身的数据量越来越大，记录数越来越多，但每天的增删改数据量并不大，仅仅只占数据库总量一个很小的比例。这个情况不只是对支付宝的支付数据，对其它大部分数据库实际应用情况也适用，是OB建立上述存储引擎的重要理论基础。
