Una pregunta habitual entre los usuarios es cuándo deben usar vistas materializadas frente a proyecciones. En este artículo exploraremos las principales diferencias entre ambas y por qué puede convenir elegir una u otra en determinados escenarios.
Resumen de las diferencias clave
Comparación entre vistas materializadas y proyecciones
Cuándo elegir vistas materializadas
- Trabaja con ETL en tiempo real y canalización de datos multietapa: necesita realizar transformaciones complejas, agregaciones o enrutar datos a medida que llegan, incluso a través de varias etapas mediante el encadenamiento de vistas.
- Requiere desnormalización compleja: necesita unir de antemano datos de varias fuentes (tablas, subconsultas o diccionarios) en una sola tabla optimizada para consultas, especialmente si resultan aceptables las actualizaciones completas periódicas mediante vistas materializadas actualizables.
- Quiere control explícito del esquema: necesita una tabla de destino independiente y diferenciada, con su propio esquema y engine para los resultados precalculados, lo que ofrece mayor flexibilidad para el modelado de datos.
- Quiere filtrar durante la ingestión: necesita filtrar los datos antes de materializarlos, reduciendo el volumen de datos escrito en la tabla de destino.
Cuándo evitar las vistas materializadas
- Los datos de origen se actualizan o eliminan con frecuencia: Sin estrategias adicionales para mantener la consistencia entre las tablas de origen y de destino, las vistas materializadas incrementales pueden quedar desactualizadas y perder consistencia.
- Se prefiere la simplicidad y la optimización automática: Si quieres evitar tener que gestionar tablas de destino independientes.
Cuándo elegir proyecciones
- Optimizar consultas para una sola tabla: tu objetivo principal es acelerar las consultas en una única tabla base mediante órdenes de clasificación alternativas, optimizando filtros en columnas que no forman parte de la clave primaria o precalculando agregaciones para una sola tabla.
- Quieres transparencia en las consultas: quieres que las consultas se ejecuten sobre la tabla original sin modificaciones, dejando que ClickHouse elija la mejor disposición de los datos para una consulta determinada.
Cuándo evitar las proyecciones
- Se requieren transformaciones de datos complejas o ETL de varias etapas: Las definiciones de proyecciones no admiten operaciones
JOIN, no pueden encadenarse para crear canalizaciones de varios pasos y no permiten algunas funcionalidades de SQL, como las funciones de ventana o las sentenciasCASEcomplejas. Aunque las consultas sobre tablas con proyecciones pueden usar joins sin restricciones, las proyecciones en sí no son adecuadas para transformaciones de datos complejas. - Se necesita filtrar explícitamente los datos materializados: Las proyecciones no admiten cláusulas
WHEREen su definición para filtrar los datos que se materializan en la propia proyección. - Se usan motores de tabla que no pertenecen a la familia MergeTree: Las proyecciones solo están disponibles para tablas que usan la familia de motores
MergeTree. - Las consultas
FINALson esenciales: Las proyecciones no funcionan con consultasFINAL, que a veces se usan para la deduplicación. - Necesitas réplicas paralelas, ya que no son compatibles con las proyecciones.