建设一个网站最低消费微信开放平台创建小程序
建设一个网站最低消费,微信开放平台创建小程序,购物系统名称,注册装修公司要多少钱才能注册Part11-Join Algorithms
Why Do We Need to Join?
Join其实是关系数据库和范式化表时候所产生的副产物。
也就是说我们范式化表是为了减少冗余信息#xff0c;而我们使用join就是为了去重建reconstruct 这些原本的tuple
Join Algorithms
主要关注两表的inner equijoin a…Part11-Join Algorithms
Why Do We Need to Join?
Join其实是关系数据库和范式化表时候所产生的副产物。
也就是说我们范式化表是为了减少冗余信息而我们使用join就是为了去重建reconstruct 这些原本的tuple
Join Algorithms
主要关注两表的inner equijoin algorithms
通常较小的表作为左表(left table / outer table)进行join右表叫做inner table
Join Operators
在叶子节点处对表访问将表中的tuple作为输入传给父节点的operator。 考虑1. output 查询计划生成树join算子之间传递的是什么 2. 如何判断算法的优劣——Cost Analysis Criteria 对于两个表RS的tuple r,s进行join 级联操作生成一个新的tuple具体的内容取决于 查询处理模型 Query processing model (多个tuple)存储模型 Storage model row / column 存具体的query 关于算子之间的输出传递可以直接级联的结果进行传递如果很多列则代价很大可能进行一个预先的投影操作。还有就是only copy joins keys along with record ids.(特别针对列存) 叫做Late Materialization I/O Cost Analysis 计算join过程必须使用的I/O次数来估计成本。只关心join操作的成本不关心最后输出结果或者其他因素。 M pages in table Rm tuples in RN pages in table Sn tuples in S
Join VS Cross-Product
cross-product 交叉连接
Join Algorithms
包括Nested Loop Join、Sort-Merge join、Hash Join
Nested Loop Join
for each tuple r in R // outer tablefor each tuple s in S: // inner tableemit,if r and s matchstupid ! Cost: M m* N 左表M个pages然后m个tuple每次都扫描一次右表N个pages代价就是Mm*N
优化 小表作为左表 Block Nested Loop Join 使用block、page可以多个tuple一个block/page让outer table的一个block中所有tuple 完成和inner table中所有tuple的join再去取下一个inner table的block。 代价是MM*N这里的话小表就是page少的了 不是tuple少的 对于outer table使用尽可能多的内存buffer来保存他即B-2个block 来保存左表1 block for inner table, 1 block for output result。 Cost M [M / (B-2)] * N 如果buffer够大可以放开左表那cost MN 可以避免循序扫描通过使用index来找inner table matches 使用一个已经存在的index on inner tablebuild one on the fly(hash table, B Tree) 针对join的index 叫做Spooling index. 查询结束删除index index不一定就是join on的key也许join on col A and B在A上有index也可以用索引探针Index probe来进行优化先找A然后再匹配B列。 假设C是index查找一个tuple的一个代价Cost M m*C Sort-Merge Join 第一阶段—排序sort both tables on the join keys可以使用external merge sort或者内存中的快排第二阶段—合并使用游标对排好序的两个表的tuple进行逐个比较匹配就输出。双指针。 可能会需要backtracking 回溯操作回到该值在inner table中第一次出现的地方。只会对inner table进行backtracking。 Cost 最差的情况outer table中的每个值和inner table中的每个值都相等每个tuple m都得回溯一次COST M * N SORT COST Sort-Merge join 用处如果有一个或者俩表都on join key排好序了或者要求order by需要对结果排序。特别有个索引排好序 且是聚簇索引 Hash Join hash function是确定的两个表相同的key hash 结果相同。 基于hash key来讲outer table拆分成多个分区付出前期成本来将数据拆分以此让查找或者探测过程更快。即value hash → partition iR tuple must be in r_i,S tuple must be in s_i。因此R tuples in r_i只需要和S tuples in s_i 比较来进行join Basic Hash Join Algorithm Build循序扫描outer relation 然后pop到hashtable 使用h_1 Probe对inner relation扫描使用h_1 将每个tuple进行hash处理会跳到相同的位置然后看有没有匹配的tuple。 Key是join操作基于的属性Value取决于上层算子的输入。 Hash Table Values Full Tuple避免回表IO但是需要更多内存。Tuple Identifiertuple标识符例如record id适用于列存 Probe Phase Optimization再build阶段创建一个bloom filter在没有查看hash table的情况下可以通过它来判断要查找的tuple是否在这个hashtable中。也叫做sizeways information passing横向信息传递。 Bloom Filter是一种概率数据结构Probabilistic DSbitmap用来处理set membership查询近似成员查询该key在不在我的集合中包括操作insert(x)Lookup(x).好处是可能会假阳性就是实际不在但是告诉你在但是不会逻辑上影响正确性不会假阴性就是在但是告诉你不在这样就是逻辑错误了这种不会出现。具体的优化是构建hash table的时候可能会溢出到磁盘为key构建一个bloom filtersuper small can fit in memory。避免潜在的无用的磁盘I/O Grace(partition) Hash Join处理Hash Join don’t fit in memory Build Phase:基于hash key将两张表拆分成多个分区拆分成两个单独的hash tableouter table和inner table各自有一张hash table。Probe Phase比较两张表对应分区的tuples对匹配的分区进行nested-loop join。 bucket chain hash table而非linear probe hash table。因为想要相同的数据hash到同一位置或者映射到同一分区。一一匹配去scan。 都hash到一个bucket就会出问题用递归分区Recursive Partitioning来解决。使用另外一个hash function h2来建立bucket_r,i。如果有足够buffer且所有数据都能放在内存中可以跨分区进行join操作COST 3 *(MN)。分区的时候要对M outertable N innertable进行一轮读和一轮写probe一轮
Observation
如果DBMS直到outer table的size可以去调整hash table或者buffer size如果可以都内存就线性hash如果需要溢出到磁盘就bucket。如果不知道size可以使用动态hash tablelinear extendable hash table或者允许overflow pages但是代价会很高。 什么情况下会不清楚outer table的size 回答多个操作之间所产生的临时中间表的size
除非排好序否则hash join永远比其他join来的好
sorting适合于non-uniform data 或者结果需要排序的情况。
range join anti join?
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.mzph.cn/pingmian/89373.shtml
如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!