Optimiza la comunicación entre ranuras

Cuando evalúas tu capacidad de procesamiento de comunicación, considera la cantidad de redistribución que requiere tu consulta. ¿Cuántos bytes se transfieren entre etapas? ¿Cuántos bytes se transfieren a cada ranura? Por ejemplo, una cláusula GROUP BY transfiere valores similares a la misma ranura para procesar. La cantidad de datos que se redistribuyen tiene un impacto directo en la capacidad de procesamiento de comunicación y, como consecuencia, en el rendimiento de la consulta.

Las siguientes recomendaciones son una guía para controlar la comunicación entre ranuras.

Reduce los datos antes de usar una JOIN

Recomendación: Reduce la cantidad de datos procesados antes de una cláusula JOIN.

Recorta los datos en la consulta lo antes posible, antes de que esta realice una JOIN. Si reduces los datos con rapidez en el ciclo de procesamiento, la redistribución y otras operaciones complejas solo se ejecutarán en los datos que necesitas.

No trates a las cláusulas WITH como declaraciones preparadas

Recomendación: Usa cláusulas WITH en particular para obtener una mayor legibilidad.

Las cláusulas WITH se usan, en particular, para obtener una mayor legibilidad, ya que no están materializadas. Por ejemplo, poner todas tus consultas en cláusulas WITH y luego ejecutar UNION ALL es un mal uso de la cláusula WITH. Si la consulta aparece en más de una cláusula WITH, se ejecuta en cada cláusula.

Evita las tablas fragmentadas por fecha

Recomendación: No uses tablas fragmentadas por fecha (también conocidas como tablas llamadas por fecha) en lugar de tablas de partición por tiempo.

Las tablas de partición tienen un mejor rendimiento que las tablas llamadas por fecha. Cuando creas tablas fragmentadas por fecha, BigQuery debe mantener una copia del esquema y los metadatos para cada tabla llamada por fecha. Además, cuando las tablas llamadas por fecha no se usan, BigQuery puede necesitar verificar los permisos para cada tabla consultada. Esta práctica también aumenta la sobrecarga de la consulta y tiene un impacto en su rendimiento.

Evita fragmentar por demás las tablas

Recomendación: Evita crear demasiados fragmentos de tabla. Si fragmentas tablas por fecha, usa en su lugar tablas de partición por tiempo.

La fragmentación de tablas hace referencia a la división de grandes conjuntos de datos en tablas diferentes y al agregado de un sufijo en el nombre de cada una. Si fragmentas tablas por fecha, usa en su lugar tablas de partición por tiempo.

Ya que el almacenamiento de BigQuery tiene un costo bajo, no necesitas optimizar tus tablas por costo como lo harías en un sistema de base de datos relacional. La creación de una gran cantidad de fragmentos de tabla tiene tal impacto en el rendimiento que supera a los beneficios de costo.

Las tablas fragmentadas requieren que BigQuery mantenga el esquema, los metadatos y los permisos para cada fragmento. Debido a la sobrecarga adicional necesaria para mantener la información en cada fragmento, fragmentar por demás las tablas puede tener un impacto en el rendimiento de las consultas.

¿Te sirvió esta página? Envíanos tu opinión:

Enviar comentarios sobre…

¿Necesitas ayuda? Visita nuestra página de asistencia.