Hash join

El algoritmo de la unión “hash join” intenta solucionar el punto débil de la unión “nested loops”: muchos recorridos del B-tree a través de la sentencia interna. En su lugar, se cargan los registros candidatos desde un lado de la unión hacia una tabla hash, que puede ser comparada rápidamente por cada registro contra el otro lado de la unión. Optimizar una unión “hash join” requiere un enfoque de la indexación completamente diferente que la unión “nested loops”. Más allá de eso, es posible mejorar el rendimiento de las uniones “hash join” seleccionando pocas columnas, un reto para la mayoría de las herramientas ORM.

La estrategia de indexación para una unión “hash join” es muy diferente porque no se necesitan indexar las columnas de la unión. Solamente los índices sobre los predicados where independientes mejoran el rendimiento de la unión “hash join”.

Considera el siguiente ejemplo. Selecciona todas las ventas de los últimos seis meses con los detalles correspondientes de los empleados:

SELECT *
  FROM sales s
  JOIN employees e ON (s.subsidiary_id = e.subsidiary_id
                  AND  s.employee_id   = e.employee_id  )
 WHERE s.sale_date > trunc(sysdate) - INTERVAL '6' MONTH

El filtro SALE_DATE es un filtro where independiente. Eso significa que se refiere solamente a una tabla y no pertenece a los predicados de la unión.

La primera etapa de la ejecución es el escaneo de la tabla entera para cargar todos los empleados dentro de la tabla hash (plan id 2). La tabla hash usa los predicados de la unión como llave. En la siguiente etapa, la base de datos hace otro escaneo completo de la tabla SALES y descarta todas las ventas que no cumplen con la condición sobre SALE_DATE (plan id 3). Para los registros restantes de SALES, la base de datos tiene acceso a la tabla “hash” para cargar los detalles correspondientes a los empleados.

El único propósito de la tabla hash es actuar como una estructura temporal en memoria con el fin de evitar tener acceso muchas veces a la tabla EMPLOYEE. La tabla hash se carga inicialmente en una sola iteración así que no existe la necesidad de un índice para traer eficientemente los registros individuales. La información de los predicados confirma que ni un solo filtro es aplicado sobre la tabla EMPLOYEES (plan id 2). La sentencia no tiene ningún predicado independiente sobre esta tabla.

Eso no significa que sea imposible indexar una unión “hash join”. Los predicados independientes pueden ser indexados. Existen condiciones que se aplican durante una de los dos operaciones de accesos. En el ejemplo anterior, corresponde al filtro sobre SALE_DATE.

CREATE INDEX sales_date ON sales (sale_date)

El siguiente plan de ejecución usa ese índice. Sin embargo, utiliza un escaneo de la tabla entera para la tabla EMPLOYEES porque la sentencia no tiene predicados where independientes sobre EMPLOYEES.

Indexar una unión “hash join” es, al contrario de la unión “Nested Loops”, un proceso simétrico. Eso significa que el orden de la unión no afecta a la indexación. El índice SALES_DATE también se puede utilizar para cargar la tabla “hash” si el orden de la unión está invertido.

Un enfoque bastante diferente para optimizar el rendimiento de una unión “hash join” es minimizar el tamaño de la tabla hash. Este método funciona porque una unión “hash join” óptima es posible solamente si la tabla hash entera cabe en memoria. El optimizador utilizará automáticamente el lado más pequeño de la unión para la tabla hash. El plan de ejecución de Oracle muestra los requisitos de memoria estimados en la columna “Bytes”. En el plan de ejecución anterior, la tabla EMPLOYEES necesita nueve megabytes y es el más pequeño de los dos.

También es posible reducir el tamaño de la tabla hash cambiando la sentencia SQL, por ejemplo, agregando unas condiciones adicionales donde la base de datos carga pocos registros candidatos dentro de la tabla hash. Continuando con el ejemplo anterior, podría significar agregar un filtro sobre el atributo DEPARTMENT para que solamente fueran considerados los equipos de ventas. Eso mejora el rendimiento de la unión “hash join” aun si no existe un índice sobre el atributo DEPARTMENT porque la base de datos no necesita almacenar en la tabla “hash” a aquellos empleados que no pueden tener ventas. Al hacer eso, hay que asegurarse de que no existan registros SALES para los empleados que no trabajan en los servicios (DEPARTMENT) respectivos. Usa las restricciones para proteger frente a errores en estas suposiciones.

Cuando se minimiza el tamaño de la tabla hash, el factor relevante no es el número de registros, sino la memoria usada. En realidad, también es posible reducir el tamaño de la tabla hash seleccionando pocas columnas; de hecho, se puede hacer seleccionando solamente los atributos que realmente se necesitan:

SELECT s.sale_date, s.eur_value
     , e.last_name, e.first_name
  FROM sales s
  JOIN employees e ON (s.subsidiary_id = e.subsidiary_id
                  AND  s.employee_id   = e.employee_id  )
 WHERE s.sale_date > trunc(sysdate) - INTERVAL '6' MONTH

Este método introduce pocas veces errores porque borrar la columna incorrecta producirá rápidamente un mensaje de error. Sin embargo, es posible reducir considerablemente el tamaño de la tabla hash; en este caso particular bajar, de 9 megabytes a 234 kilobytes; una reducción del 97%.

--------------------------------------------------------------
| Id | Operation                    | Name      | Bytes| Cost|
--------------------------------------------------------------
|  0 | SELECT STATEMENT             |           | 2067K| 2202|
|* 1 |  HASH JOIN                   |           | 2067K| 2202|
|  2 |   TABLE ACCESS FULL          | EMPLOYEES |  234K|  478|
|  3 |   TABLE ACCESS BY INDEX ROWID| SALES     |  913K| 1724|
|* 4 |    INDEX RANGE SCAN          | SALES_DATE|      |  133|
--------------------------------------------------------------

Aunque a primera vista, parece sencillo quitar unas columnas desde una sentencia SQL, es realmente un desafío cuando se usa una herramienta ORM. El soporte de los llamados objetos parciales es muy escaso. Los siguientes ejemplos muestran algunas posibilidades.

Si te gusta mi manera de explicar, te encantará mi libro.