理解TiDB

TIDB是一款分布式关系型数据库。它同时支持在线事务处理(OLTP)和在线分析处理(HTAP)。

它的处理时延在几十ms到若干秒。承诺在秒级内响应。支持乐观事务、悲观事务、可重复读(快照)和读已提交

Overview

tidb-architecture-v3.1

PD

是一个中心管理节点。管理整个集群的信息。记录表和KV的关系,记录KV的region分布。分配唯一id。

TiDB

是计算引擎,兼容mysql客户端。把收到的sql得到执行计划,把关系型数据转化为KV数据,并发送给TiKV或者TiFlash来执行,并返回数据

TiKV

是一个行KV存储节点,每个TiKV会存储若干region的KV数据,并通过raft来同步数据。使用rocksdb来存储KV对

TiFlash

是一个列KV存储节点,用于在线分析。通过raft同步TiKV的数据,保持强一致性

TiSpark

兼容spark客户端

五大特性

  • 一键水平扩容/缩容(通过TiUP)

    可按需对计算、存储分别进行在线扩缩容

  • 金融级别高可用

    通过raft算法同步数据

  • 实时HTAP

    为HTAP提供列式存储引擎TiFlash。TiFlash通过Raft同步TIKV的数据,确保TiFlash与TiKV的强一致性

  • 云原生分布式数据库

  • 兼容mysql

    计算引擎TiDB兼容mysql客户端,应用程序可以快速从mysql迁移到TIDB

基本API

通过sql操作,计算引擎会自动选择TiKV还是TiFlash来返回数据

生产环境推荐硬件

组件 CPU 内存 硬盘类型 网络 实例数量(最低要求)
TiDB 16 核+ 48 GB+ SAS 万兆网卡(2 块最佳) 2
PD 8 核+ 16 GB+ SSD 万兆网卡(2 块最佳) 3
TiKV 16 核+ 64 GB+ SSD 万兆网卡(2 块最佳) 3
TiFlash 48 核+ 128 GB+ 1 or more SSDs 万兆网卡(2 块最佳) 2
TiCDC 16 核+ 64 GB+ SSD 万兆网卡(2 块最佳) 2
监控 8 核+ 16 GB+ SAS 千兆网卡 1

迁移工具

名称 使用场景 上游(或输入源文件) 下游(或输出文件) 主要优势 使用限制
TiDB DM 用于将数据从与 MySQL 协议兼容的数据库迁移到 TiDB。 MySQL,MariaDB,Aurora,MySQL TiDB 一体化的数据迁移任务管理工具,支持全量迁移和增量同步;支持对表与操作进行过滤;支持分库分表的合并迁移。 建议用于 1TB 以内的存量数据迁移。
Dumpling 用于将数据从 MySQL/TiDB 进行全量导出。 MySQL,TiDB SQL,CSV 支持全新的 table-filter,筛选数据更加方便;支持导出到 Amazon S3 云盘 如果导出后计划往非 TiDB 的数据库恢复,建议使用 Dumpling;如果是往另一个 TiDB 恢复,建议使用 BR。
TiDB Lightning 用于将数据全量导入到 TiDB。 Dumpling 输出的文件;CSV 文件;从本地盘或 Amazon S3 云盘读取数据。 TiDB 支持迅速导入大量新数据,实现快速初始化 TiDB 集群的指定表;支持断点续传;支持数据过滤。 如果使用 Local-backend 进行数据导入,TiDB Lightning 运行后,TiDB 集群将无法正常对外提供服务。如果你不希望 TiDB 集群的对外服务受到影响,可以参考 TiDB Lightning TiDB-backend 中的硬件需求与部署方式进行数据导入。
Backup & Restore (BR) 通过对大数据量的 TiDB 集群进行数据备份和恢复,实现数据迁移。 TiDB SST;backup.meta 文件;backup.lock 文件 适用于向另一个 TiDB 迁移数据。支持数据冷备份到外部存储,可以用于灾备恢复。 BR 恢复到 TiCDC / Drainer 的上游集群时,恢复数据无法由 TiCDC / Drainer 同步到下游。BR 只支持在 new_collations_enabled_on_first_bootstrap 开关值相同的集群之间进行操作。
TiCDC 通过拉取 TiKV 变更日志实现的 TiDB 增量数据同步工具,具有将数据还原到与上游任意 TSO 一致状态的能力,支持其他系统订阅数据变更。 TiDB TiDB,MySQL,Apache Pulsar,Kafka,Confluent 提供开放数据协议 (TiCDC Open Protocol)。 TiCDC 只能同步至少存在一个有效索引的表。暂不支持以下场景:暂不支持单独使用 RawKV 的 TiKV 集群。暂不支持在 TiDB 中创建 SEQUENCE 的 DDL 操作和 SEQUENCE 函数。
TiDB Binlog 用于 TiDB 集群间的增量数据同步,如将其中一个 TiDB 集群作为另一个 TiDB 集群的从集群。 TiDB TiDB,MySQL,Kafka,增量备份文件 支持实时备份和恢复。备份 TiDB 集群数据,同时可以用于 TiDB 集群故障时恢复。 与部分 TiDB 版本不兼容,不能一起使用。
sync-diff-inspector 用于校验 MySQL/TiDB 中两份数据的一致性。 TiDB,MySQL TiDB,MySQL 提供了修复数据的功能,适用于修复少量不一致的数据。 对于 MySQL 和 TiDB 之间的数据同步不支持在线校验。不支持 JSON、BIT、BINARY、BLOB 等类型的数据。

部署

Labels设计

tidb-three-data-centers-in-two-cities-deployment-03

同城多中心

tidb-deploy-3dc

两地三中心

tidb-three-data-centers-in-two-cities-deployment-01

tidb-three-data-centers-in-two-cities-deployment-02

热点

  • PD会检测Region是否存在热点,把不同的热点region分配到不同的机器上

  • PD调度的最小单位是region。再细粒度的调度可以通过load base split。

    Load Base Spit会检测10s内超过阈值的region,并再合适的位置把region拆分,并把region分配到不同的计算机器上。被拆分的region不会被迅速merge。PD会跳过这些region,并通过心跳来监控region的QPS,避免合并两个QPS很高的region

限流

Store limit

原理

存储TiKV

tidb-storage-architecture
  • 本地存储使用rocksdb,相同TiKV的不同region会存放再相同的rocksdb中

  • 使用raft来同步数据

tidb-storage-1
  • region是一块有序的数据块,从start_key到end_key。每块region不超过94M,raft以region为单位同步数据。region的分布通过PD动态调整

  • MVCC支持,通过再key后面加上version来实现

    Key1_Version3 -> Value
    Key1_Version2 -> Value
    Key1_Version1 -> Value
    ……
    Key2_Version4 -> Value
    Key2_Version3 -> Value
    Key2_Version2 -> Value
    Key2_Version1 -> Value
    ……
    KeyN_Version2 -> Value
    KeyN_Version1 -> Value
    ……
    
  • 分布式ACID事务

    • 乐观事务
tidb-2pc-in-tidb
  • 悲观事务
tidb-pessimistic-transaction-in-tidb

计算TiDB

行转kv

Key:   tablePrefix{TableID}_recordPrefixSep{RowID}
Value: [col1, col2, col3, col4]

索引

Key:   tablePrefix{tableID}_indexPrefixSep{indexID}_indexedColumnsValue
Value: RowID

Key:   tablePrefix{TableID}_indexPrefixSep{IndexID}_indexedColumnsValue_{RowID}
Value: null

元数据

存放再TiKV中

调度PD

任务

  • region合理分布,提高集群利用率
  • 跨机房部署时,要保证一个机房掉线,不会丢失region的多数副本
  • 添加一个TiKV节点,需要合理的迁移其他节点的region到新增节点
  • 当一个节点掉线时,需要考虑快速容灾
    • 掉线后,region副本数量不够,需要选择合适机器补充副本
    • 节点恢复后,region副本数量过多,需要合理删除多余副本
  • 热点region负载均衡
  • 负载均衡时需要考虑数据迁移是否会占用大量网络资源、磁盘IO、CPU。需要限速进行

实现

PD通过心跳收集每个TiKV节点的信息,做调度策略

性能

Threads 主键查询 TPS 95% latency (ms) 更新非索引字段 TPS 95% latency (ms) 更新索引字段 TPS 95% latency (ms) 读写 tps 95% latency (ms)
300 265353.15 1.89 42991.9 11.45 19198.89 23.95 4914.11 82.96
600 358976.94 2.57 54099.58 20.37 22877.58 41.85 5848.09 150.29
900 407625.11 3.68 62084.65 26.68 26431.12 53.85 6223.95 223.34

优化手段

  • 热点识别,拆分region
  • sql编译计划缓存
  • sql执行计划缓存
  • 热点小表缓存
  • 建索引
  • sql优化

你可能感兴趣的:(理解TiDB)