读写事务
在OceanBase系统中，用户的读写请求，即读写事务，都发给MergeServer。MergeServer解析这些读写事务的内容，例如词法和语法分析、schcma检查等。对于只读事务，由MergeScrver 发给相应的ChunkServer分别执行后再合并每个ChunkServer的执行结果；对于读写事务，由MergeServer进行预处理后，发送给UpdateServer执行。
只读事务执行流程如下：
1）MergeServer解析SQL语句，词法分析、语法分析、预处理（schema合法性检查、权限检查、数据类型检查等），最后生成逻辑执行计划和物理执行计划。
2）如果SOL请求只涉及单张表格，MergeServer将请求拆分后同时发给多台
ChunkServer并发执行，每台ChunkServer将读取的部分结果返回MergeServer，由MergeServer来执行结果合并。
3）如果SQL请求涉及多张表格，MergeServer还需要执行联表、嵌套查询等操作。
4）MergeServer将最终结果返回给客户端。
读写事务执行流程如下：
1）与只读事务相同，MergeServer首先解析SQL请求，得到物理执行计划。
2）MergeServer请求ChunkServer获取需要读取的基线数据，并将物理执行计划和基线数据一起传给Updateserver。
3）Updatesever根据物理执行计划执行读写事务，执行过程中需要使用MergeServer传入的基线数据。
4）UpdateServer返回MergeServer操作成功或者失败，MergeServer接着会把操作结果返回客户端。
例如，假设某SQL语句为update t1 set c1 = c1 + 1 where rowkey=1 ，即将表格t1中主键为1的c1列加1，这一行数据存储在Chunkserver中.c1列的值原来为2012。那么，MergeServer执行SQL时首先从ChunkServer读取主键为1的数据行的c1列，接着将读取结果（c1=2012）以及SOL语句的物理执行计划一起发送给UpdateServer。UpdateServer根据物理执行计划将c1加1，即将c1变为2013并记录到内存表（McmTable)中。当然，更新内存表之前需要记录操作日志。
单点性能
OceanBase架构的优势在于既支持跨行跨表事务，又支持存储服务器线性扩展。当然，这个架构也有一个明显的缺陷：UpdateServer单点，这个问题限制了OceanBase集群的整体读写性能。
下面从内存容量、网络、磁盘等几个方面分析UpdateServer的读写性能。其实大部分数据库每天的修改次数相当有限，只有少数修改比较频繁的数据库才有每天几亿次的修改次数。另外，数据库平均每次修改涉及的数据量很少，很多时候只有几十个字节到几百个字节。假设数据库每天更新1亿次，平均每次需要消耗100字节，每天插入1000万次，平均每次需要消耗1000字节，那么，一天的修改量为：1亿×100+1000
万×1000=20GB，如果内存数据结构膨胀2倍，占用内存只有40GB。而当前主流的服务器都可以配置96GB内存，一些高档的服务器甚至可以配置192GB、384GB乃至更多内存。
从上面的分析可以看出，UpdateServer的内存容量一般不会成为瓶颈。然而，服务器的内存毕竟有限，实际应用中仍然可能出现修改量超出内存的情况。例如，淘宝双11网购节数据库修改量暴涨，某些特殊应用每天的修改次数特别多或者每次修改的数据量特别大，DBA数据订正时一次性写入大量数据。为此，Updateserver设计实现了几种方式解决内存容量问题，Updancesever的内存表达到一定大小时，可自动或者手工冻结并转储到SSD中，另外，OceanBase支持通过定期合并或者数据分发的方式将Updateserver的数据分散到集群中所有的ChunkServer机器中，这样不仅避免了Updateserver单机数据容量问题，还能够使得读取操作往往只需要访问UpdateServer内存中的数据，避免访问SSD磁盘，提高了读取性能。
从网络角度看，假设每秒的读取次数为20万次，每次需要从UpdateServer中获取100字节，那么，读取操作占用的UpdateServer出口带宽为：20万×100=20MB，远远没有达到千兆网卡带宽上限。另外，UpdateServer还可以配置多块千兆网卡或者万兆网卡，例如，OceanBase线上集群一般给UpdateServer配置4块千兆网卡。当然，如果软件层面没有做好，硬件特性将得不到充分发挥。针对UpdateServer全内存、收发的网络包一般比较小的特点，开发团队对UpdateServer的网络框架做了专门的优化，大大提高了每秒收发网络包的个数，使得网络不会成为瓶颈。
从磁盘的角度看，数据库事务需要首先将操作日志写人磁盘。如果每次写人都需要将数据刷入磁盘，而一块SAS磁盘每秒支持的IOPS很难超过300，磁盘将很快成为瓶颈。为了解决这个问题，UpdateServer在硬件上会配置一块带有缓存模块的RAID卡，UpdateServer写操作日志只需要写入到RAID卡的缓存模块即可，延时可以控制在1毫秒之内。RAID卡带电池，如果UpdateServer发生故障，比如机器突然停电，RAID卡能够确保将缓存中的数据刷入磁盘，不会出现丢数据的情况。另外，UpdateServer 还实现了写事务的成组提交机制，将多个用户写操作凑成一批一次性提交，进一步减少磁盘IO次数。
SSD支持
磁盘随机10是存储系统性能的决定因素，传统的SAS盘能够提供的IOPS不超过300。关系数据库一般采用高速缓存（Bufcr Cache)9的方式缓解这个问题，读取操作将磁盘中的页面缓存到高速缓存中，并通过LRU或者类似的方式淘汰不经常访问的页面：同样，写人操作也是将数据写入到高速缓存中，由高速缓存按照一定的策略将内存中页面的内容刷人磁盘。这种方式面临一些问题，例如，Cache冷启动问题，即数据库刚启动时性能很差，需要将读取流量逐步切人。另外，这种方式不适合写入特别多的场景。
最近几年，SSD磁盘取得了很大的进展，它不仅提供了非常好的随机读取性能，功耗也非常低，大有取代传统机械磁盘之势。一块普通的SSD磁盘可以提供35000 IOPS甚至更高，并提供300MB/s或以上的读出带宽。然而，SSD盘的随机写性能并不理想。这是因为，尽管SSD的读和写以页（page，例如4KB，8KB等）为单位，但SSD写入前需要首先擦除已有内容，而擦除以块（block)为单位，一个块由若干个连续的页组成，大小通常在512KB~2MB。假如写人的页有内容，即使只写人一个字节，SSD也需要擦除整个512KB~2MB大小的块，然后再写入整个页的内容，这就是SSD的写入放大效应。虽然SSD硬件厂商都针对这个问题做了一些优化，但整体上看，随机写入不能发挥SSD的优势。
OceanBase设计之初就认为SSD为大势所趋，整个系统设计时完全摒弃了随机写，除了操作日志总是顺序追加写入到普通SAS盘上，剩下的写请求都是对响应时间要求不是很高的批量顺序写，SSD盘可以轻松应对，而大量查询请求的随机读，则发挥了SSD良好的随机读的特性。摒弃随机写，采用批量的顺序写，也使得固态盘的使用寿命
不再成为问题，主流SSD盘使用MLCSSD芯片，而MLC号称可以擦写1万次（SLC可以擦写10万次，但因成本高而较少使用），即使按最保守的2500次擦写次数计算，而且每天全部擦写一遍，其使用寿命为2500/365=6.8年。
数据正确性
数据丢失或者数据错误对于存储系统来说是一种灾难。OceanBase设计为强一致性系统，设计方案上保证不丢数据。然而，TCP协议传输、磁盘读写都可能出现数据错误，程序Bug则更为常见。为了防止各种因素导致的数据损毁，OceanBase采取了以下数据校验措施：
- 数据存储校验。每个存储记录（通常是几KB到几十KB）同时保存64位CRC校验码，数据被访问时，重新计算和比对校验码。
- 数据传输校验。每个传输记录同时传输64位CRC校验码，数据被接收后，重新计算和比对校验码。
- 数据镜像校验。UpdateServer在机群内有主UpdateServer和备UpdateServer，集群间有主集群和备集群，这些UpdateServer的内存表（MemTable)必须保持一致。为此，UpdateServer为MemTable生成一个校验码，MemTable每次更新时，校验码同步更新并记录在对应的操作日志中。备UpdateServer收到操作日志并重放到MemTable时，也同步更新MemTable校验码并与接收到的校验码对照。UpdateServer 重新启动后重放日志恢复MemTable时也同步更新MemTable校验码并与保存在每条操作日志中的校验码对照。
- 数据副本校验。定期合并时，新的子表由各个ChunkServer独立地融合旧的子表中的SSTable与冻结的MemTable而生成，如果发生任何异常或者错误（比如程序bug），同一子表的多个副本可能不一致，则这种不一致可能随着定期合并而逐步累积或扩散且很难被发现，即使被察觉，也可能因为需要追溯较长时间而难以定位到源头。为了防止这种情况出现，ChunkServer在定期合并生成新的子表时，也同时为每个子表生成一个校验码，并随新子表汇报给RootServer，以便RootServer核对同一子表不同副本的校验码。
分层结构
OceanBase对外提供的是与关系数据库一样的SQL操作接口，而内部却实现成一个线性可扩展的分布式系统。系统从逻辑实现上可以分为两个层次：分布式存储引擎层以及数据库功能层。
OceanBase一期只实现了分布式存储引擎，这个存储引擎支持如下特性：
- 支持分布式数据结构，基线数据逻辑上构成一颗分布式B+树，增量数据为内存中的B+树：
- 支持目前OceanBase的所有分布式特性，包括数据分布、负载均衡、主备同步、容错、自动增加/减少服务器等；
- 支持根据主健更新、插入、删除、随机读取一条记录，另外，支持根据主键范围顺序查找一段范围的记录。
二期的OceanBase版本在分布式存储引之上增加了SQL支持：
- 支持SQL语言以及MySQL协议，MySQL客户端可以直接访问；
- 支持读写事务；
- 支持多版本并发控制；
- 支持读事务并发执行。
从另外一个角度看，OceanBase融合了分布式存储系统和关系数据库这两种技术。通过分布式存储技术将基线数据分布到多台ChunkServer，实现数据复制、负载均衡、服务器故障检测与自动容错，等等；UpdateServer相当于一个高性能的内存数据库，底层采用关系数据库技术实现。我们后来发现，有一个号称“世界上最快的内存数据库”MemSQL采用了和OceanBase UpdateServer类似的设计，在拥有64个CPU核心的服务器上实现了每秒150万次单行写事务。OceanBase相当于GFS+MemSQL，ChunkServer的实现类似GFS，UpdateServer的实现类似MemSQL，目标是成为可扩展的、支持每秒百万级单行事务操作的分布式数据库。
