OceanBase与TiDB、CRDB的区别(2):架构可靠性(下)

本文探讨了TiDB依赖单独管理节点的架构,与CockroachDB的完全对等部署(无管理节点)和OceanBase的中间状态进行了对比。CockroachDB利用HLC和Gossip协议确保事务一致性,而OceanBase虽然接近CRDB但仍有集中式服务。作者指出CRDB的去中心化设计提供了更高的可靠性,但国产化过程中面临技术和商业挑战。
摘要由CSDN通过智能技术生成

上一篇说了TiDB通过设置单独的管理节点解决分布式事务(全局递增事务标识)和数据路由的问题,但也因此使系统可靠性受到了少量管理节点(PD节点)的制约。今天我们看一下Cockroachdb和OceanBase是如何应对这一问题的。

一,小强CRDB实现了完全对等部署

CRDB通过应用了HLC混合逻辑时钟、Gossip传染式协议等多种技术,以及复杂的工程实现,去掉了集群的管理节点、管理角色。CRDB实现集群所有节点自行管理、自行维护的完全对等部署架构,所有节点角色完全平等且一致(这在现实社会,简直是一个理想的乌托邦世界~~)。

CRDB采用混合逻辑时钟HLC为事务授时,使分布式数据库的事务标识不再依赖某一个节点进行全局统一管理,并通过一系工程实现保障事务强一致性,符合ACID特性。

HLC是以一种客观物理因果关系(在分布式系统中,消息接收端接到消息的时间总是晚于发送端发出的时间,这永不会改变)为基础,不依赖单一节点授时,也能使集群中不同的节点之间实现时间戳比较,是一种非常有意思的授时算法,有兴趣的同学可以查阅了解(后面有时间在聊一下CRDB如何应用HLC保证事务一致性)。

CRDB的元数据和用户数据一样,都是存储在集群内部的LSM-Tree结构中,也是通过range进行切片,然后分片副本中有一个是leader副本,承担集群的元数据变更产生的读写服务,follower副本通过raft同步。

crdb的元数据独特之处,增加了一层gossip协议,将元数据和系统状态等信息在集群中进行传播,并在每个节点内存中建立元数据缓存层,从而使计算节点在执行DML操作(增删改查)时一般只需要访问本地缓存就能获取数据路由信息。

gossip是一种最终一致性协议,所以节点本地的元数据缓存有可能过期,crdb中如果会话访问数据时发现本地元数据是过期的,会自动从存储层(元数据leader副本)拉取最新的信息,从而不会影响事务一致性。

crdb为了实现去中心化架构设计,不仅用了这些独特的技术,还拥有更复杂的工程逻辑,想要完全搞清楚是一件困难的事~~。(说到这里,又想起之前写的数据一致性的介绍,那里介绍了分布式事务的强一致性、数据副本的多数派一致性,现在又来了一个元数据缓存最终一致性...对想学原理的同学越来越不友好了....)

不管怎样,CRDB的分布式,是更加接近最终形态的完全分布式架构,没有任何管理节点,整个集群的运行不依赖任何单一或少量节点的健康,是一个完全对等部署的集群,不受少数个体影响、追求极致可靠性的系统;和TiDB完全依赖单独的PD节点进行事务和元数据管理的架构设计完全不同。

二、OceanBase是处于TiDB和CRDB中间状态。

OB经过了多个版本升级以后,在部署上更趋向对等部署,在外表上看起来已经和CRDB的架构一样,没有管理节点、计算节点、存储节点之分。但是OB集群中依然隐藏着两个集中式服务:GTS(全局时间戳服务)和RS(rootserver)。

GTS是按租户配置的,每个租户会单独启动一个,为该租户下所有事务分配时间戳标识。

所以OB系统中如果某租户的GTS服务所在节点发生故障,大约会导致该租户的所有业务被中断数十秒,故障影响的范围相比TiDB(全集群)已经有所缓解,但还没有达到CRDB那样对全局业务几乎没有影响的状态。同时,这样的设计也导致一套集群中的不同租户之间数据是完全隔离的,不允许产生跨租户事务,因为那样无法保障数据一致性。

OB中也存在单一的管理角色(RS服务),负责集群的节点状态监控、扩缩容管理等,这个角色同样被隐藏在集群中,可以通过查看系统表得知所在节点。

总结如下:

TiDB的架构是典型的多角色混搭分布式架构,需部署单独的管理节点(即PD节点),架构通俗易懂、方便理解学习和掌握(大部分分布式数据库,尤其是分库分表架构的数据库基本都是这样的模式,因为这样工程实现相对简单,对MySQL/Pg改造量小~~)。但集群会受到单一节点健康状态的影响,可靠性风险略高。

如果系统对可靠性要求较高,那么应用TiDB时可能要在整体解决方案上好好设计一下了。

另外其采用存算分离的部署架构,3种不同的角色如果都部署到独立节点上,那么最小也需要7-9个节点起步,对中小型业务系统而言投入成本有点高了。

OB在这方面似乎要好一点,至少部署上可以对等,资源占用降低了。

但从可靠性架构角度看,最好的还是CRDB,部署对等、功能、服务也都完全对等,没有单点风险(或者说单点风险本降到了最低),系统可靠性更高。

基于这样的独特性,且CRDB也是开源产品,按理说在国内早就遍地国产了...但到现在相似架构的产品还鲜为人知。不像MySQL改一个名字就实现自主可控,前几年有几家基于CRDB的国产厂商,但最后大都放弃了,原因就是太难了。另外,CRDB修改了它的开源协议,也导致国内厂商即便用了其代码也不再进行宣传了,我知道是有几个不错的公司在坚持crdb魔改的(想试用CRDB特性、且有信创任务的同学可以私信沟通)。

好的架构才能决定产品的未来~,国产有些时候略显急功近利了。一、两个角度对比产品是片面的,后续会尝试从更多角度分析,希望能够展现出全部的真实。

关注公众号:天下观查

  • 17
    点赞
  • 23
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 1
    评论
1. OceanBaseTiDB都是分布式数据库,但是OceanBase是基于Oracle的架构,而TiDB是基于MySQL的架构。 2. OceanBase支持更多的数据类型,包括空间数据类型和JSON数据类型,而TiDB只支持常规的数据类型。 3. OceanBase支持更多的索引类型,包括B-tree、Hash、Bitmap和R-tree索引,而TiDB只支持B-tree索引。 4. OceanBase支持更多的事务隔离级别,包括Read Committed、Serializable和Snapshot Isolation,而TiDB只支持Read Committed和Repeatable Read。 5. OceanBase支持更多的分区方式,包括Range、Hash和List分区,而TiDB只支持Range分区。 6. OceanBase支持更多的分布式事务协议,包括2PC和XA,而TiDB只支持2PC。 7. OceanBase支持更多的分布式锁机制,包括行锁、表锁和分布式锁,而TiDB只支持行锁和表锁。 8. OceanBase支持更多的分布式存储引擎,包括OLTP和OLAP存储引擎,而TiDB只支持OLTP存储引擎。 9. OceanBase支持更多的分布式查询优化器,包括Cost-based和Rule-based优化器,而TiDB只支持Rule-based优化器。 10. OceanBase支持更多的分布式执行引擎,包括基于线程池和协程池的执行引擎,而TiDB只支持基于线程池的执行引擎。 11. OceanBase支持更多的分布式数据迁移工具,包括基于物理复制和逻辑复制的数据迁移工具,而TiDB只支持基于逻辑复制的数据迁移工具。 12. OceanBase支持更多的分布式备份和恢复工具,包括基于物理备份和逻辑备份的备份和恢复工具,而TiDB只支持基于逻辑备份的备份和恢复工具。 13. OceanBase支持更多的分布式监控和诊断工具,包括基于Prometheus和Grafana的监控和诊断工具,而TiDB只支持基于TiUP的监控和诊断工具。 14. OceanBase支持更多的分布式安全机制,包括基于SSL和Kerberos的安全机制,而TiDB只支持基于SSL的安全机制。 15. OceanBase支持更多的分布式扩展方式,包括基于水平扩展和垂直扩展的扩展方式,而TiDB只支持基于水平扩展的扩展方式。 16. OceanBase支持更多的分布式部署方式,包括基于Docker和Kubernetes的部署方式,而TiDB只支持基于TiUP的部署方式。 17. OceanBase支持更多的分布式语言接口,包括Java、C++、Python和Go等语言接口,而TiDB只支持Java和Go语言接口。 18. OceanBase支持更多的分布式数据格式,包括ORC、Parquet和Avro等数据格式,而TiDB只支持CSV和JSON等数据格式。 19. OceanBase支持更多的分布式数据集成方式,包括基于Kafka和Flume的数据集成方式,而TiDB只支持基于TiCDC的数据集成方式。 20. OceanBase支持更多的分布式数据分析工具,包括基于Spark和Flink的数据分析工具,而TiDB只支持基于TiDB-Binlog的数据分析工具。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

天下观查

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值