就像在“系统架构(一)”提到的，只有分布式架构才能支撑当前和未来越来越庞大的数据量和访问量，同时OceanBase还必须支持跨行跨表事务，看起来OceanBase似乎需要实现分布式事务。
然而，分布式事务不仅实现复杂，更重要的是它尚未在工业界得到广泛应用，其效率和性能等还有待更多生产实践的检验。
仔细分析诸多业务发现，尽快很多数据库系统数据量十分庞大，例如几十亿、几百亿条甚至更多，但一段时间(例如一天)的修改量并不大，通常不超过几千万条到几亿条，因此OceanBase决定使用单台服务器(称为UpdateServer)来记录这段时间(例如一天)的修改增量，并以内存表(memtable)为主，SSD(固态盘)为辅。修改增量之外的、在此段时间内保持不变的数据称为基线数据。基线数据以类似于分布式文件系统的方式存储于多台服务器(称为ChunkServer)上，每次查询都由MergerServer把ChunkServer上的基线数据和UpdateServer上的增量数据融合后返回给调用者。这样写事务集中在UpdateServer进行，读事务分散在多台服务器上，既实现了跨行跨表事务、避免了复杂的分布式写事务，又有较好的扩展性。
图5.1
UpdateServer开始总是以内存表(memtable)方式记录修改，如果内存表(memtable)达到一定阈值，UpdateServer就冻结当前内存表并同时开启新的内存表，之后的修改写入新的内存表。冻结内存表不再接受写入并被转换成一种紧凑格式保存到SSD盘，转换完成后，冻结内存表的内存即可回收。
OceanBase内部使用主键(类似于经典关系数据库的聚集索引)对表中数据进行排序和存储，主键由若干列组成并具有唯一性。在OceanBase内部，基线数据按主键排序并划分成数据量大致相等的块，称为tablet。Tablet的缺省大小是256MB(可配置)并存储在ChunkServer上，为了避免ChunkServer故障导致数据丢失，tablet通常保存2~3个副本(可配置)。
图5.2
OceanBase每隔一段时间(例如一天)会把这段时间的修改增量合并到原有基线数据并生成新的基线数据(称为每日合并)，然后清除UpdateServer中过期的修改增量和ChunkServer上过期的基线数据。合并开始时，UpdateServer会冻结当前内存表并开启新的内存表，此后新的修改将写入新的内存表，ChunkServer则把当前的基线数据与冻结的内存表融合并生成新的基线数据，当所有tablet的新的基线数据都生成后，UpdateServer冻结的内存表即可释放，其所占内存也被回收。为了降低每日合并对用户访问OceanBase的影响，每日合并被设置成低优先级任务，当机器负载(例如CPU load和iowait等)高于一定阈值时，合并速度会减慢甚至暂停。在实际应用中，数据库管理员(DBA)通常把每日合并时间设定在业务的低峰期(例如后半夜)，这样每日合并对用户基本没有什么影响。
联系客服
