Analítica en tiempo realData warehousingObservabilidadAI/MLCloudOss
Requisitos previos
- A running ClickHouse Cloud service. If you don’t have one yet, complete the Create your first Cloud service quickstart first.
uk_price_paid creada en ella.
Lo que crearás
uk_price_paid por town o county requiere un escaneo completo de la tabla porque está ordenada por (postcode, addr1, addr2).
En esta guía de inicio rápido resolverás ese problema creando una vista materializada que almacena los mismos datos ordenados por (town, date), lo que permite búsquedas rápidas por localidad sin modificar la tabla original.
Al final, entenderás cómo funcionan las vistas materializadas como desencadenador de inserción, cómo cargar datos históricos ya existentes y la compensación en espacio de disco que implica almacenar los datos dos veces.
Comprenda por qué necesita una vista materializada
Su tablauk_price_paid está ordenada por (postcode, addr1, addr2). Esto significa que ClickHouse puede omitir grandes bloques de datos cuando filtra por postcode, addr1 o addr2, pero las consultas que filtran por town deben examinar todas las filas: los 30 millones.Podría crear una segunda tabla con un ORDER BY distinto, pero entonces tendría que acordarse de insertar en ambas tablas cada vez que lleguen datos nuevos. Una vista materializada automatiza esto: detecta las inserciones en una tabla de origen, transforma las filas y las escribe automáticamente en una tabla de destino.Piense en una vista materializada como un trigger de inserción: cada vez que se insertan filas en la tabla de origen, la consulta SELECT de la MV se ejecuta sobre el nuevo bloque de filas y el resultado se inserta en la tabla de destino.Crear la tabla de destino
Una vista materializada necesita algún lugar donde almacenar su resultado. Se trata simplemente de una tabla MergeTree normal; tienes control total sobre su esquema,ORDER BY y PARTITION BY.Crea una tabla ordenada por (town, date) con solo las columnas que necesitas para las consultas por ciudad:Cree la vista materializada
Ahora, cree la vista materializada que conecta la tabla de origen (uk_price_paid) con la tabla de destino (uk_price_paid_by_town):TO uk_price_paid_by_town le indica a ClickHouse que escriba el resultado de SELECT en la tabla de destino. A partir de ahora, cada vez que se insertan filas en uk_price_paid, esta vista materializada se activa e inserta las filas transformadas en uk_price_paid_by_town.Hay una salvedad importante: las vistas materializadas solo se activan con inserciones. Si eliminas o actualizas filas en la tabla de origen, la tabla de destino no tiene forma de saberlo; las vistas materializadas no se mantienen sincronizadas con eliminaciones ni actualizaciones. Si necesitas ese tipo de sincronización, considera usar proyecciones en su lugar.Rellenar los datos históricos existentes
La vista materializada solo procesa inserciones futuras. Los 30 millones de filas que ya hay enuk_price_paid se insertaron antes de que existiera la MV, por lo que la tabla de destino está vacía en este momento.Rellénela manualmente:Consultar la tabla de destino de la vista materializada
Ahora ejecuta una consulta con un filtro portown en la tabla de destino y compárala con una consulta directa a la tabla de origen.Primero, consulta la tabla de origen:town no está en el ORDER BY de la tabla de origen.Ahora ejecuta la misma consulta en la tabla de destino de la vista materializada:(town, date) y ClickHouse puede omitir todos los datos que no coinciden con LONDON.Ejecuta SHOW TABLES para ver qué se ha creado:uk_price_paid_by_town (la tabla de destino) como uk_price_paid_by_town_mv (la vista). Como usaste CREATE MATERIALIZED VIEW ... TO, puedes controlar el nombre de la tabla de destino. Si omites la cláusula TO, ClickHouse crea una tabla de destino con un nombre implícito (.inner.xxx), con la que es más difícil trabajar directamente.
Por ello, se recomienda crear vistas materializadas con la cláusula TO.Observa que los datos se almacenan por duplicado
Las vistas materializadas te ofrecen lecturas más rápidas a costa de ocupar más espacio en disco. Consultasystem.parts para ver cuánto espacio usa cada tabla:uk_price_paid, ordenados por (postcode, addr1, addr2), y otra en uk_price_paid_by_town, ordenados por (town, date). Esta es la compensación fundamental: se utiliza más espacio en disco a cambio de lecturas más rápidas para distintos patrones de acceso.La tabla de destino puede ocupar menos espacio en disco porque contiene menos columnas y el orden de clasificación (town, date) puede comprimirse de forma distinta al original.