Mejoras en nuestras consultas

Esto además de ser una reflexión acerca de nuestras consultas, también lo que va a intentar es dar algunos tips de consultas que pueden servir para todos los que trabajan en BI.

Volviendo un poco al pasado, me acuerdo que cuando comencé a trabajar en BI, me toco comenzar a aprender mucho acerca de consultas porque para ese entonces estaba en la moda de ser un programador de java y estaba dando mis primeros pinos en PDH. La primeras consultas que hice fue con mucho miedo porque no quería realizar consultas que fueran a tumbar la base de datos pero la verdad es que trabajaba en una multinacional y por ende tenían una gran máquina, adicional a esto me daba mucho miedo enfrentarme a un súper modelo que me intentaron explicar en dos días y tengo que admitir que dormí en varios momentos de la reunión en la que me estaban explicando el modelo (Modelo de Industria de Teradata para Seguros).

Comencé con consultas pequeñas y las iba guardando para cogerme confianza y a partir de allí iba metiéndoles joins y demás. Sin embargo por el constante pedido de información de los usuarios de áreas como mercadeo comencé a coger más cancha y me puse a hacer consultas de toda índole creyendo que ya sabía de esto.

Después de esto me llego una excelente charla en la que me dijeron ¿Hey cuando tiras un query miras como se hace la consulta? Eso fue como quebrar algo en mi mente y me di cuenta que la mayoría de las BD's (Oracle, Teradata, SQL Server, etc) te dan el chance de mirar el comportamiento de las consultas.

Con ese nuevo conocimiento me fui corriendo a hacer puros explain plan de mis consultas y cuando lo hice me di cuenta de algo, no entendía absolutamente nada de lo que decía allí la base de datos. Fue entonces cuando comencé a leer de índices, primero en Teradata y luego en Oracle que eran los motores de Bases de datos en los que trabajaba por ese entonces.

En Teradata la cogí de una y me di cuenta de varias verdades de Teradata:

1. No existen PK's, todo lo que existen son los índices: Esto es muy potencial si el desarrollador es bueno, pero puede ser perjudicial para una persona que no esté preparada.

2. Lo más importante es el Primary Index (Para Teradata esto es como una PK): Esto porque por medio de esta Teradata hace sus reparticiones en los AMP's (Para mayor información ver la nota LINK DE ARTICULO TERADATA).

3. Los Secundary Index sirven muy poco en Teradata pero pueden mejorar el performance: Esto me dio risa cuando me di cuenta de esto porque yo dije, entonces ¿Cuál es el motivo de que existan? Pues básicamente porque es importante porque pueden ayudar, pero no es garantía porque lo que hace el motor es crear una tabla adicional para guardar donde existe el registro que se refiere a ese valor, pero físicamente la BD no hace más que esto.

Con estos tres tips me fui a leer explain plan, convencido de que los iba a entender y me di cuenta que si los estaba entendiendo mejor porque me estaba dando cuenta en el explain si mi query se iba por un índice primario o secundario. Adicional a esto me daba un estimado del tiempo que se demoraba en cada paso por lo que lograba identificar donde era más costoso hacer el query.

Lo que paso después fue algo sorprendente ¿Me iba a poner a hacer explains y analizar tantas cosas luego de construir mis consultas? Algo mucho pero ¿Iba a Cuestionar a Microstrategy en la construcción de los querys que hace la herramienta para las consultas de la Bodega de Datos?

Muchos me podrán tildar de obvio pero créame que yo en esa época parecía niño estrenando juguete. Adicional esta actitud me ayudo a encontrarme con algo importante y es ¿que tips adicionales puedo tener al momento de crear las consultas?

Me encontré con cosas muy interesantes que me ayudaron mucho:

1. Trate de filtrar las consultas por los índices creados en las tablas para que sean más rápido las consultas.

2. Los joins también en la medida de lo posible, debo hacerlos por los índices de las tablas.

3. Cuando haga un count, hágalo así Select Count(1) from {tabla} en vez de Count(*) from {tabla}, esto a cuenta de que al poner el * hacemos que la base de datos tenga que pasar por todas las columnas de las filas para poder contar el registro, en cambio si lo hago con la constante lo que hace es ver la fila, sin recorrer todas las columnas.

4. La precedencia de los operadores: Esto sí que me ha ayudado porque en la BD se hace más rápido la consulta dependiendo del operador usado en las condiciones (WHERE):

         a. Con un operador como = en vez de poner cualquier otro operador, se hacen las consultas óptimas.

         b. Si se usa el operador Like con %, entonces hágalo así: Select * From {Tabla} Where {Campo} like 'Dieguinho%'; en vez de Select * From {Tabla} Where {Campo} like '%Dieguinho%'; o Select * From {Tabla} Where {Campo} like '%Dieguinho%';, esto a causa de que si lo hacemos de la manera correcta cuando el motor busque se va para todos los valores que tengan Dieguinho al inicio y de ahí devuelve la data más rápido que si lo hace del otro modo, la BD llega la tabla y la recorre toda, haciendo más esfuerzo.

         c. si tiene una consulta de > o < haga lo siguiente: Select * From {tabla} Where {campo1} <= 3; en vez de Select * From {tabla} Where {campo1} < 2; esto a cuenta de cómo operan las BD's porque si se pone de la primera, el busca el igual al tres y de ahí para arriba los devuelve, en cambio sin el igual lo que hace es mirar los datos y comparar si es mayo a dos o no.

         d. No use el NOT por lo mismo, es más fácil para la BD buscar el = o el Like o el Exist que la negación de algo porque debe recorrer toda la tabla.

         e. Use Union en vez de hacer OR en un mismo query.

         f. Ojo con los subquerys, en caso de ser necesario y posible, es mejor hacer esto: Select * From {tabla1} a, (Select * From {Tabla 2} Where {campo1} = 'X') tmp Where a.{campo_join} = b.{campo_join}; en vez de Select * From {tabla1} a where a.{campo_join} in (Select {campo_join} From {Tabla 2} Where {campo1} = 'X');

Luego de esto no me puse a ver explain de todos mis querys, solo de los necesarios y comencé a construir consultas más eficientes y para mis usuarios expertos que hacían sus propios querys, me ayudó a mejorarles sus consultas y esto me ayudó mucho.

En alguna entrada posterior, voy a seguir con esta historia que continua pero con la creación de tablas y todo lo que se debe crear para su optimización porque cronológicamente cuando me vieron hacer consultas eficientes, pase de ser creador de consultas a ser creador de modelos.

:D