Métodos para ejecutar la operación de reunión (join) Francisco Moreno

La operación join Centro de interés: Operación join (reunión): Métodos (algoritmos) para su ejecución Evaluación de costo de cada método

La operación join Relaciones r(A,…) y s(B,…) Join: r ⋈A=B s Sean: Fr = Número de páginas de r Fs = Número de páginas de s tr = Número de tuplas de r ts = Número de tuplas de s

La operación join Para el ejemplo, se manejarán estos valores: Fr = 1000 Fs = 100 tr = 10000 ts = 1000

Nested Loops 1. Block Nested Loops (Ciclos Anidados con Bloques) Supóngase que se tiene una memoria de M páginas M - 2 páginas se usarán para la relación del ciclo externo (r)  ver algoritmo 1 página se usará para la relación del ciclo interno (s)  ver algoritmo 1 página se usará para generar la salida

Nested Loops … r 1 2 M-2 r ⋈ s s ⋈ Set of M-2 pages of r Input buffer for r … 1 2 M-2 r ⋈ s s ⋈ Input buffer for s Output buffer Page of s

Nested Loops FOR EACH set spr of M-2 pages of r DO FOR EACH page ps of s DO output spr ⋈A=B ps

Nested Loops Por lo tanto, la relación s se recorre una vez por cada grupo de (M - 2) páginas de r, es decir, se recorre: Fr / (M - 2) veces. Por lo tanto, el costo es: Fr + Fs * Fr / (M - 2) Nótese que si Fr  (M - 2) entonces el costo es: Fr + Fs

Nested Loops Ej: si M = 102 entonces Costo = 1000 + 100 * 1000 / (102 - 2) = 2000 Intercambiando r y s: Costo = 100 + 1000 * 100 / (102 - 2) = 1100 Aquí la diferencia es casi del 50%, así el orden de las relaciones importa. Es más “económico” colocar la relación más pequeña en el ciclo externo Fr Fs Fr M - 2 Fs Fr Fs M - 2

Nested Loops 2. Index Nested Loops (Ciclos Anidados con Índice) Supóngase que s (relación interna) tiene un índice sobre el atributo de join B En vez de recorrer toda s en el ciclo interno se puede usar el índice para encontrar las matching tuplas así:

Algoritmo FOR EACH t  r DO { - Usar el índice sobre B para encontrar todas las tuplas t’  s tales que t.A = t’.B - output <t, t’> para cada una de las t’ }

Nested Loops Para estimar el costo se debe considerar: El tipo de índice (B+, hash, etc.) y Si el índice es clustered (agrupado) o unclustered

Índice clustered Archivo del índice Mecanismo para localizar las entradas del índice Entradas del índice Registros de datos Archivo de datos

Índice unclustered Archivo del índice Mecanismo para localizar las entradas del índice Entradas del índice Registros de datos Archivo de datos

Nested Loops Si el índice es de tipo B+, el costo promedio para llegar al nodo hoja de la tupla buscada está entre 2 a 4 páginas Si el índice es de tipo hash, el costo promedio es 1.2 páginas

Nested Loops Si el índice es unclustered el número de lecturas (páginas) requerido para recuperar todas las matching tuplas de s es en el peor de los casos Fs (implicaría leer toda s) Por lo tanto, los índices unclustered no son recomendables para este método a menos que B sea una clave candidata en s (en este caso habría una sola matching tupla y se requeriría una sola lectura (página) para recuperarla)

Nested Loops Si el índice es clustered, todas las matching tuplas de t estarán en la misma página o en las páginas adyacentes, en promedio, 1 o 2 lecturas (páginas) Por lo tanto, en este caso el costo es:

Nested Loops Fr + ( + 1) * tr Donde  es el costo promedio de localizar con el índice el nodo hoja del arbol B+ (o el bucket correspondiente si el índice es hash) El 1 adicional corresponde a la lectura de la página de las matching tuplas

Nested Loops Si el índice es unclustered entonces el costo es: Fr + ( + ) * tr Donde  es el número de páginas que hay que leer para recuperar las matching tuplas de t

Nested Loops Ej: Supóngase  = 2, un índice B+ clustered sobre el atributo B de s, r externa y s interna, entonces: 1000 + (2 + 1) * 10000 = 31000 Intercambiando r y s y suponiendo un índice B+ clustered sobre el atributo A de r: 100 + (2 + 1) * 1000 = 3100 Fr  tr Fs  ts

Nested Loops En este ejemplo, este método “pierde” con el Block Nested, pero si la relación interna es de gran tamaño, el Index Nested tiene un mejor comportamiento que el Block Nested…

Nested Loops Nótese que para una relación s muy grande,  crece…pero poco El Index Nested suele trabajar “bien” con relaciones de gran tamaño, con la relación interna: a) más grande que la externa y b) con índice clustered sobre el atributo de join

Sort Merge Join 4. Sort Merge Join (Reunión con Ordenamiento y Mezcla) Se hace en dos etapas: i. Se ordenan las relaciones por los atributos de join ii. Luego se hace un proceso de mezcla tal y como lo muestra el algoritmo:

Sort Merge Join Proceso de Mezcla Input: relación r ordenada por el atributo A relation s ordenada por el atributo B Output: r ⋈A=B s Result := {} //Se inicializa el resultado tr := getFirst(r) //Primera tupla de r ts := getFirst(s) //Primera tupla de s while !eof(r) AND !eof(s) do { while !eof(r) AND tr.A < ts.B do tr := getNext(r) //Obtener la próxima tupla de r while !eof(s) AND tr.A > ts.B do ts := getNext(s) //Obtener la próxima tupla de s if tr.A = ts.B = c then { //Para alguna constante c Result := (A=c(r) x B=c(s)) U Result; tr := próxima tupla t  r tal que t.A > c } Return Result Proceso de Mezcla Las relaciones ya vienen ordenadas por los atributos de join

Sort Merge Join Costo total: Costo del ordenamiento de cada relación + Costo de la mezcla El costo de la mezcla es: Fr + Fs Ahora se debe obtener el costo de ordenar una relación:

Sort Merge Join Costo de ordenar una relación: Ordenar una relación en una BD consta a su vez de dos fases: Partial sorting (ordenamiento parcial) Mezcla (K-way merge)* * No confundir con la mezcla del Sort Merge, son dos procesos distintos…

Sort Merge Join - Costo del ordenamiento parcial: Supóngase una memoria de M páginas y una relación de F páginas (F es usualmente más grande que M, es decir, F>>M) Se leen, ordenan y escriben todas las páginas de la relación, tal y como lo muestra el siguiente algoritmo:

Sort Merge Join Algoritmo ordenamiento parcial: DO{ 1. Leer M páginas desde disco a la memoria principal 2. Ordenarlas en memoria con uno de los métodos conocidos (suponer que existe memoria adicional suficiente para llevar a cabo este proceso, aparte de la memoria para las M páginas) 3. Escribir el resultado ordenado en un nuevo archivo }UNTIL(Fin de archivo)

Sort Merge Join Por lo tanto, el costo del ordenamiento parcial es: F(lectura) + F(escritura) = 2F (páginas) N = Número de “runs” generadas: N = F/M Ej: Si M = 4 y F = 10 entonces 10/4 = 3 Nótese que el tamaño de cada run es M páginas* * Excepto una de ellas cuando la división no es exacta…

Sort Merge Join 13 3 2 6 1 10 15 7 20 11 8 4 18 5 9 0 12 21 19 14 1 2 3 6 7 10 13 15 0 4 5 8 9 11 18 20 12 14 19 21 Run 1 Run 2 Run 3 Cada run está ordenada

Sort Merge Join Costo del K-way merge Supongamos que hay N = 16 runs ordenadas cada una de 4 páginas. Sea M = 5 Como se requiere una página para generar la salida, se puede usar un 4-way merge como máximo. Gráficamente:

Sort Merge Join Una run de 4 páginas Número de Pasos: LogM-1(N) K-way merge Paso 2: Se lee y escribe cada run cuyo tamaño es 4M (se va leyendo de a una página de cada run y se realiza el K-way merge): Total 2NM páginas Paso 1: Se lee y escribe cada run cuyo tamaño es M (M-1  M) (se va leyendo de a una página de cada run y se realiza el K-way merge): Total 2NM páginas

Sort Merge Join En cada paso se acceden 2NM páginas Por lo tanto, el total de páginas accedidas es: (2NM) * LogM-1(N) Pero NM = F (número de páginas de la relación) y N = F/M, remplazando la fórmula queda: Total de páginas que se accede (lee y escribe) en cada paso Número total de pasos

Sort Merge Join (2F) * LogM-1(F/M) = (2F) * (LogM-1(F) - LogM-1M) = (2F) * (LogM-1(F) - 1)  Costo del K-way merge Por lo tanto, el costo total del ordenamiento es: Costo ordenamiento parcial + Costo del K-way merge: 2F + (2F) * (LogM-1(F) - 1)  1

Sort Merge Join Simplificando: 2F + 2F * LogM-1(F) – 2F Costo del ordenamiento de una relación: 2F * LogM-1(F) Redondeando el logaritmo: 2F * LogM-1(F)  Costo del ordenamiento

Sort Merge Join Por lo tanto, el costo total del Sort Merge Join será: Costo del ordenamiento de cada relación + Costo de la etapa merge del Sort Merge: 2Fr * LogM-1(Fr) + 2Fs * LogM-1(Fs) + Fr + Fs Costo de ordenar r Costo de ordenar s Costo de la mezcla del Sort Merge

2Fr * LogM-1(Fr) + 2Fs * LogM-1(Fs) Sort Merge Join Se han propuesto mejoras al algoritmo Sort Merge donde se fusionan las mezclas de ambos procesos (merge del Sort Merge y merge del K-way) y se evita el acceso (Fr + Fs) Así, el costo del Sort Merge se reduce a: 2Fr * LogM-1(Fr) + 2Fs * LogM-1(Fs)

Sort Merge Join Ej: Sea Fr = 1000, Fs = 100 y M = 102 2(1000) * Log101(1000) + 2(100) * Log101(100) 2000 * 2 + 200 * 1 = 4201 (páginas) Fr M-1 Fr Fs M-1 Fs

Sort Merge Join En este caso el costo dio mayor que el del Block Nested, pero a medida que r y s crecen, el Sort Merge tiene un mejor comportamiento que el Block Nested…

Hash Join 5. Hash Join (Reunión con Dispersión) El hash join se hace en dos etapas: Se hace un proceso de hashing en r sobre el atributo de join (A) Se hace un proceso de hashing en s sobre el atributo de join (B) Esto tiene el efecto de que las tuplas de r y s que posiblemente harán parte del join quedarán en el mismo bucket (cubeta) b. Se hace el join de r y s en cada cubeta para producir así el resultado final (join total).

Hash Join r r1 ⋈ s1 s rn ⋈ sn r1 s1 r1 s1 ⋈ A=B rn sn rn sn ⋈ A=B Input buffer for r r1 s1 r1 s1 ⋈ A=B r1 ⋈ s1 Hash Function Hash Table Buckets s rn sn rn sn ⋈ A=B rn ⋈ sn Input buffer for s Stage 1 Stage 2

Hash Join Costo: Si cada cubeta cabe en memoria el costo es: 3(Fr + Fs) Ya que: r y s se deben leer para generar las cubetas: Fr + Fs Las cubetas resultantes se deben escribir: Fr + Fs Cada cubeta se debe leer para hacer el join: Fr + Fs

Hash Join Para el ejemplo: Fr = 1000, Fs = 100 Costo: 3 (1000 + 100) = 3300 Y aunque el costo es mayor que el del Block Nested, también tiene un comportamiento asintótico mejor que este…

Hash Join Desventajas: Si una cubeta es muy grande y no cabe en memoria, implicaría accesos adicionales Si se elige (o el sistema la provee) una función de hashing inadecuada Nótese que solo sirve para joins basados en condición de igualdad