ArchSummit北京2015-《深度解析云数据库TiDB》.pdf
文本预览下载声明
ArchSummit全球架构师峰会北
京站2015
《深度解析云数据库TiDB》
微博: @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 问题 ?
迁移
显示全部