最近好几个粉丝给我转了这篇发表在公众号OceanBase上的OceanBase CTO的雄文： OceanBase CTO 杨传辉： 下一代企业级分布式数据库的一体化设计 ，希望我能够帮忙解读一下。
这篇文章写的很有意思，值得深入解读一下。 特别是对比市面上的竞争对手们的架构解读，就更有意思了。
文章里面第一个观点是关于存储计算分离的看法。
业界有三种存储计算分离方案：
第一种本质是基于中间件分库分表，后端的数据库表示存储，中间件表示计算，这种方案是真正的存储计算分离吗？ 显然不是，我也把这种方案叫做“伪存储计算分离”；
第二种把系统划分为 SQL、事务和分布式 KV 层，分布式 KV 表示存储，SQL 和事务表示计算，存储和计算采用松耦合设计，这种方案能够解决可扩展的 SQL 处理问题，但每次操作都涉及到计算和存储之间的远程访问，且事务相关元数据存储到分布式 KV 表格中，增加了事务处理的额外开销，牺牲了性能；
第三种采用紧耦合设计，SQL、事务和 KV 表示计算，KV 层数据块依赖的分布式文件系统表示存储。 这种方案来自于经典数据库的 IOE 架构，SQL、事务和 KV 层表示计算，底层依赖 EMC 的 SAN 存储。 Amazon Aurora 借鉴了经典数据库的存储计算分离架构，并在云原生环境下发扬光大，成为最终的事实标准。
为了追求极致性能， 我认为，企业级分布式数据库应该向经典数据库学习原生存储计算分离技术 ，我推荐第三种方案。
第二种最经典的代表是开源的TiDB数据库。下面是开源的TiKV，上面是SQL层，存储用KV，这样一来scale out的解决方案就会很方便。同样经典的就是TiDB模仿的对象，谷歌的Spanner，下面用的是BigTable上面再构建起Spanner层。
这种做法最大的好处就是scale out做起来很好。最大的坏处，就是单节点性能不行。客户是不是愿意牺牲单节点性能，从而获得更好的scale out，我想这个问题见仁见智。每个人可能会有不同的观点。
OceanBase CTO杨传辉是不赞同这种方式的，他觉得类似Aurora这样的计算存储分离才是应该追求的目标。OceanBase显然是冲着这条路去的。
但是最开始的Aurora版，底下是一个大磁盘，上面是计算层。这个大磁盘同时具备了Log merge的能力，这样的做法性能是不是可以做到单节点极致其实也存疑。
至于阿里巴巴另外一个数据库PolarDB，下面一个大磁盘接上单机MySQL，根本就没办法谈Scale out的事情了。PolarDB-X倒是更可能Scale out。但是早年的PolarDB-X上面三节点备份，下面文件系统再做三备份，一个记录写9份的骚操作，我没有在第二个数据库里见过。至于现在PolarDB-X演化的怎么样了，我也不好判断。
OceanBase实际上怎么做的，技术细节也没有公布出来，所以我也很难下一个结论说，OceanBase的实际实现，能够同时满足单节点性能最优和很好的Scale out能力。这两者本身就是需要互相妥协的。做好了，需要极高的工程能力。
下面是OceanBase CTO关于Paxos和Raft的看法：
Raft 协议是 Paxos 协议的一种简化，原理是在 Paxos 协议基础上增加了一个限制，要求按顺序投票，也就意味着数据库 redo 日志顺序同步。Raft 协议的好处是实现简单，但每个分区只能顺序同步，并发同步性能较差，在弱网环境下事务卡顿现象概率较高；Paxos 协议支持乱序同步，虽然实现更加复杂，但并发同步性能好，在弱网环境下事务卡顿现象概率较低。Raft 类系统发明了一个概念叫：Multi-Raft，指的是每个分片运行一个 Raft 协议。这个概念和经典的 Multi-Paxos 是不对等的，Multi-Paxos 指的是一个分片内做并发，Multi-Raft 指的是多个分片之间做并发，如果单个分片写入量很大，仍然是会产生性能瓶颈的。
Paxos 和 Raft 两种协议都是合理的做法，我个人建议采用并发性能更高的原生 Paxos 协议，这也是顶尖互联网公司在大规模分布式存储系统的主流做法，包括 Google Spanner，Microsoft Azure，Amazon DynamoDB，OceanBase 等等。
简单总结, Raft不如Paxos，因为并发性能高。顶尖互联网公司都用Paxos。这也很有意思。
我们知道目前有两个数据库产品用了Raft，一个是阿里云的PolarDB。它用了自己改进的Paralle Raft协议。另外一个是TiDB。其他的数据库产品，尤其是顶尖互联网公司的，我知道的都是Paxos协议。
这当然有历史原因，Raft出来的比较晚。但是也有现实的原因，Paxos协议的实现有很多很难的地方，一不小心就栽坑。我自己亲自经历的就看到过几个大Bug，导致数据丢失，都是Paxos协议实现细节上不对导致的。要实现一个好的Raft，估计难度上会相对容易一些。这当然也会成为某些项目的选择。
有关HTAP的观点如下：
HTAP 也是分布式数据库领域的一个热门概念。有两种做法：
第一种是主备库物理隔离，主库做 OLTP，备库做 OLAP，主备之间通过 redo 日志做同步，备库与主库之间有一定的延迟。第二种是在同一套引擎实现 OLTP 和 OLAP 混合负载，区分 OLTP 和 OLAP 请求所在的资源组，对资源组进行逻辑隔离。
第一种方案实现相对简单，但由于产生了更多数据冗余，性价比较低；第二种方案实现相对复杂，但采用一体化设计，性价比更高。第二种方案来自经典数据库，例如 Oracle、SQL Server。
我认为，企业级分布式数据库应该学习 HTAP 技术，采用第二种方案。
HTAP就是一套数据库同时做两件事情，同时做TP和AP。这当然并不是什么新概念。在早先版本的TiDB里面，Raft增加了单纯的listener，作为备库，备库是列式的存储。有别于基于KV的OLTP workload的存储。
TiDB的AP引擎是魔改ClickHouse得来的。主要利用列存进行AP处理。但是也可以在有必要的时候从行存中读取。总体来说，还是两套引擎。TiDB 5.0版本，据说引入了类似GreenPlum的MPP架构，使得其对OLAP的处理更上一层楼。
当然总的来说，我还是不太清楚现在两套引擎各自为政，还是说已经开始融合了。但是不管怎么样，融合MySQL和ClickHouse这种事情，我这点Engineer水平是不敢去随波尝试的。
PolarDB本身的AP能力很一般。PolarDB-X的最新版本，搞的有点像GreenPlum那样的MPP架构，但是从已经知道的细节来看，我也无法分辨这OLTP/OLAP是一套引擎还是两套引擎。
OceanBase的理念和观点，在这篇文章里已经阐述的比较清楚了。但是我还是想等一篇公开发表在顶级会议上的论文，通过阅读论文可以让我有更好的理解和判断，现在OceanBase的架构到底怎么样。OceanBase CTO这篇技术雄文里面描述的东西是不是真的实现了，又是怎么样实现的。不然的话，我也不好判断，到底是不是真牛逼。
