OceanBase是由淘宝核心系统研发部、运维、DBA、广告、应用研发等部门共同开发的一款支持海量数据的高性能分布式数据库系统，目前已经应用于淘宝收藏夹，用于存储淘宝用户收藏条目和具体的商品、店铺信息，每天支持4～5千万的更新操作。

在这篇文章中，OceanBase的掌门人阳振坤 （@阿里正祥）解释了为什么OceanBase可以把一天的修改增量置于内存，以及为什么OceanBase没有做成全内存数据库(如VoltDB，MemSQL)。

早在2010年5月，在OceanBase立项前，项目团队对许多数据库应用进行了分析，让我们看几个例子：
1. 全国人口数据库
全国的人口数据库很大，目前活着的人口有14亿条左右的记录，加上已经去世的人数量就更多，但每天修改的记录主要是出生(目前每天5万左右)，死亡(目前每天2~3万)和其他修改(如人口迁移、错误修正等)，每天增删改的记录，可能不到记录总数的1%。

2. 金融机构的交易库
交易库是金融机构(支付宝，银行等)的交易流水记录，主要是新增记录，但如果考虑到金融机构通常在线上保存1年或以上的交易记录，那么一天内增删改的记录就只是一个很小的比例，即使只在线上保存3个月的交易记录，每天增删改的记录也只占总记录的百分之几。

3. 金融机构的账务库
账务库保存着金融机构(支付宝，银行等)的客户的账务余额，可能有几千万甚至几亿条记录，但一天内增删改的记录则是那些当天有付款收款等交易，或者有其他特殊情况(例如销户等)的账户，因此也是一个很小的比例。

上述的例子和对其他数据库应用的分析让OceanBase项目团队发现了一个隐藏在数据库背后的事实：即尽管数据库本身的数据量越来越大，记录数越来越多，但每天的增删改数据量并不大，仅仅只占数据库总量一个很小的比例：

数据库每天增删改的数据量只占总量一个很小的比例

很多数据库每次只修改几十到几百字节，按平均100字节计算，每天10亿次写，其总修改量大约是100GB，单个服务器内存就可以容纳；即使每笔写事务4KB，每天10亿笔写事务，总修改量大约4TB，16台256GB内存或者8台512GB内存服务器也可以支撑(不考虑热备等因素)。

根据上述分析，OceanBase把修改增量(包括增删改，下同)置于内存，每天在业务的相对低谷期再合并到基线数据中并释放内存（参见下篇：“错峰合并消除OceanBase每日合并对性能的影响”），从而使得OceanBase彻底消除了写事务的随机写磁盘，极大地提升了性能。

为了支持上述特性，OceanBase采取了针对性的设计：

1. 设计实现了内存B树以保存和读写修改增量

支持记录的插入、删除和修改以及单项和范围读

2. 内存中数据只保存增量本身而不是对应的数据页
很多数据库单个表的单个写事务平均大小仅仅100字节左右，而数据库的数据页常常是8KB，这意味着8KB/100B=80倍的放大，因此如果OceanBase像其他商业和开源数据库一样用数据页，就需要把内存增加80倍。

3. 主库备库(一主多备)为active-active而非active-standby模式
修改增量全部置于内存，虽然极大提升了性能，但也带来了风险，即一旦服务器宕机，恢复时间可能比较长，为了克服这一风险，OceanBase没有像其他商业/开源数据库一样把备库做成standby模式，而是active模式，即主库故障后备库可以瞬间升级到主库并继续提供服务。

尽管全内存的数据库性能更高，但出于成本，特别是性价比的考虑，OceanBase没有采用全内存设计：
1. 数据库中大部分数据是冷数据，以80/20法则为例，80%的访问由20%的数据提供，把其余80%数据跟频繁访问的20%数据同等对待(置于内存)，显然不经济；
2. 单台服务器的内存容量只有磁盘(SSD)容量的1/10~1/20，如果采用全内存设计，就意味着10~20倍数量的服务器。

如果你对OceanBase感兴趣，可以关注OceanBase的微博，或者上GitHub OceanBase页面了解更多。