无论是数据量还是访问量，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通常将每日合并时间设置在业务的低峰期(比如午夜之后)，这样每日合并对用户的影响很小。