无论是数据量还是访问量， OceanBase 都不能再是单机系统，即使单机可以服务高达数 TB 的数据，提供数万 QPS 的服务能力，因此，分布式系统是必然的。但是要实现内部表反汇编 ( 数据库反汇编 ) 和 海量数据库 的事务，是一个很大的挑战，也是一个很艰难的选择。

一种选择是目前数据库常见的横向拆解，淘宝在这方面做了很多实践。通常的做法是对主键进行哈希或模运算 ( 实际上是一种特殊的哈希 ) ，将数据分布到不同的 DB 服务器上，客户端通过路由或规则访问特定的数据库，将整个系统的数据和访问负载分布到多个服务器上，从而减轻单机的负载压力。然而，这种方法有一些缺点：

一是数据和负载增加后的加机操作复杂；

二是很多跨行 / 跨表修改通常涉及多台机器，难以支持事务；

三是有些范围查询需要访问几乎所有的机器；

四是单一的 RDBMS 数据量小 ( 比如 MySQL 在很多情况下支持 200GB 左右的数据时性能更好 ) ，可能会消耗大量的机器资源；

至关重要的是，这种方法在很多年前就被几乎所有的 relationships 海量数据库厂商采用并积累了丰富的经验，而 OceanBase 项目组没有理由做得更好。

还有分布式 B+ 树 ( 类似 BigTable 和 HBase) ，根据主键的范围动态拆分数据库，即把整个表看成一棵主键的 B+ 树，每个叶节点 ( 约 200 MB) 对应一个连续的主键范围。由于修改、删除等，叶节点可能变得太大或太小。以及拆分或合并。容错、故障恢复和负载均衡都是基于叶节点的 ( 关于 Bigtable 的更多信息，请参考另一篇博客：云计算的分布式表系统或 BigTable 论文：《 BigTable ：结构化数据的分布式存储系统》 ) 。

这种架构的优点是系统易于扩展：只需添加机器，少数突发的机器故障甚至对用户透明。负载均衡优于以前的方案，范围查询容易实现且高效。

但是这种架构最大的难点是事务的实现，因为 BigTable 只有单行事务，而 OceanBase 需要跨行跨表的事务。项目组花了很长时间来解决这个问题 ( 参见 “ 系统架构 (2)”) 。理论分析和代码实现表明，该方法简单高效。

后来有机会看了 Google 关于分布式事务的文章 ( 《使用分布式事务和通知的大规模增量处理》 ) ，感受到了它优秀的设计和复杂性。同时我也发现，虽然使用 15000 个 CPU 核达到了创纪录的 11200 tps (TPC-E 基准 ) ，但其平均事务响应时间为 2s-5s ，不符合淘宝平均响应时间几毫秒到几十毫秒的需求。此外，开发类似的系统及其底层 BigTable 和 GFS 系统所需的时间、人力、物力和技术挑战是巨大的。

如上所述，只有分布式架构才能支持目前和未来不断增长的数据量和访问量。同时， OceanBase 还必须支持跨行、跨表交易。看来 OceanBase 需要实现分布式事务。

然而，分布式事务不仅实现起来复杂，更重要的是还没有在业界得到广泛应用，其效率和性能还需要更多的生产实践来检验。

仔细分析了很多业务，发现海量数据库 system 的数据量非常巨大，比如几十亿、几百亿甚至更多，但是某一段时间 ( 比如一天 ) 的修改量并不大，通常不超过几千万到上亿。所以 OceanBase 决定使用单个服务器 ( 称为 UpdateServer) 来记录这段时间 ( 比如一天 ) 内的修改增量，主要是内存 memtable 。超出增量并在此期间保持不变的数据称为基线数据。基线数据以类似于分布式文件系统的方式存储在多个服务器 ( 称为 ChunkServer) 上， MergerServer 为每个查询融合 ChunkServer 上的基线数据和 UpdateServer 上的增量数据，并将其返回给调用者。这样，写事务集中在 UpdateServer ，读事务分散在多个服务器上，既实现了跨行、跨表事务，又避免了复杂的分布式写事务，具有良好的可扩展性。

首先， UpdateServer 总是以内存表的形式记录更改。如果内存表达到一定的阈值， UpdateServer 将冻结当前内存表，同时打开一个新的内存表，后续的更改将被写入新的内存表。冻结的内存表不再接受写入，转换成紧凑格式保存到 SSD 磁盘。转换完成后，冻结内存表的内存可以回收。

OceanBase 使用主键 ( 类似于经典关系数据库的聚集索引 ) 对表中的数据进行排序和存储。主键由几列组成，并且是唯一的。在 OceanBase 内，基线数据按主键排序，分成数据量大致相等的块，称为 tablet 。平板电脑的默认大小为 256MB( 可配置 ) ，存储在 ChunkServer 上。为了避免 ChunkServer 故障造成的数据丢失，平板通常会保留 2~3 份副本 ( 可配置 ) 。

每隔一段时间 ( 比如一天 ) ， OceanBase 会将这段时间内的修改增量合并到原来的基线数据中并生成新的基线数据 ( 称为每日合并 ) ，然后清除 UpdateServer 中过期的修改增量和 ChunkServer 上过期的基线数据。在合并开始时， UpdateServer 将冻结当前的内存表，并打开一个新的内存表。之后，新的修改将被写入新的内存表。 ChunkServer 会将当前的基线数据与冻结的内存表融合，并生成新的基线数据。当所有新的平板电脑基线数据生成后， UpdateServer 冻结的内存表将被释放，其内存将被恢复。为了减少每日合并对用户访问 OceanBase 的影响，每日合并被设置为低优先级任务。当机器负载 ( 如 CPU 负载和 iowait 等。 ) 高于某个阈值，合并速度会变慢甚至暂停。在实际应用中，海量数据库 DBA 通常将每日合并时间设置在业务的低峰期 ( 比如午夜之后 ) ，这样每日合并对用户的影响很小。