大数据&云计算|作为数据库核心成员,如何让淘宝不卡顿?( 二 )


本文插图
TDDL的定位

3.4 总结 , 我们能做什么?
大数据&云计算|作为数据库核心成员,如何让淘宝不卡顿?
本文插图
结合我们的目标 , 通用方法 , 大前提以及架构定位 , 分析下我们能做和不能做的 。

不能做的:
索引 , 因为这个是设计阶段 , 强业务相关 。 与大前提冲突:我们不参与业务 。
能做的:
语法优化
排除sql问题
下推优化
分表分库(自动水平分表 , 水平分库)

读写分离(读写分离/分布式化与动态扩容)
四 我们如何做?
4.1 语法优化
为达到语法优化的目的 , 我们需要具备什么能力?
简单来说:
我们需要认识这个别人提交给我的sql 。
我能拆解sql 。
优化与重组这个sql 。
大数据&云计算|作为数据库核心成员,如何让淘宝不卡顿?
本文插图
专业点来说:语义分析能力 。

sql解析
sql规则制定
sql优化
sql重组
因此:我们需要设计一个sql解析器 , sql优化器 。
4.1.1 解析器
解析器的核心是词法分析、语法语义分析 , 也就是说来了一条 select/update/insert/delete语句 , 你能认识它 , 而且你知道下一步该怎么处理 , 同时为后面的优化器打下基础 。
核心:将sql解析为一棵语法树 。
例:
sql语法树:
大数据&云计算|作为数据库核心成员,如何让淘宝不卡顿?
本文插图
4.1.2 优化器

核心:
在sql解析成sql语法树后 , 使用sql优化规则(1. 语法优化 2. 下推优化) ,通过对树进行左旋 , 右旋 , 删除子树来对语法树进行重构sql语法树 。
将重构的语法树进行遍历得到优化后的sql 。
(1)语法优化
函数提前计算
判断永真/永假式
合并范围
类型处理
(2)下推优化
Where条件下推

说明:提前条件过滤 , 提前获取数据 , 减少后期计算/IO/网络成本 。
JOIN中非join列的条件下推
说明:提前过滤 , 减轻后期join计算成本 , 达到“小表驱动”的目的 。
等值条件的推导
说明:同理 , 提前过滤 。
4.1.3 总结
sql解析器
负责将sql语句化为sql语法树 。
sql优化器
负责将sql语法树利用sql优化规则 , 重构sql语法树 。
将sql语法树转化为sql语句 。
4.2 分表分库
单库单表的问题:
几年前 , 业务简单 , 应用的数据比较少 , 表结构也不复杂 。 只有一个数据库 , 数据库中的表是一张完整的表 。 而到了今天 , 2007年了 , 业务复杂起来了 , 数据量爆增 , 单表数据破千万甚至上亿条 , 一条DML语句 , 死慢死慢的 。 这种情况下加索引已不再有显著的效果 。
这个时候 , 数据库效率瓶颈不是靠加索引 , sql优化能搞定的 。
正确出路:分表分库 , 通过将表拆分 , 来降低单表数据量 , 进而提高数据库操作效率 。
分表分为:
垂直分表
水平分表
分库分为:
垂直分库
水平分库
由于TDDL不参与业务 , 而垂直分库分表是强业务相关的 , 因此TDDL暂不参与垂直分库分表 , 只在水平分库分表方向上努力 。
4.2.1 垂直分表

垂直拆分是将一张表垂直拆成多个表 。 往往是把常用的列独立成一张主表 。 不常用的列以及特别长的列拆分成另一张拓展表 。
大数据&云计算|作为数据库核心成员,如何让淘宝不卡顿?
本文插图
简单垂直分表举例
核心要素:
冷热分离 , 把常用的列放在一个表 , 不常用的放在一个表 。
大字段列独立存放 , 如描述信息 。
关联关系的列紧密的放在一起 。
它带来的提升是:
为了避免IO争抢并减少锁表的几率 , 查看详情的用户与商品信息浏览互不影响 。
充分发挥热门数据的操作效率 , 商品信息的操作的高效率不会被商品描述的低效率所拖累 。
4.2.2 水平分表
水平分表是在同一个数据库内 , 把同一个表的数据按一定规则拆到多个表中 。
大数据&云计算|作为数据库核心成员,如何让淘宝不卡顿?
本文插图
简单水平分表举例

简单点的技巧:按照枚举类型区分 。
作用总结:
库内的水平分表 , 解决了单一表数据量过大的问题 , 分出来的小表中只包含一部分数据 , 从而使得单个表的数据量变小 , 提高检索性能 。
避免IO争抢并减少锁表的几率 。
4.2.3 垂直分库
垂直分库是指按照业务将表进行分类 , 分布到不同的数据库上面 , 每个库可以放在不同的服务器上 , 它的核心理念是专库专用 。

大数据&云计算|作为数据库核心成员,如何让淘宝不卡顿?
本文插图
垂直分库

作用总结:


推荐阅读