淘宝海量数据库OceanBase系统架构
无论是数据量还是访问量，OceanBase都不能再是单机系统，即使单机可以服务高达数TB的数据，提供数万QPS的服务能力，因此，分布式系统是必然的。但是要实现内部表反汇编(数据库反汇编)和海量数据库的事务，是一个很大的挑战，也是一个很艰难的选择:
一个选择是现在的海量数据库常见的横库拆，淘宝在这方面已经有了很多实践。通常的做法是对主键进行哈希或模运算(其实是一种特殊的哈希)，将数据分发到不同的DB服务器上，客户端通过路由或规则访问一个特定的海量数据库然而，这种方法有一些缺点:
一、数据和负载增加后的加机操作复杂；
二、很多跨行/跨表修改通常涉及多台机器，难以支持事务；
三、有些范围查询需要访问几乎所有的机器；
四、单一的RDBMS数据量小(比如MySQL在很多情况下支持200GB左右的数据时性能更好)，可能会消耗大量的机器资源；
至关重要的是，这种方法在很多年前就被几乎所有的relationships 海量数据库厂商采用并积累了丰富的经验，而OceanBase项目组没有理由做得更好。
还有一种分布式B+树(类似BigTable和HBase)，可以根据主键的范围动态拆解数据库，即把整个表看成一棵主键的B+树，每个叶子节点(约200 MB)对应一个连续的主键范围。由于修改、删除等，叶节点可能变得太大或太小。，以便拆分或合并。容错、恢复和负载平衡都基于叶节点。
这种架构的优点是系统易于扩展:只需添加机器，少数突发的机器故障甚至对用户透明。负载均衡优于以前的方案，范围查询容易实现且高效。
但是这种架构最大的难点是事务的实现，因为BigTable只有单行事务，而OceanBase需要跨行跨表的事务。项目组花了很长时间来解决这个问题(参见“系统架构(2)”)。理论分析和代码实现表明，该方法简单高效。
后来有机会看了Google关于分布式事务的文章(《使用分布式事务和通知的大规模增量处理》)，感受到了它优秀的设计和复杂性。同时我也发现，虽然使用15000个CPU核达到了创纪录的11200 tps (TPC-E基准)，但其平均事务响应时间为2s-5s，不符合淘宝平均响应时间几毫秒到几十毫秒的需求。此外，开发类似的系统及其底层BigTable和GFS系统所需的时间、人力、物力和技术挑战是巨大的。
如上所述，只有分布式架构才能支持目前和未来不断增长的数据量和访问量。同时，OceanBase还必须支持跨行、跨表交易。看来OceanBase需要实现分布式事务。
然而，分布式事务不仅实现起来复杂，更重要的是还没有在业界得到广泛应用，其效率和性能还需要更多的生产实践来检验。
仔细分析很多业务可以发现，尽快，很多海量数据库系统的数据量是巨大的，比如几十亿，几百亿甚至更多。但一定时间内(比如一天)的变化量并不大，通常不超过几千万到几亿。因此，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通常将每日合并时间设置在业务的低峰期(比如午夜之后)，这样每日合并对用户的影响很小。
