分布式数据库30讲
王磊
光大银行首席数据架构师
新⼈⾸单¥19.9
2397 人已学习
课程目录
已更新 23 讲 / 共 33 讲
0/4登录后，你可以任选4讲全文学习。
开篇词 (1讲)
开篇词｜为什么要学习分布式数据库？
免费
基础篇 (8讲)
01｜什么是分布式数据库？
02｜强一致性：那么多数据一致性模型，究竟有啥不一样？
03｜强一致性：别再用BASE做借口，来看看什么是真正的事务一致性
04 | 架构风格：NewSQL和PGXC到底有啥不一样？
05 | 全局时钟：物理时钟和逻辑时钟你Pick谁？
06 | 分片机制：为什么说Range是更好的分片策略？
07 | 数据复制：为什么有时候Paxos不是最佳选择？
08 | 基础篇大串讲：重难点回顾+思考题答疑+知识全景图
开发篇 (14讲)
09｜原子性：2PC还是原子性协议的王者吗？
10 | 原子性：如何打破事务高延迟的魔咒？
11｜隔离性：读写冲突时，快照是最好的办法吗？
12 | 隔离性：看不见的读写冲突，要怎么处理？
13 | 隔离性：为什么使用乐观协议的分布式数据库越来越少?
14 | 隔离性：实现悲观协议，除了锁还有别的办法吗？
15 | 分布式事务串讲：重难点回顾+思考题答疑+知识全景图
16 | 为什么不建议你使用存储过程？
17 | 为什么不建议你使用自增主键？
18 | HTAP是不是赢者通吃的游戏？
19 | 查询性能优化：计算与存储分离架构下有哪些优化思路？
20 | 关联查询：如何提升多表Join能力？
21 | 查询执行引擎：如何让聚合计算加速？
22｜RUM猜想：想要读写快还是存储省？又是三选二
21 | 查询执行引擎：如何让聚合计算加速？
王磊 2020-09-25
你好，我是王磊。
在 19、20 两讲中，我已经介绍了计算引擎在海量数据查询下的一些优化策略，包括计算下推和更复杂的并行执行框架。这些策略对应了从查询请求输入到查询计划这个阶段的工作。那么，整体查询任务的下一个阶段就是查询计划的执行，承担这部分工作的组件一般称为查询执行引擎。
单从架构层面看，查询执行引擎与分布式架构无关，但是由于分布式数据库要面对海量数据，所以对提升查询性能相比单体数据库有更强烈的诉求，更关注这部分的优化。
你是不是碰到过这样的情况，对宽口径数据做聚合计算时，系统要等待很长时间才能给出结果。那是因为这种情况涉及大量数据参与，常常会碰到查询执行引擎的短板。你肯定想知道，有优化办法吗？
当然是有的。查询执行引擎是否高效与其采用的模型有直接关系，模型主要有三种：火山模型、向量化模型和代码生成。你碰到的情况很可能是没用对模型。
火山模型
火山模型（Volcano Model）也称为迭代模型（Iterator Model），是最著名的查询执行模型，早在 1990 年就在论文“Volcano, an Extensible and Parallel Query Evaluation System”中被提出。主流的 OLTP 数据库 Oracle、MySQL 都采用了这种模型。
确认放弃笔记？
放弃后所记笔记将不保留。
新功能上线，你的历史笔记已初始化为私密笔记，是否一键批量公开？
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《分布式数据库30讲》，如需阅读全部文章，
请订阅文章所属专栏，新⼈⾸单¥19.9
请订阅文章所属专栏，新⼈⾸单¥19.9
立即订阅
登录 后留言
精选留言(2)
扩散性百万咸面包老师，这里有个问题，既然MySQL等用了火山模型，那它们为什么不改成向量化接口呢？既然提升如此明显？
感觉向量化就是把多个tuple一次返回，向量化和行式存储结合的难点在哪呢？2020-09-25
Jxin感觉代码生成==编译器运行期优化。
1.针对循环做优化
2.减少过程调用开销
3.对控制流做优化
4.向量计算2020-09-25
收起评论