您好,登录后才能下订单哦!
这篇文章给大家介绍什么是分布式数据库和TIDB 整体架构,内容非常详细,感兴趣的小伙伴们可以参考借鉴,希望对大家能有所帮助。
TIDB 是一个分布式,强一致的可水平扩展的关系型数据库,在TIDB 设计之初,聚焦了四个设计的要点
1 水平扩展, 在设计之初水平扩展是最基本的需求,通过添加机器的方式扩展,存储的能力和计算的能力
2 高可用, TIDB 作为分布式数据库,节点众多,对于节点失效和数据库滚动升级,需要解决少量节点失效的问题
3 ACID 事务, 虽然部分数据库为了更高效的存储和处理数据,抛弃了SQL和事务,但在生产中的交易场景中,事务是非常重要的,另一个主要的原因在于如果事务的问题不在本地存储,而是业务解决或者中间件解决,这样做比较难做到高效
4 SQL 支持,提供MYSQL 的支持,让整体使用数据库变得简单
下面是一张TIDB 的结构图
TIDB 存储引擎是TIKV 数据库存储引擎,采用了分层的架构来实现
1 transaction
2 MVCC
3 raft
4 local kv storage
容灾与特点
高度分层,底层为ROCKSDB,通过raft来进行数据存储的高可用, 高度分层的主要原因是可以更独立的进行层次的切换。通过多副本的方式进行数据的存储,通过raft 进行强一致,多个副本中只有一个leader 其他节点为follower,其中leader 和follower值不固定的,在leader失效后,会选择follower通过算法变为leader的角色变换。
Raft 本身是支持一份数据的强一致的多副本,分布式数据如何切片,如何将不同的切片放到不同的位置上,这就需要一个分片的算法,基于hash的分片,或者基于range 划分,但由于数据库在查询中会涉及到一段连续值的查询的可能,则利用range分片比较合理。将存储KEY 的空间进行切分,主要根据KEY VALUE存储的阈值来进行,默认96MB进行数据的切分。
下图是一个多节点中某个节点 region 从节点 1 到 节点4的过程
则问题是在数据的迁移中,谁主导了整体迁移的操控,Placement Driver集群主导了。
具体可以看上图,另外在事务模型中,PD 的leader 会根据时间算法提供时间戳,作为事务的标签,整体以去中心化为设计理念。在TIDB 中3.0前以乐观锁为锁的设计,在数据事务处理中并不会上锁,而是在提交的过程中上锁。3.0提供了悲观锁,类似传统数据库的锁设计。
3 TIDB SQL 引擎
下图是一张TIDB SQL 层的整体的图形。
整体的SQL 处理流程, 如果是计算 COUNT , 则TIDB PD获知这些数据在那个 region 中,region 根据where 条件,将符合的条件的数据进行累加和,最终每个region将自己的累加和汇总到 TIDB SERVER ,在进行聚合SUM。
4 DDL 在线修改,TIDB 根据 f1-schema-change 的思想来设计整体DDL 操作。具体可以参考下面的文档,总结出几句话
1 给与修改DDL 操作一个时间范围
2 在DDL 操作中,每个region都会提供两种状态,可以删除和可写状态
3 租约的概念,在系统中设定的租约到期后,需要重载SCHEMA
关于什么是分布式数据库和TIDB 整体架构就分享到这里了,希望以上内容可以对大家有一定的帮助,可以学到更多知识。如果觉得文章不错,可以把它分享出去让更多的人看到。
免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。