淘宝Oceanbase云存储系统实践

写事务只操作UpdateServer，读事务需要同时读取ChunkServer和UpdateServer。某些操作，比如OLAP分析型操作可能需要涉及多个ChunkServer上的数据，这时将引入一个新的MergeServer模块将请求拆分到不同的ChunkServer，合并每个ChunkServer的返回结果后执行排序、分组、分页等操作。静态数据在ChunkServer中保存三份，UpdateServer通过Linux HA的方式进行双机热备以保证可靠性。RootServer的访问压力很小，一般可以和UpdateServer部署在相同节点上，并采用相同的Linux HA方式。Oceanbase的UpdateServer在同一个IDC机房采用实时同步的方式保证强一致性，这意味着写事务只有等到主机和备机都操作成功后才返回客户端。Oceanbase支持跨IDC机房的异步准实时热备，多个机房之间的数据延迟为秒级。

Oceanbase的静态数据和BigTable类似，数据被分为几十到几百MB不等的子表，每个子表的磁盘存储格式为SSTable，通过bloom filter、block cache、key value cache等方式进行优化。SSTable支持根据column group按列存储，从而高效地支持OLAP分析。动态数据采用copy-on-write的方式实现了单机内存中的B+树，在单写多读的应用场景下不需要加锁。

Oceanbase静态数据构成一棵分布式B+树，动态数据为单机B+树。与线下MapReduce批处理应用不同，在线存储应用的更新量一般比较小，动态数据服务器不会成为性能瓶颈。这也就意味着，淘宝Oceanbase用一种更为简便的方式在底层实现了和其他互联网巨头类似的B+树数据结构，并且能够高效地支持跨行跨表事务。当然，当数据量增长到万亿级或者数据更新更快时，需要考虑将动态数据服务器的方案由集中式修改为分布式。我们也考虑过多UpdateServer方案的设计，但由于短期内看不到明确的需求，暂时没有实现，目前我们认为可以通过硬件的方法，比如万兆网卡、更好的CPU、更大的内存和SSD来解决。

Oceanbase还实现了一些分布式系统中常见的特性，比如自动负载均衡、在线修改Schema、内置压缩解压缩等。另外，Oceanbase系统里面没有随机写操作，因此天然适应SSD存储介质，很好地弥补了磁盘的IOPS不足这个问题。

Oceanbase应用效果和经验

Oceanbase首先应用在淘宝收藏夹并取得了明显的效果。淘宝收藏夹最初采用MySQL分库/分表的方式实现，通过使用Oceanbase，机器数由原来的16台主加上16台备共32台减少到12台静态数据服务器加上2台动态数据服务器，大大节省了机器资源。另外，目前应用的很多问题在Oceanbase中是通过更好的架构来解决，单机层面基本没做优化，相信后续还有很大的提升空间。在这过程中，我们也积累了一些经验教训。

展望

Oceanbase目前的主要工作是应用推广，根据应用的需求来逐步完善Oceanbase系统，实现互联网数据库的构想。我们已经开始和淘宝的业务团队开展了千万级数据秒级实时分析的OLAP项目。另外，Oceanbase还在考虑整合分布式Blob存储系统。随着应用推广的深入和Oceanbase系统的优化，希望能在合适的时间进行数据库新基准TPC-E的测试。

另外一个振奋人心的消息是：Oceanbase将在合适的时间点开源。相信通过业界同仁一起努力，一定能够将云存储这个问题解决好！