TiDB是一套开源分布式HTAP(Hybrid Transactional/Analytical Processing)数据库,同时提供MySQL与Spark SQL接口。
底层的数据存储和计算资源可以动态扩展,前端的数据访问服务是以兼容MySQL的协议开放出来。
TiDB 作为开源的分布式关系数据库,其特点是几乎可以100% 兼容MySQL接口,也兼容 MySQL 的语法和协议,在保证不丧失 ACID 事务的前提下,能够弹性伸缩,高可用,可以同时处理OLTP和OLAP工作负载,不再需要ETL。
TiDB整体架构图
要深入了解 TiDB 的水平扩展和高可用特点,首先需要了解 TiDB 的整体架构。
TiDB产品的整体架构是高度分层的,由分布式SQL层(TiDB)、分布式KV存储引擎(TiKV)以及管理整个集群的PD(Placement Driver)模块组成。水平扩展是TiDB的一大特点,这里所说的水平扩展包括两方面:计算能力和存储能力。
TiDB 集群主要分为三个组件:
TiDB Server
TiDB Server 负责接收 SQL 请求,处理 SQL 相关的逻辑,并通过 PD 找到存储计算所需数据的 TiKV 地址,与 TiKV 交互获取数据,最终返回结果。 TiDB Server 是无状态的,其本身并不存储数据,只负责计算,可以无限水平扩展,可以通过负载均衡组件(如LVS、HAProxy 或 F5)对外提供统一的接入地址。
PD Server
Placement Driver (简称 PD) 是整个集群的管理模块,其主要工作有三个: 一是存储集群的元信息(某个 Key 存储在哪个 TiKV 节点);二是对 TiKV 集群进行调度和负载均衡(如数据的迁移、Raft group leader 的迁移等);三是分配全局唯一且递增的事务 ID。
PD 是一个集群,需要部署奇数个节点,一般线上推荐至少部署 3 个节点。
TiKV Server
TiKV Server 负责存储数据,从外部看 TiKV 是一个分布式的提供事务的 Key-Value 存储引擎。存储数据的基本单位是 Region,每个 Region 负责存储一个 Key Range (从 StartKey 到 EndKey 的左闭右开区间)的数据,每个 TiKV 节点会负责多个 Region 。TiKV 使用 Raft 协议做复制,保持数据的一致性和容灾。副本以 Region 为单位进行管理,不同节点上的多个 Region 构成一个 Raft Group,互为副本。数据在多个 TiKV 之间的负载均衡由 PD 调度,这里也是以 Region 为单位进行调度。
HTAP给开发者提供了一个实时数据分析方面的新思路,不需要再去维护另一个离线的数据仓库,既减轻了ETL的工作,又能节省很大一部分建立数据仓库所用到的存储和计算成本,HTAP将是未来的重要趋势。
TiDB的四个主要应用场景。
一、MySQL分片与合并
对于已经在用MySQL的业务,分库、分表、分片、中间件是常用手段,随着分片的增多,跨分片查询是一大难题。TiDB在业务层兼容MySQL的访问协议,PingCAP做了一个数据同步的工具——Syncer,它可以把TiDB作为一个MySQL Slave,将TiDB作为现有数据库的从库接在主MySQL库的后方,在这一层将数据打通,可以直接进行复杂的跨库、跨表、跨业务的实时SQL查询。过去的数据库都是一主多从,有了TiDB以后,可以反过来做到多主一从。
二、直接替换MySQL
第二类场景是用 TiDB 直接去替换 MySQL。如果你的IT架构在搭建之初并未考虑分库分表的问题,全部用了 MySQL,随着业务的快速增长,海量高并发的 OLTP 场景越来越多,如何解决架构上的弊端呢?
在一个 TiDB 的数据库上,所有业务场景不需要做分库分表,所有的分布式工作都由数据库层完成。TiDB 兼容 MySQL 协议,所以可以直接替换 MySQL,而且基本做到了开箱即用,完全不用担心传统分库分表方案带来繁重的工作负担和复杂的维护成本,友好的用户界面让常规的技术人员可以高效地进行维护和管理。另外,TiDB 具有 NoSQL 类似的扩容能力,在数据量和访问流量持续增长的情况下能够通过水平扩容提高系统的业务支撑能力,并且响应延迟稳定。
三、用做数据仓库
TiDB 本身是一个分布式系统,第三种使用场景是将 TiDB 当作数据仓库使用。
当然,因为 OLAP 的范畴非常大,TiDB 的 SQL 也有搞不定的情况,为此 PingCAP 开源了 TiSpark,TiSpark 是一个 Spark 插件,用户可以直接用 Spark SQL 实时地在 TiKV 上做大数据分析。
四、作为其他系统的一个模块
TiDB 是一个传统的存储跟计算分离的项目,其底层的 Key-Value 层,可以单独作为一个 HBase 的 Replacement 来用,它同时支持跨行事务。TiDB 对外提供两个 API 接口,一个是 ACID Transaction 的 API,用于支持跨行事务;另一个是 Raw API,它可以做单行的事务,换来的是整个性能的提升,但不提供跨行事务的 ACID 支持。用户可以根据自身的需求在两个 API 之间自行选择。例如有一些用户直接在 TiKV 之上实现了 Redis 协议,将 TiKV 替换一些大容量,对延迟要求不高的 Redis 场景。
原文链接:
TiDB 简介与整体架构
https://blog.csdn.net/wjl7813/article/details/79184398
黄东旭:TiDB 数据库的四大应用场景分析
https://cloud.tencent.com/developer/news/256652
声明:本站部分文章及图片源自用户投稿,如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢!