TiDB
2021-02-23 22:27:10 4 举报AI智能生成
TiDB
作者其他创作
大纲/内容
概念
mysql数据量超过一定行数之后效率变慢
分库分表
优点
大表拆分成小表，能水平扩展，通过部署多台数据库实例，提升整个集群的QPS/TPS
缺点
分表跨实例后有分布式事务管理问题，一旦数据库服务器宕机，事务不一致
分表后，对sql语句有一定的限制，实时报表统计类需求限制很大
需要维护的对象呈指数增长，mysql实例数，需要执行的sql变更数量等
NewSQL数据库
无限水平扩展能力
分布式强一致性，确保数据100%安全
完整的分布式事务处理能力和ACID特性
TiDB是NewSQL的代表产品
开源分布式关系型数据库
在线事务处理、在线分析处理的融合新数据库产品
一键水平伸缩
强一致性的多副本数据安全
分布式事务
兼容Mysql的协议和生态
100%的OLTP
在线事务处理
80%实时OLAP
更复杂的可以使用TiSpark
在线分析查询处理
故障自动恢复高可用
迁移便捷，运维成本极低
整体架构
组件
PD server
集群的管理者，存储元数据，负责复杂均衡， 分配全局唯一的事务id
会在TiKV server节点之间以Region为单位做调度，将部分数据迁移到新加的节点上
TiDB server
负责接收sql请求的，解析sql
通过PD存储的元数据找到数据存在在哪个TiKV，并和TiKV交互，将结果返回用户
简单的增加TiDB server，可以提高整体的处理能力，提供更高的吞吐
无状态的，可以水平无限扩容增加计算能力
TiKV server
真正存储数据的
本质上是key value 存储引擎
部署更多的TiKV server节点解决数据扩容的问题
数据是以Region为单位进行存储的
类似HBase的Region
默认3副本
通过Raft协议保证数据一致和高可用
与HDFS类似
通过RocksDB实现了TB级别的本地化存储
与HBase类似
通过LSM树作为存储方案
避免了B+树叶子节点膨胀带来的大量随机读写
从而提升整体的吞吐量
从而提升整体的吞吐量
Ti Spark
解决用户复杂OLAP查询需求的组件
TiDB Operate
负责云上部署的组件
推荐部署最少，3个TiKV,3个PD,2个TiDB
随着业务的增长按需增加TiKV和TiDB实例
核心特性
高度兼容MySQL
大多数情况下，无需修改代码即可从MySQL轻松迁移至TiDB，分库分表后MySQL集群也可以通过TiDB工具实时迁移
分布式事务
100%支持标准的ACID事务
一站式HTAP解决方案
典型OLTP行存数据库，兼具强大的OLAP性能，配合TiSpark，可提供一站式HTAP
一份存储同时处理OLTP&OLAP，无需传统繁琐的ETL过程
云原生SQL数据库
配合TiDB Operator可实现自动化运维，使部署、配置、维护变得简单
水平弹性扩展
通过简单的增加新节点可实现TiDB的水平扩展，按需扩展吞吐或存储，轻松应对高并发。海量数据场景
金融级高可用
基于Raft的多数派选举协议数据强一致性保证，且在不丢失大多数副本的前提下，可实现故障的自动恢复，无需人工介入
实现原理
TiDB
TiDB无状态，前端通过负载均衡组件对外提供服务。单个实例失效，会影响正在这个实例上进行的session。从应用角度，会出现单次请求失败的情况，重新连接后即可继续获得服务。
PD
集群，Raft协议保持数据的一致性，单个实例失效，如果不是leader节点，服务完全不受影响；
如果是leader，会重新选出新的Raft leader自动恢复服务。PD在选举过程无法对外提供服务，大概3秒。
推荐至少3台PD
如果是leader，会重新选出新的Raft leader自动恢复服务。PD在选举过程无法对外提供服务，大概3秒。
推荐至少3台PD
TiKV
Raft保持数据的一致性，默认保存3副本。单个节点失效，会影响这个节点上存储的所有Region
leader挂会中断服务，等待重新选举；follower，不会影响服务
默认3副本
当某个节点失效，并且在默认30min无法恢复时，PD会将其上的数据迁移到其他TiKV
TiDB存储和计算能力
存储扩展
增加TiKV
计算扩展
增加TiDB
0 条评论
下一页
