【TiDB 4.0 PCTA学习笔记】- 1.3 A Brief History About the TiDB database platform（TiDB 发展简史）@2班+孟维克

☄️ 学习与认证 经验&心得&笔记
,
#1

课程名称：101 +1.3 A Brief History About the TiDB database platform（TiDB 发展简史）

学习时长：20M

课程收获：

课程内容：

最初版TiDB

  • 在Google Spanner论文的启发下，我们创造了TiDB
  • 在1.0.0GA版本，TiDB有以下特性
    • 无限扩展(计算层、存储层)的数据库，可分开扩展
    • 兼容MySQL语法和协议
    • 对应用透明的分片策略
    • 支持强一致的分布式事务

数据中台的能力

  • TiDB适合数据中台的场景
  • 协议的兼容，很容易从MySQL生产环境同步
  • 不需要分片，因此对应用是透明的
  • 数据汇总是实时的
  • 可将中台和备库合二为一

一年后

  • TP场景
    • 客户：尽管有一些问题，但是整体还行。
  • AP场景
    • 问题1:复杂的SQL语句执行太慢！
    • 问题2:容易OOM！
    • 问题3:不能很好的与大数据平台整合！

解决方案

  • 将TiDB与TiKV融合
    • 重构成类似MPP存储引擎
    • 但是时间很长，风险很高
  • 或者
    • 引入开源的分布式计算框架

TiSpark

  • Spark帮助我们完成分布式计算
    • 成熟的分布式计算框架
    • 更快、更稳定
  • 完整集成到Apache Spark生态
    • 无缝集成到大数据生态
    • 脚本，Python，R，Apache Zeppelin，Hadoop均可操作TiDB
  • Apache Spark并发很低
    • 消耗大量计算资源
  • 用户希望有高并发、中等规模的AP查询场景
    • 复杂的查询消耗资源不高
    • TiDB比Spark更易于维护

优化

  • 优化器
    • 基础优化器—>RBO+CBO优化器—>Cascade优化器
  • 执行器
    • 经典的火山模型—>批量执行—>向量化执行
    • 更好的并发控制
  • 分区表，Index Merge等

核心矛盾

  • 至此，我们仍然有2个核心矛盾未解决
    • 行式存储引擎不适用于分析场景
  • 资源隔离不友好
    • TiSpark场景有时甚至更糟

TiFlash

  • 通过Raft Learner单独同步一份列存数据
    • 资源消耗低
    • 通过MVCC提供强一致读
  • 通过打标签方式物理隔离
    • AP/TP负载不会互相影响

学习过程中参考的其他资料