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