最近一直在看分布式数据库的设计,不过分布式数据库大体在国内逃离不了两个设计的架构, GOOGLE 系, 和 POSTGRES-X 系, 偶然看了OB的设计,感觉的确是不一样,想法是脱离了这两个系列的思维方式.
下面我们看一张图, 这张图是OCEANBASE早期的架构图.
OB 主要的组件分为 root server , update server, merge server , chunk server.
root server 主要控制的是数据均分实现数据在多个节点的存储的功能
update server 是OB 在早期设计的重点, OB 的数据主要分为两个部分
数据更新部分和数据基线部分, 这部分也是通过OB 针对早期电商的业务而来的, 数据的更新与历史数据的量级差别很大, 早期会将最近一段频繁更新的数据存储在UPDATE SERVER 中, 然后定期将数据更新到基线节点.
merge server merge server 主要的功能是将UPDATE SERVER 中的数据与基线数据进行合并的服务, merge server 的功能中还有接受分析用户的SQL请求, 经过词法分析, 语法分析, 查询优化后,将用户需要反馈的数据从基线chunkserver 以及 update server上提取后返回给客户.
chunk server 就是基线数据的存放地,这实际上是数据的分布式存储的实现.其中存储了UDPATE 数据与原有数据的合并, 其中CHUNK SERVER 的数据也是通过SSTABLE (LSM tree) 进行数据存储的, 根据LSM TREE 的独特性, 数据是有序存储的通过二分查找的方式来进行数据的提取.
客户的数据访问是通过连接到root server 获取 MergeServer 的地址列表, 根据获取到的地址列表访问merger server 对整体的数据进行访问.
这个时期的OB的设计主要的服务的对象就是TB, 并且这个时期的OB 数据库中的设计中有几个问题
1 为了降低2PC数据提交中的延迟问题, 在每个OB的集群中,事务都是通过UPDATE SERVER 进行数据的更改的, 这里一个OB的集群中只有一个 UPDATE SERVER , 这就造成了单点的问题, 所以在部署时要求一个集群中唯一的UPDATE SERVER 的性能要求会比较高. 通过强一直的的方式用两台UPDATE 做互备.
2 数据的定期的MERGE ,用户在访问数据会涉及,chunk server 和 updateserver 两个部分, 所以定期将UPDATE SERVER的数据合并到chunk server 是一项必须的工作,一般会选择业务的低峰期来进行数据的更新和合并.
所以这个时期的设计中, UPDATE SERVER 相当于一个数据"中期" 的缓存功能. 以上是OB 早期的设计, 后面 OB 慢慢进化到了 2.0 的结构.
下图是OB 官网的架构图, 从图上看整体的架构有了很大的变化,
从官网上看到的, 虽然整体的结构有了很大的变化, 但总体的设计理念是没有变化的, UDPATE SERVER 从实体的服务器,变换为内存结构的数据存储方式同时数据的存储方式也变为了类似 TIBD 的数据存储方式(个人感觉类似,如有不对请指正)
同时也部分与OB 有关的文字也指出,为什么OB 不使用RAFT 协议,而是使用PAXOS, 这也从侧面看出 POLARDB 为什么也使用PAXOS 协议来进行 POLARDB 的高可用成型.
从OB 的早期设计,到目前2.0 的版本, 可以看出整体架构的迁移和变化, 以及一些设计中的考量,例如其中提到的关于数据合并的方式中,并没有采用ROCKDB的合并方式,而是采用变动的数据块进行合并的方式,提高了数据合并的效率.
等等
最后提到另类, 与目前两大阵营的分布式数据库比较, OB在结构图中并没有这些数据库中带有的事务集中管理的机制, 或许正是早期设计中嫌弃 2PC 的机制,导致与其他的分布式数据库在MVCC 分布式事务处理的理念不同.
参考文字:
https://zhuanlan.zhihu.com/p/59926633
