010、体系架构之TiFlash

TiFlash

  • TiFlash 功能
    • 架构
    • 异步复制
    • 一致性读取
    • 场景选择
    • 是选择TiKV还是TiFLash

TiFlash 功能

  • 异步复制
  • 一致性读取(写虽然是异步,但读可以做到一致性)
  • 引擎智能选择
  • 计算加速

架构

010、体系架构之TiFlash_第1张图片

TiFLASH 也是通过raft 算法进行同步,但它不怎么消耗资源,因为它的角色四 Learner(即只同步,没有选举功能)、另外写数据是不能直接写TiFlash上。读是可以直接在TiFlash上。

010、体系架构之TiFlash_第2张图片

异步复制

010、体系架构之TiFlash_第3张图片

TiFlash 是异步复制,它的日志写入成功与否不会影响 TiKV 的leader厍,它是learner角色。

一致性读取

010、体系架构之TiFlash_第4张图片
其实最难的是一致性读取,TiFlash中的数据如果还没有来得及同步过来,那数据的读取是怎么保证一致性的?
010、体系架构之TiFlash_第5张图片

010、体系架构之TiFlash_第6张图片
010、体系架构之TiFlash_第7张图片
等到了 idx=125 idx=31的时候,才会将数据返回。
010、体系架构之TiFlash_第8张图片
010、体系架构之TiFlash_第9张图片
010、体系架构之TiFlash_第10张图片

场景选择

在决定如何选择 TiFlash 节点数量时,请考虑以下⼏种业务场景:

  • 如果业务场景以 OLTP 为主,做轻量级的 OLAP 计算,通常部署 1个或⼏个 TiFlash 节点就会产⽣明显的加速效果。
  • 当 OLTP 数据吞吐量对节点 I/O ⽆明显压⼒时,每个 TiFlash 节点将会使⽤较多资源⽤于计算,这样 TiFlash 集群可实现近似线性的扩展能⼒。
  • 当 OLTP 数据吞吐量较⾼时(例如写⼊或更新超过千万⾏/⼩时),由于⽹络和物理磁盘的写⼊能⼒有限,内部 TiKV 与 TiFlash 之间的 I/O 会成为主要瓶颈,也容易产⽣读写热点。此时 TiFlash 节点数与 OLAP 计算量有较复杂⾮线性关系,需要根据具体系统状态调整节点数量。

是选择TiKV还是TiFLash

索引扫描适合OLTP _TiKV
列统计非常适合列簇 _TIFlash
通常交给优化器自行选择。

010、体系架构之TiFlash_第11张图片

  • 引擎智能选择
    • session.tidb_isolation_read_engines: 支持读操作的可用引擎
    • alter table … set tiflash replica n: 为特定表启用TiFlash的learner复制功能
    • alter table … set tiflash replica 0: 关闭特定表启用TiFlash的learner复制功能
    • CBO 将自动地选择更好的存储引擎支持查询操作
      010、体系架构之TiFlash_第12张图片
      测试用例
      在这里插入图片描述

你可能感兴趣的:(TiDB从入门到精通,架构,数据库,大数据)