Cloud + TiDB 技术解读

本文介绍了TiDB作为Cloud-native数据库的技术特点,包括其分布式架构和弹性伸缩能力。TiDB与Kubernetes的整合使得数据库在云上的部署和运维更加便捷。文章详细阐述了TiDB的组件、Kubernetes的StatefulSet和Operator如何管理有状态服务,以及如何通过tidb-operator实现自动化运维、动态扩缩容和资源隔离。TiDB在Kubernetes上的高可用性通过多副本、智能调度和故障恢复机制得以保证。
摘要由CSDN通过智能技术生成

作为一款定位在 Cloud-native 的数据库,现如今 TiDB 在云整合上已取得了阶段性的进展。日前 Cloud TiDB 产品 在 UCloud 平台正式开启公测,TiDB 弹性伸缩的特性在 Cloud 提供的基础设施支持下发挥的淋漓尽致。在感受云数据库魅力的同时,让我们来一探究竟,看一下 TiDB 与 Cloud 背后的技术秘密。

TiDB 的架构

首先还是要先从 TiDB 的架构说起,TiDB 和传统的单机关系型数据库有什么不同?相信长期以来一直关注 TiDB 的同学都比较了解了,但这里还是科普一下。TiDB 作为一个开源的分布式数据库产品,具有多副本强一致性的同时能够根据业务需求非常方便的进行弹性伸缩,并且扩缩容期间对上层业务无感知。TiDB 的主体架构包含三个模块,对应 GitHub 上面 PingCAP 组织下的三个开源项目,TiDB / TiKV / PD:

  • TiDB 主要是负责 SQL 的解析器和优化器,它相当于计算执行层,同时也负责客户端接入和交互;
  • TiKV 是一套分布式的 Key-Value 存储引擎,它承担整个数据库的存储层,数据的水平扩展和多副本高可用特性都是在这一层实现;
  • PD 相当于分布式数据库的大脑,一方面负责收集和维护数据在各个 TiKV 节点的分布情况,另一方面 PD 承担调度器的角色,根据数据分布状况以及各个存储节点的负载来采取合适的调度策略,维持整个系统的平衡与稳定。

上面的这三个模块,每个角色都是一个多节点组成的集群,所以最终 TiDB 的架构看起来是这样的。

由此可见,分布式系统本身的复杂性导致手工部署和运维的成本是比较高的,并且容易出错。传统的自动化部署运维工具如 Puppet / Chef / SaltStack / Ansible 等,由于缺乏状态管理,在节点出现问题时不能及时自动完成故障转移,需要运维人员人工干预。有些则需要写大量的 DSL 甚至与 Shell 脚本一起混合使用,可移植性较差,维护成本比较高。

TiDB 与 Kubernetes 的整合历程

在云时代,容器成为应用分发部署的基本单位,而谷歌基于内部使用数十年的容器编排系统 Borg 经验推出的开源容器编排系统 Kubernetes 成为当前容器编排技术的主流。作为 Cloud Native Database,TiDB 选择拥抱容器技术,并与 Kubernetes 进行深度整合,使其可以非常方便地基于 Kubernetes 完成数据库的自动化管理。

Kubernetes 项目可以说是为 Cloud 而生,利用云平台的 IaaS 层提供的 API 可以很方便的和云进行整合。这样我们要做的事情就很明确了,只要让 TiDB 与 Kubernetes 结合的更好,进而就实现了和各个云平台的整合, 使得 TiDB 在

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值