SELECT una sola vez y servir las ejecuciones posteriores de la misma consulta directamente desde la caché.
Según el tipo de consultas, esto puede reducir drásticamente la latencia y el consumo de recursos del servidor de ClickHouse.
Antecedentes, diseño y limitaciones
- En las cachés transaccionalmente coherentes, la base de datos invalida (descarta) los resultados de consultas almacenados en caché si el resultado de la consulta
SELECTcambia o puede cambiar. En ClickHouse, las operaciones que modifican los datos incluyen inserciones/actualizaciones/eliminaciones en/de tablas o merges de colapso. El almacenamiento en caché transaccionalmente coherente es especialmente adecuado para bases de datos OLTP, por ejemplo MySQL (que eliminó la caché de consultas a partir de la versión 8.0) y Oracle. - En las cachés transaccionalmente incoherentes, se aceptan pequeñas imprecisiones en los resultados de las consultas bajo el supuesto de que a todas las entradas de caché se les
asigna un período de validez tras el cual expiran (p. ej., 1 minuto) y de que los datos subyacentes cambian muy poco durante ese período.
En general, este enfoque es más adecuado para bases de datos OLAP. Como ejemplo de un caso en el que el almacenamiento en caché transaccionalmente incoherente es suficiente,
considere un informe horario de ventas en una herramienta de informes al que acceden simultáneamente varios usuarios. Por lo general, los datos de ventas cambian
lo bastante despacio como para que la base de datos solo necesite calcular el informe una vez (representado por la primera consulta
SELECT). Las consultas posteriores pueden servirse directamente desde la caché de consultas. En este ejemplo, un período de validez razonable podría ser de 30 min.
Ajustes de configuración y uso
En ClickHouse Cloud, debe usar ajustes a nivel de consulta para editar los ajustes de la caché de consultas. Actualmente no se admite la edición de ajustes a nivel de configuración.
clickhouse-local ejecuta una sola consulta a la vez. Como no tiene sentido almacenar en caché los resultados de las consultas, la caché de resultados de consultas está deshabilitada en clickhouse-local.
use_query_cache = true) leerán
el resultado calculado de la caché y lo devolverán inmediatamente.
Establecer
use_query_cache y todos los demás ajustes relacionados con la caché de consultas solo surte efecto en sentencias SELECT independientes. En particular,
los resultados de SELECT sobre vistas creadas mediante CREATE VIEW AS SELECT [...] SETTINGS use_query_cache = true no se almacenan en la caché, a menos que la sentencia SELECT
se ejecute con SETTINGS use_query_cache = true.true). El primero
controla si los resultados de las consultas se almacenan en la caché, mientras que el segundo determina si la base de datos debe intentar recuperar resultados de consultas
desde la caché. Por ejemplo, la siguiente consulta usará la caché solo de forma pasiva; es decir, intentará leer de ella, pero no almacenar su
resultado en ella:
use_query_cache, enable_writes_to_query_cache y
enable_reads_from_query_cache solo en consultas específicas. También es posible habilitar el almacenamiento en caché a nivel de usuario o de perfil (por ejemplo, mediante SET use_query_cache = true), pero debe tenerse en cuenta que, en ese caso, todas las consultas SELECT pueden devolver resultados almacenados en caché.
La caché de consultas puede vaciarse mediante la sentencia SYSTEM CLEAR QUERY CACHE. El contenido de la caché de consultas se muestra en la tabla del sistema
system.query_cache. El número de aciertos y fallos de la caché de consultas desde el inicio de la base de datos se muestra como eventos
“QueryCacheHits” y “QueryCacheMisses” en la tabla del sistema system.events. Ambos contadores solo se actualizan para
consultas SELECT que se ejecutan con el ajuste use_query_cache = true; las demás consultas no afectan a “QueryCacheMisses”. El campo query_cache_usage
en la tabla del sistema system.query_log muestra, para cada consulta ejecutada, si el resultado de la consulta se escribió en
o se leyó de la caché de consultas. Las métricas QueryCacheEntries y QueryCacheBytes en la tabla del sistema
system.metrics muestran cuántas entradas / bytes contiene actualmente la caché de consultas.
La caché de consultas existe una vez por cada proceso del servidor ClickHouse. Sin embargo, de forma predeterminada, los resultados almacenados en caché no se comparten entre usuarios. Esto puede
cambiarse (véase más abajo), pero no se recomienda hacerlo por motivos de seguridad.
Los resultados de las consultas se referencian en la caché de consultas mediante el árbol de sintaxis abstracta (AST) de
la consulta. Esto significa que el almacenamiento en caché no distingue entre mayúsculas y minúsculas; por ejemplo, SELECT 1 y select 1 se tratan como la misma consulta. Para
que la coincidencia sea más natural, todos los ajustes a nivel de consulta relacionados con la caché de consultas y el formato de salida)
se eliminan del AST.
Si la consulta se aborta debido a una excepción o a una cancelación del usuario, no se escribe ninguna entrada en la caché de consultas.
El tamaño de la caché de consultas en bytes, el número máximo de entradas de caché y el tamaño máximo de cada entrada de caché (en bytes y en
registros) pueden configurarse mediante distintas opciones de configuración del servidor.
users.xml y, a continuación, establezca ambas configuraciones como
solo lectura:
Age y Expires con la antigüedad (en segundos) y la marca temporal de expiración de la
entrada almacenada en caché.
Las entradas de la caché de consultas se comprimen de forma predeterminada. Esto reduce el consumo total de memoria a costa de escrituras en / lecturas desde
la caché de consultas más lentas. Para deshabilitar la compresión, use la configuración query_cache_compress_entries.
A veces resulta útil mantener en caché varios resultados de la misma consulta. Esto se puede lograr mediante la configuración
query_cache_tag, que actúa como una etiqueta (o espacio de nombres) para las entradas de la caché de consultas. La caché de consultas
considera distintos los resultados de la misma consulta con diferentes etiquetas.
Ejemplo para crear tres entradas diferentes en la caché de consultas para la misma consulta:
tag de la caché de consultas, puede usar la sentencia SYSTEM CLEAR QUERY CACHE TAG 'tag'.
ClickHouse lee los datos de las tablas en bloques de max_block_size filas. Debido al filtrado, la agregación,
etc., los bloques de resultados suelen ser mucho más pequeños que ‘max_block_size’, aunque también hay casos en los que son mucho mayores. La opción
query_cache_squash_partial_results (habilitada de forma predeterminada) controla si los bloques de resultados
se compactan (si son muy pequeños) o se dividen (si son grandes) en bloques de tamaño ‘max_block_size’ antes de insertarlos en la caché de resultados de consultas.
Esto reduce el rendimiento de las escrituras en la caché de consultas, pero mejora la tasa de compresión de las entradas de caché y proporciona una
granularidad de bloque más natural cuando más adelante los resultados de las consultas se sirven desde la caché de consultas.
Como resultado, la caché de consultas almacena varios bloques de
resultados parciales para cada consulta. Aunque este comportamiento es una buena configuración predeterminada, puede desactivarse con la opción
query_cache_squash_partial_results.
Además, los resultados de consultas con funciones no deterministas no se almacenan en caché de forma predeterminada. Estas funciones incluyen:
- funciones para acceder a diccionarios:
dictGet(), etc. - funciones definidas por el usuario sin la etiqueta
<deterministic>true</deterministic>en su definición XML, - funciones que devuelven la fecha o la hora actuales:
now(),today(),yesterday(), etc., - funciones que devuelven valores aleatorios:
randomString(),fuzzBits(), etc., - funciones cuyo resultado depende del tamaño, el orden o los fragmentos internos usados para el procesamiento de consultas:
nowInBlock(), etc.,rowNumberInBlock(),runningDifference(),blockSize(), etc., - funciones que dependen del entorno:
currentUser(),queryID(),getMacro(), etc.