《ArchSummit北京2016年荐-《深度解析云数据库TiDB》-刘奇》.pdfVIP

ArchSummit全球架构师峰会北 京站2015 《深度解析云数据库TiDB》 liuqi@ 微博: @goroutine 议程 ● 关于 MySQL 的一些技术痛点 ● 我们需要一个怎样的数据库? ● 技术实现 ● 关于多租户的一些讨论 ● 一些测试方法 话题从哪里开始 ？ Google 能告诉我们什么 MySQL 君怎么了？ 逃离 MySQL ? MySQL 君怎么了？ ● 争论从未停止 ● 选你所爱 MySQL 君怎么了？ ● 不被巨头控制，垄断 ● 不被绑架 ● 自由 MySQL 君怎么了？ ● scale ● schemaless MySQL 君怎么了？ ● scale ● fast MySQL 君怎么了？ ● 数据库前面通常有缓存 ● Redis越来越流行 ● 其它各种补充 ○ HBase ○ Couchbase ○ …... 别人家的够好吗 ？ PG 君怎么了？ MongoDB 君怎么了？ We Need Transaction! 先小结下： 离开 MySQL 的原因: • 水平扩容/缩容 • 分布式事务 • 容错 • 半同步转异步，数据一致性问题 大家是怎么解决这些问题的？ 水平伸缩 • NoSQL 在这方面有很好的积累 • HBase • Cassandra • MongoDB 分布式事务 • 典型做法 • 两阶段提交 （2PC） • Google spanner (2PL + 2PC) 隔离级别 • SI • 可重复读 • Write skew • update set a = a + 1 • SSI • External consistency 容错 • 多副本( raft 协议 复制，N / 2 + 1 ) • 去中心化的事务冲突检测 TiDB 如何解决这些问题 ？ 受 Google Spanner 和 Google F1 启发 重点支持: • 水平扩容/缩容 • 分布式事务 • 隔离级别 • 异步 schema 变更 • 容错 TiDB 架构图 TiDB 可插拔存储引擎 TiDB 如何解决 Scale 问题 ？ 数据组织 KV { Node [ 1 … N ] { region [ 1 … X ] } } TiDB 如何解决 Scale 问题 ？ 内部分裂 Region X Region Y Region Z Split 1 ~ 10 1 ~ 5 6 ~ 10 Node A TiDB 如何解决 Scale 问题 ？ 迁移