Cómo evitar antipatrones de SQL

Las siguientes prácticas recomendadas proporcionan una guía para evitar los antipatrones de consulta que afectan el rendimiento en BigQuery.

Uniones automáticas

Práctica recomendada: Evita las uniones automáticas. Usa una función de ventana en su lugar.

Por lo general, las uniones automáticas se usan para procesar relaciones dependientes de las filas. El resultado de usar una unión automática es que se podría duplicar el número de filas de salida. Este aumento en los datos salientes puede provocar un rendimiento bajo.

En lugar de usar una unión automática, utiliza una función de ventana (analítica) para reducir el número de bytes adicionales que genera la consulta.

Sesgo de datos

Práctica recomendada: Si tu consulta procesa claves que están muy sesgadas a unos pocos valores, filtra tus datos lo antes posible.

El sesgo de partición, a veces llamado sesgo de datos, ocurre cuando los datos se dividen en particiones de tamaño muy desigual. Esto crea un desequilibrio en la cantidad de datos enviados entre las ranuras. No puedes compartir particiones entre ranuras, por lo que si una partición es especialmente grande, puede ralentizarse o incluso bloquear la ranura que procesa la partición de gran tamaño.

Las particiones aumentan de tamaño cuando tu clave de partición tiene un valor que ocurre con más frecuencia que cualquier otro valor. Por ejemplo, agrupar por el campo user_id donde hay muchas entradas para guest o null.

Cuando los recursos de una ranura están atestados, se produce un error resources exceeded. Alcanzar el límite de combinaciones para una ranura (2 TB en la memoria comprimida) también provoca que la combinación escriba en el disco y afecte aún más el rendimiento. Los clientes con precios de tarifa plana pueden aumentar el número de ranuras asignadas.

Si examinas el plan explicativo de la consulta y ves una diferencia significativa entre los tiempos de procesamiento promedio y máximo, es probable que tus datos estén sesgados.

Para evitar problemas de rendimiento provocados por el sesgo de datos:

  • Usa una función agregada aproximada como APPROX_TOP_COUNT para determinar si los datos están sesgados.
  • Filtra tus datos lo antes posible.

Uniones desequilibradas

El sesgo de datos también puede aparecer cuando usas cláusulas JOIN. Dado que BigQuery combina los datos en cada lado de la unión, todos los datos con la misma clave de unión van a la misma fragmentación. Esta combinación puede sobrecargar la ranura.

Para evitar problemas de rendimiento asociados con uniones desequilibradas:

  • Realiza un filtro previo a las filas de la tabla con la clave desequilibrada.
  • Si es posible, divide la consulta en dos consultas.

Uniones cruzadas (producto cartesiano)

Práctica recomendada: Evita las uniones que generan más salidas que entradas. Cuando se requiere un CROSS JOIN, agrega previamente tus datos.

Las uniones cruzadas son consultas donde cada fila de la primera tabla se une a cada fila de la segunda tabla (hay claves no únicas en ambos lados). El resultado en el peor caso es el número de filas en la tabla de la izquierda multiplicado por el número de filas en la tabla de la derecha. En casos extremos, la consulta podría no finalizarse.

Si el trabajo de consulta se completa, la explicación del plan de consulta mostrará las filas de salida versus las filas de entrada. Puedes confirmar un producto cartesiano modificando la consulta para imprimir el número de filas a cada lado de la cláusula JOIN, agrupadas por la clave de unión.

Para evitar problemas de rendimiento asociados con uniones que generan más salidas que entradas:

  • Usa una cláusula GROUP BY para agregar previamente los datos.
  • Usa una función de ventana. Las funciones de ventana son a menudo más eficientes que las uniones cruzadas. Para obtener más información, consulta funciones analíticas.

Declaraciones DML que actualizan o insertan filas individuales

Práctica recomendada: Evita las declaraciones DML para un punto en particular (actualizando o insertando 1 fila a la vez). Carga por lotes tus actualizaciones e inserciones.

El uso de declaraciones DML para un punto específico es un intento por tratar a BigQuery como un sistema de procesamiento de transacciones en línea (OLTP). BigQuery se centra en el procesamiento analítico en línea (OLAP) mediante el uso de análisis de tablas y no de consultas de puntos. Si necesitas obtener un comportamiento similar al del OLTP (actualizaciones o inserciones de filas individuales), considera contar con una base de datos que esté diseñada para admitir casos prácticos de OLTP como Google Cloud SQL.

Las declaraciones DML de BigQuery están diseñadas para realizar actualizaciones en forma masiva. Las declaraciones DML UPDATE y DELETE en BigQuery están destinadas a la ejecución de sobrescrituras periódicas de tus datos, no a mutaciones de filas individuales. La declaración DML INSERT está diseñada para ser utilizada con moderación. Las inserciones consumen las mismas cuotas de modificación que los trabajos de carga. Si tu caso práctico implica la ejecución de inserciones frecuentes en filas individuales, considera transmitir tus datos en su lugar.

Si el procesamiento por lotes de tus declaraciones UPDATE produce muchas tuplas en consultas muy largas, puedes acercarte al límite de longitud de la consulta de 256 K. Para evitar sobrepasar el límite de longitud de la consulta, considera si tus actualizaciones pueden manejarse en función de un criterio lógico en lugar de una serie de reemplazos directos de tuplas.

Por ejemplo, podrías cargar tu conjunto de registros de reemplazo en otra tabla y luego escribir la declaración DML para actualizar todos los valores de la tabla original si las columnas no actualizadas coinciden. Por ejemplo, si los datos originales se encuentran en la tabla t y las actualizaciones se almacenan en la tabla u, la consulta tendrá el siguiente aspecto:

UPDATE dataset.t t
SET my_column = u.my_column
FROM dataset.u u
WHERE t.my_key = u.my_key
¿Te ha resultado útil esta página? Enviar comentarios:

Enviar comentarios sobre...

Si necesitas ayuda, visita nuestra página de asistencia.