[转帖]TiKV & TiDB相关笔记

tikv,tidb,相关,笔记 · 浏览次数 : 0

小编点评

**调度概述** * PD (Placement Driver) 是整个集群的核心,负责全局元信息的存储以及 TiKV 集群负载均衡调度。 * 调度需求整理作为一个分布式高可用存储系统,必须满足:副本数量不能多也不能少、副本需要分布在不同的机器上、新加节点后可以将其他节点上的副本迁移过来、节点下线后需要将数据迁移走。 **调度策略** * PD 在动态中不断向最优状态前进,最终落地的无非是下面三件事:增加一个 Replica删除一个 Replica将 Leader 角色在一个 Raft Group 的不同 Replica 之间 transfer。 * 每 Region 的 Replica 数量正确通过 Leader 在上报信息后,通过 API 的方式暴露出期望的 TiDB/TiKV numbers。 * 根据负载动态分裂 ( Load Base Splitting) * 热点隔离 (Isolate Frequently Access Region) **TiDB 和 MySQL 的区别** * TiDB 是开源 NewSQL 数据库的典型代表之一,同样支持 SQL,支持事务 ACID 特性。 * 在通讯协议上,TiDB 选择与 MySQL 完全兼容,并尽可能兼容 MySQL 的语法。

正文

https://www.jianshu.com/p/1141be233bb2

 

一、TiKV存储

简述

  • 通过单机的 RocksDB,TiKV 可以将数据快速地存储在磁盘上;通过 Raft,将数据复制到多台机器上,以防单机失效。数据的写入是通过 Raft 这一层的接口写入,而不是直接写 RocksDB。通过实现 Raft,TiKV 变成了一个分布式的 Key-Value 存储,少数几台机器宕机也能通过原生的 Raft 协议自动把副本补全,继续让业务无感知的对外服务。

Region

将整个 Key-Value 空间分成很多段,每一段是一系列连续的 Key,将每一段叫做一个 Region,并且会尽量保持每个 Region 中保存的数据不超过一定的大小,目前在 TiKV 中默认是 96MB。每一个 Region 都可以用 [StartKey,EndKey) 这样一个左闭右开区间来描述。

  1. 以 Region 为单位,将数据分散在集群中所有的节点上,并且尽量保证每个节点上服务的 Region 数量差不多
  2. 以 Region 为单位做 Raft(数据) 的复制和成员管理:一个 Region 的多个 Replica 会保存在不同的节点上,构成一个 Raft Group。其中一个 Replica 会作为这个 Group 的 Leader,其他的 Replica 作为 Follower。所有的读和写都是通过 Leader 进行,(写)再由 Leader 复制给 Follower。

MVCC(多版本并发控制)

TiKV 的 MVCC 实现是通过在 Key 后面添加版本号来实现。可以直接通过 RocksDB 的 API: SeekPrefix(Key-Version),定位到第一个大于等于这个 Key_Version 的位置。

分布式 ACID 事务

TiKV 的事务采用的是 Google 在 BigTable 中使用的事务模型:Percolator
能保证要么全部成功,要么全部失败,不会出现的中间状态和脏数据。

二、TiDB如何使用TiKV

问题:如何存储数据?哪些作为key,哪些作为value?
对于一个 Table 来说,需要存储的数据包括三部分:

  1. 表中每一行的数据,以下简称表数据
  2. 表中所有索引的数据,以下简称索引数据
  3. 表的元信息
    对于表中每一行的数据,既可以选择行存也可以选择列存,两者各有优缺点,适用不同场景。
    TiDB 的首要目标是 OLTP 业务,要满足这类业务的需求,数据库需要支持快速的针对单行或者某些行的增、删、改、查等操作,所以 TiKV 的行存是比较合适该场景的。
    从 TiDB 3.1 开始(包括 TiDB 4.0),为了能够满足用户复杂的实时分析场景(OLAP?),TiDB 提供了一个叫做** TiFlash 的列存引擎**,它提供了列式的存储模式和快速的分析能力。列存的映射关系比较简单,这里暂且不表。

2.1 索引

索引数据,TiDB 同时支持主键和二级索引(包括唯一索引和非唯一索引)。在 OLTP 场景下,好的索引能够极大的提升 SQL 查询的性能,降低集群的整体负载。

  1. 对于 Insert 语句,既需要将表数据写入 KV 存储,也需要构造和存储对应的索引数据。
  2. 对于 Update 语句,需要在更新表数据的同时,也更新对应的索引数据(如果有必要的话)。
  3. 对于 Delete 语句,需要在删除表数据的同时,也删除对应的索引数据(如果有必要的话)。
  4. 对于 Select 语句,情况会复杂一些。用户希望数据库提供快速读取一行数据的能力,所以每行表数据最好有一个唯一 ID (显示或隐式的 ID)方便快速读取。其次用户也可能会连续地读取多行数据,比如 select * from user。最后还有通过索引读取数据的需求,对索引的使用可能是基于唯一索引或者主键的等值查询(业界常说的“点查”)或者是范围查询。
    当然,在有了 TiFlash 以后,全表扫更适合在 TiFlash 上进行,因为列式存储的优势,这种场景中它能提供更快的读取性能。

2.1.1 行数据的key设计

TiDB会为全集群生成唯一表ID,为表内数据生成唯一的行ID(有整型主键则是主键作为行ID),则数据如下:

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

2.1.2 索引数据的 Key-Value 映射关系

TiDB 为表中每个索引分配了一个索引 ID,其中:
对于需要满足唯一性约束的主键或者唯一索引,按照如下规则编码成 (Key, Value) 键值对:

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

对于不需要满足唯一性约束的普通二级索引,按照如下规则编码成 (Key, Value) 键值对:

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

2.2 元数据

另外存储于某个key中,将元信息编码后存储

2.3 SQL 层简介

TiDB 的 SQL层,即tidb-server,负责将 SQL 翻译成 KV 操作,转发给共享的分布式 KV 存储层 TiKV,并组装返回结果,最终返回查询结果。
举例:select count(*) from user where name='test',像这样一句语句,如果将数据返回到tiDB进行过滤、计数会浪费网络IO和无意义计算。可以将这类操作下放到tiKV,粗略描述如下图:

 
image.png

 

实际流程较复杂:


 
image.png

用户的 SQL 请求会直接或者通过Load Balancer发送到 tidb-server,tidb-server 会解析MySQL Protocol Packet,获取请求内容,然后做语法解析、查询计划制定和优化、执行查询计划获取和处理数据。数据全部存储在 TiKV 集群中,所以在这个过程中 tidb-server 需要和 TiKV 交互,获取数据。最后 tidb-server 需要将查询结果返回给用户。

三、关于调度

在这两个组件的后面,还有一个叫做 PD(Placement Driver)的组件,虽然不直接和业务接触,但是这个组件是整个集群的核心,负责全局元信息的存储以及 TiKV 集群负载均衡调度。

3.1 为什么要进行调度

 

 
image.png

整个系统是在动态变化,Region 分裂、节点加入、节点失效、访问热点变化等情况会不断发生,整个调度系统也需要在动态中不断向最优状态前进,因此我们需要一个中心节点,来对系统的整体状况进行把控和调整,所以有了 PD 这个模块。

 

3.2 调度的需求整理

作为一个分布式高可用存储系统,必须满足:副本数量不能多也不能少、副本需要分布在不同的机器上、新加节点后可以将其他节点上的副本迁移过来、节点下线后需要将数据迁移走。
作为一个良好的分布式系统,需要优化:维持整个集群的 Leader 分布均匀、维持每个节点的储存容量均匀、维持访问热点分布均匀控制 Balance 的速度,避免影响在线服务;管理节点状态,包括手动上线/下线节点,以及自动下线失效节点。
上述调度需求看似复杂,但是整理下来最终落地的无非是下面三件事:

  • 增加一个 Replica
  • 删除一个 Replica
  • 将 Leader 角色在一个 Raft Group 的不同 Replica 之间 transfer。
    刚好 Raft 协议能够满足这三种需求,通过 AddReplica、RemoveReplica、TransferLeader 这三个命令,可以支撑上述三种基本操作。

3.3 信息收集

  • 每个 TiKV 节点(Store)会定期向 PD 汇报节点的整体信息。
  • 每个 Raft Group 的 Leader 会定期向 PD 汇报信息。

3.4 调度的策略

  • 保障一个 Region 的 Replica 数量正确:在掉节点或恢复节点时,增删replica
  • 保障一个 Raft Group 中的多个 Replica 不在同一个位置: 位置包括物理机器、单个机架、单个机房。可以给节点配置 lables,需要在 Replica 分配的时候尽量保证不会有一个 Region 的多个 Replica 所在结点有相同的位置标识。
  • 副本在 Store 之间的分布均匀分配:维持每个节点上面,副本数量的均衡,会使得总体的负载更均衡。
  • Leader 数量在 Store 之间均匀分配: Raft 协议要读取核写入都通过 Leader 进行,所以计算的负载主要在 Leader 上面,PD 会尽可能将 Leader 在节点间分散开。
  • 访问热点数量在 Store 之间均匀分配:每个 Store 以及 Region Leader 在上报信息时携带了当前访问负载的信息,比如 Key 的读取/写入速度。PD 会检测出访问热点,且将其在节点之间分散开。
  • 各个 Store 的存储空间占用大致相等
  • 控制调度速度,避免影响在线服务

3.5 自动伸缩

TiDB 借助 TiDB Operator 和 PD 来实现 Auto-Scale。目前由 TiDB Operator 组件定期获取 TiDB / TiKV 的 metrics 信息后,通过 API 的方式暴露出期望的 TiDB/TiKV numbers,然后由 TiDB Operator 定期拉取 PD API 信息后,通过内部的 Auto-scaling 算法对 TidbCluster.Spec.Replicas 进行调整,从而实现Auto-scaling。

3.6 动态调度

3.7 根据负载动态分裂 ( Load Base Splitting)

3.8 热点隔离 (Isolate Frequently Access Region)

四、TiDB 和 MySQL 的区别

TiDB 作为开源 NewSQL 数据库的典型代表之一,同样支持 SQL,支持事务 ACID 特性。
在通讯协议上,TiDB 选择与 MySQL 完全兼容,并尽可能兼容 MySQL 的语法。
因此,基于 MySQL 数据库开发的系统,大多数可以平滑迁移至 TiDB,而几乎不用修改代码。对用户来说,迁移成本极低,过渡自然。
但仍有少量不兼容。

与[转帖]TiKV & TiDB相关笔记相似的内容:

[转帖]TiKV & TiDB相关笔记

https://www.jianshu.com/p/1141be233bb2 一、TiKV存储 简述 通过单机的 RocksDB,TiKV 可以将数据快速地存储在磁盘上;通过 Raft,将数据复制到多台机器上,以防单机失效。数据的写入是通过 Raft 这一层的接口写入,而不是直接写 RocksDB。

[转帖]TiKV & TiDB相关笔记

https://www.jianshu.com/p/1141be233bb2 一、TiKV存储 简述 通过单机的 RocksDB,TiKV 可以将数据快速地存储在磁盘上;通过 Raft,将数据复制到多台机器上,以防单机失效。数据的写入是通过 Raft 这一层的接口写入,而不是直接写 RocksDB。

[转帖]TiKV Control 使用说明

https://docs.pingcap.com/zh/tidb/stable/tikv-control TiKV Control(以下简称 tikv-ctl)是 TiKV 的命令行工具,用于管理 TiKV 集群。它的安装目录如下: 如果是使用 TiUP 部署的集群,在 ~/.tiup/compon

[转帖]TiKV Control 使用说明

https://docs.pingcap.com/zh/tidb/stable/tikv-control TiKV Control(以下简称 tikv-ctl)是 TiKV 的命令行工具,用于管理 TiKV 集群。它的安装目录如下: 如果是使用 TiUP 部署的集群,在 ~/.tiup/compon

[转帖]TIDB TIKV 数据是怎么写入与通过Region 分割的?

https://cloud.tencent.com/developer/article/1882194 国产的分布式数据库不少,TDSQL, OB, TIDB ,等等都是比较知名的产品,使用的分布式协议也不同,有使用POSTGRES-XL ,也有从外观模仿ORACLE 的,还有借鉴各家所长自己研发的

[转帖]TiKV 内存调优

TiDB试用 来源:TiDB 浏览 87 扫码 分享 2023-05-09 09:02:19 TiKV 内存参数性能调优 参数说明 TiKV 内存使用情况 TiKV 机器配置推荐 TiKV 内存参数性能调优 本文档用于描述如何根据机器配置情况来调整 TiKV 的参数,使 TiKV 的性能达到最优。你

[转帖]TIKV扩容之刨坑填坑​

01 背景 某tidb集群收到告警,TIKV 节点磁盘使用率85%以上,联系业务无法快速删除数据,于是想到扩容TIKV 节点,原先TIKV 节点机器都是6TB的硬盘,目前只有3TB的机器可扩,也担心region 均衡后会不会打满3TB的盘,PD 调度策略来看应该是会根据不同存储机器的资源配置和使用情

[转帖]TiKV 缩容不掉如何解决?

https://tidb.net/book/tidb-monthly/2022/2022-04/usercase/tikv TiKV节点缩容不掉,通常遇到的情况: 1、经常遇到的情况是:3个节点的tikv集群缩容肯定会一直卡着,因为没有新节点接受要下线kv的region peer。 2、另外就是除缩

[转帖]TiKV & TiFlash 加速复杂业务查询

https://tidb.net/book/tidb-monthly/2022/2022-07/usercase/tikv-tiflash 背景​ 在互联网公司或传统公司的 CRM 系统中,最常用的功能之一客户的筛选。通过不同的角度、维度、标签的组合来框选客户,以便后续的业务操作。 这无疑是对传统关

[转帖]TiKV 内存参数性能调优

https://docs.pingcap.com/zh/tidb/stable/tune-tikv-memory-performance 本文档用于描述如何根据机器配置情况来调整 TiKV 的参数,使 TiKV 的性能达到最优。你可以在 etc/config-template.toml 找到配置文件