代码两边都没开源，git上面有三年前的OceanBase代码，感兴趣的可以研究一下，这篇文章主要就从架构上面分析OceanBase跟Oracle的区别，找到OB胜出最本质的原因，OB这边的资料主要来源是官方文档https://oceanbase.alipay.com/docs/oceanbase/OceanBase%E6%A6%82%E8%A7%88
1.分布式架构
Oracle使用最广的RAC集群是一种基于share disk的架构，多实例跑在不同的服务器上，共享数据存储。
OB的分布式架构，我觉得跟kafka的思想类似（OB的开发者更多的去类比google的F1等），是一种分区+副本的架构，每个分区有多个副本，副本分leader，follower，主副本所在的zone，被称为Primary Zone ，选主和日志同步采用的也是paxos算法，机制跟kafka如出一辙。
小结：在架构上，oracle rac是一种share disk的模式，这种集群可以支持的节点数是有限的。
OceanBase是一种share nothing的模式，是真正的分布式，分区数可以成千上万，每个分区可以三副本，可以五副本（对于普通单表，OB的一个分区就是一张表，而对于分区表，OB的一个分区对应表的一个分区）。在高可用方面，OceanBase在架构层面就天然比oracle要强，之前的云栖大会也演示过现场把某个节点的服务器网线剪断，服务在26秒之内恢复正常。Oracle集群如果存储服务挂掉，那么整个集群都将不可用。
2.存储
Oracle采用的是内存bufferCache+磁盘IO的模式。对数据的读写尽量在内存bufferCache中进行，会有进程负责将bufferCache中的冷数据和脏数据写入到磁盘中。
OB把数据分成基线数据和增量数据，增量数据放在内存中，叫MemTable，基线数据放在ssd盘中，叫SSTable，大部分dml操作都在内存中完成（官网文档不是很严谨，说所有DML操作都在内存中完成），性能会非常高。内存中的增量数据达到一定规模后，触发增量数据和基线数据的合并，即增量数据落盘。
写操作完全是内存操作比较好理解，写完内存中的MemTable返回即可，后续再异步的跟基线数据合并落盘。
为了增加读操作的性能，会有Block Cache和Row Cache两层内存cache，对于不存在的行的空查，会有布隆过滤器过滤。但是读操作不能保证是完全的内存操作，比如基线和增量里面都有id=1的数据记录，基线数据中该记录为A，C，D，增量数据中该记录为B，C，F。按照上图，会有Block Cache和Row Cache，如果这两层Cache中包含id=1的数据记录，那么这个查询是内存操作可以理解，内存中一合并就好了。但是如果这两层Cache不包含id=1的数据记录呢，那么肯定是要对基线数据直接进行一次合并的，那就会有磁盘IO，因为Cache不可能包含全量的基线数据。之前看到文章说，单机的情况下，OceanBase性能是不如Oracle的。
3.总结
个人理解，OB之所以在性能测试上面能击败Oracle，最主要还是依赖分布式的架构，其他的点：比如存储，sql，分布式事务等都是为此服务的。而且单机的Oracle性能比OB要强，这点上，OB提升的空间还很大，如果将来OB的单机性能能够接近或者超过Oracle，那么OB的性能还将上升一个台阶。
绝大多数的互联网公司发展到一定规模，出于性能和成本的考虑，会有去Oracle的计划（淘宝也有这个过程，CBU的总裁七公就是淘宝的Oracle元老），替代者往往是Mysql。这么做的问题点就是Mysql在做分布式的架构时，需要中间件的辅助，同时需要运维人员比较强的能力，OceanBase最大的优势就是可以直接提供出一个商业化、分布式的关系型数据库，配合上云，那么对于去O的公司来说，OceanBase绝对会是个非常有竞争优势的产品，期待OB外部商业化的成功。
