La caché de condiciones de consulta solo funciona cuando enable_analyzer está establecido en true, que es el valor predeterminado.
WHERE col = 'xyz') sobre los mismos datos siempre devolverá los mismos resultados.
Más concretamente, la caché de condiciones de consulta recuerda, para cada filtro evaluado y cada gránulo (= un bloque de 8192 filas de forma predeterminada), si ninguna fila del gránulo satisface la condición de filtro.
La información se registra como un único bit: un bit 0 representa que ninguna fila coincide con el filtro, mientras que un bit 1 significa que existe al menos una fila coincidente.
En el primer caso, ClickHouse puede omitir el gránulo correspondiente durante la evaluación del filtro; en el segundo, el gránulo debe cargarse y evaluarse.
La caché de condiciones de consulta es eficaz si se cumplen tres requisitos previos:
- En primer lugar, la carga de trabajo debe evaluar repetidamente las mismas condiciones de filtro. Esto ocurre de forma natural si una consulta se repite varias veces, pero también puede suceder si dos consultas comparten los mismos filtros, p. ej.
SELECT product FROM products WHERE quality > 3ySELECT vendor, count() FROM products WHERE quality > 3. - En segundo lugar, la mayor parte de los datos es inmutable, es decir, no cambia entre consultas. En general, este es el caso en ClickHouse, ya que las partes son inmutables y solo se crean mediante INSERTs.
- En tercer lugar, los filtros son selectivos, es decir, solo relativamente pocas filas satisfacen la condición de filtro. Cuantas menos filas coincidan con la condición de filtro, más gránulos se registrarán con el bit 0 (sin filas coincidentes) y más datos podrán descartarse en evaluaciones posteriores del filtro.
Consumo de memoria
query_condition_cache_size (valor predeterminado: 100 MB).
Un tamaño de caché de 100 MB corresponde a 100 * 1024 * 1024 * 8 = 838,860,800 entradas.
Dado que cada entrada representa una marca (8192 filas de forma predeterminada), la caché puede abarcar hasta 6,871,947,673,600 (6,8 billones) de filas de una sola columna.
En la práctica, los filtros suelen evaluarse sobre más de una columna, por lo que ese número debe dividirse por la cantidad de columnas filtradas.
Configuración y uso
use_query_condition_cache = true, utilizarán la caché de condiciones de consulta para escanear menos datos.
Consultas ORDER BY ... LIMIT n (TopK)
ORDER BY <column> LIMIT n, acelerada mediante filtrado dinámico o un índice de omisión minmax en la columna de ordenación) también utilizan la caché de condiciones de consulta.
Las lecturas TopK pueden omitir gránulos según un umbral que cambia mientras se ejecuta la consulta, por lo que sus entradas de caché se particionan según los parámetros del plan TopK y el conjunto de partes leídas: solo una consulta con el mismo plan sobre las mismas partes las reutiliza.
Estas lecturas pueden excluirse por completo de la caché con la configuración use_query_condition_cache_for_top_k (predeterminado: habilitado), que solo surte efecto si use_query_condition_cache también está habilitada.
Administración
SYSTEM CLEAR QUERY CONDITION CACHE.
El contenido de la caché se muestra en la tabla del sistema system.query_condition_cache.
Para calcular el tamaño actual de la caché de condiciones de consulta en MB, ejecute SELECT formatReadableSize(sum(entry_size)) FROM system.query_condition_cache.
Si desea examinar condiciones de filtro individuales, puede consultar el campo condition en system.query_condition_cache. Tenga en cuenta que este campo solo está disponible en compilaciones de depuración.
El número de aciertos y fallos de la caché de condiciones de consulta desde el inicio de la base de datos se muestra como los eventos “QueryConditionCacheHits” y “QueryConditionCacheMisses” en la tabla del sistema system.events.
Ambos contadores solo se actualizan para consultas SELECT que se ejecutan con la configuración use_query_condition_cache = true; otras consultas no afectan a “QueryCacheMisses”.