max_bytes_before_external_distinct
Umbral de memoria de la consulta, en bytes, a partir del cual los datos deDISTINCT se vuelcan a disco. El uso real de memoria puede superar
este umbral.
Con 0 se deshabilita este umbral. Si max_bytes_ratio_before_external_distinct también define un umbral,
se utiliza el menor de ambos. Establezca ambas configuraciones en 0 para deshabilitar el volcado.
Consulte DISTINCT en memoria externa.
max_bytes_before_external_group_by
Valor predeterminado de Cloud: la mitad de la memoria por réplica. Habilita o deshabilita la ejecución de cláusulasGROUP BY en memoria externa.
(Véase GROUP BY en memoria externa)
Valores posibles:
- Volumen máximo de RAM (en bytes) que puede usar una sola operación GROUP BY.
0—GROUP BYen memoria externa deshabilitado.
Si el uso de memoria durante las operaciones de GROUP BY supera este umbral en bytes,
active el modo de ‘aggregación externa’ (volcar datos a disco).El valor recomendado es la mitad de la memoria disponible del sistema.
max_bytes_before_external_join
Si se establece en un valor distinto de cero, el hash join se convertirá automáticamente en grace hash join para habilitar el volcado a disco cuando los datos del lado derecho superen esta cantidad de bytes. Junto conmax_bytes_ratio_before_external_join, constituye el disparador de volcado basado en umbral para todo join_algorithm basado en hash, incluido grace_hash, que requiere que uno de los dos sea distinto de cero. Una vez que un umbral distinto de cero hace que un join pueda volcar, enable_adaptive_memory_spill_scheduler puede forzarlo a volcar bajo presión de memoria antes de que se alcance el umbral; con ambas configuraciones en 0, el join nunca vuelca, por lo que el planificador no tiene nada que disparar. La excepción es legacy_join_size_limits_trigger_spilling: con esta opción activada, grace_hash independiente ignora ambas y vuelca según max_rows_in_join / max_bytes_in_join. Cuando se establece en 0 (valor predeterminado), este umbral absoluto en bytes se desactiva, pero el volcado automático puede seguir produciéndose mediante max_bytes_ratio_before_external_join (cuyo valor predeterminado es 0.5); establezca ambos en 0 para desactivar por completo el volcado automático. Impide la optimización de read in order a través de join.
max_bytes_before_external_sort
Valor predeterminado en Cloud: la mitad de la memoria por réplica. Habilita o deshabilita la ejecución de cláusulasORDER BY en memoria externa. Consulte Detalles de implementación de ORDER BY
Si el uso de memoria durante la operación ORDER BY supera este umbral en bytes, se activa el modo de “ordenación externa” (volcado de datos a disco).
Valores posibles:
- Volumen máximo de RAM (en bytes) que puede usar una única operación ORDER BY. El valor recomendado es la mitad de la memoria disponible del sistema
0—ORDER BYen memoria externa deshabilitado.
max_bytes_before_remerge_sort
En caso de usar ORDER BY con LIMIT, cuando el uso de memoria supere el umbral especificado, realiza pasos adicionales de combinación de bloques antes de la fusión final para conservar solo las primeras filas del LIMIT.max_bytes_for_lazy_final
Número máximo de bytes en el conjunto para la optimización FINAL diferida. Si se supera, se recurre a FINAL normal.max_bytes_in_distinct
El número máximo de bytes del estado en memoria (en bytes sin comprimir) que utiliza una tabla hash al usar DISTINCT.max_bytes_in_join
El tamaño máximo en bytes de la estructura de datos del lado derecho (normalmente, una tabla hash) que se utiliza al unir tablas. Esta configuración se aplica a las operaciones SELECT … JOIN y al motor de tabla Join. Si una consulta contiene varios joins, ClickHouse comprueba esta configuración en cada resultado intermedio. Es un tope estricto para todojoin_algorithm basado en hash: cuando se alcanza
el límite, la consulta lanza un error o se interrumpe según
join_overflow_mode.
Nunca hace que un join haga spill a disco; esa decisión corresponde a
max_bytes_before_external_join
y a
max_bytes_ratio_before_external_join.
Dado que es un tope y no un disparador, establecerlo en el umbral de spill o por debajo de él
normalmente hace que la consulta falle antes de que el join pueda hacer spill,
salvo que el join admita spill y enable_adaptive_memory_spill_scheduler
fuerce primero un spill, o que
legacy_join_size_limits_trigger_spilling convierta de nuevo este límite en un disparador
de spill para la parte de un join que ya se ejecuta en disco.
El límite contabiliza lo que contienen las tablas hash, por lo que un join que hizo spill lo alcanza a
medida que se carga cada bucket y no mientras se lee el lado derecho: puede leer más
del lado derecho antes de detenerse de lo que lo haría un hash join en memoria.
Valores posibles:
- Entero positivo.
- 0 — El control de memoria está deshabilitado.
max_bytes_in_set
El número máximo de bytes (de datos no comprimidos) que puede usar un Set de la cláusula IN creado a partir de una subconsulta.max_bytes_ratio_before_external_distinct
Fracción de la memoria disponible del servidor o del usuario que se emplea para calcular el umbral deDISTINCT externo al
inicio de la ejecución. Por ejemplo, 0.5 utiliza la mitad de la memoria disponible.
Los valores deben ser como mínimo 0 y menores que 1. 0 desactiva este umbral. Si no hay un memory limit aplicable
de servidor o de usuario, la proporción no surte efecto.
max_memory_usage no influye en este cálculo. Para configurar el volcado a disco en relación con ese límite,
utilice max_bytes_before_external_distinct, dejando margen para un uso de memoria adicional.
max_bytes_ratio_before_external_group_by
La proporción de la memoria disponible que puede usarse paraGROUP BY. Una vez alcanzado este valor,
se utiliza memoria externa para la agregación.
Por ejemplo, si se establece en 0.6, GROUP BY permitirá usar el 60 % de la memoria disponible
(para server/user/merges) al inicio de la ejecución; a partir de ese momento,
empezará a usar agregación externa.
max_bytes_ratio_before_external_join
La proporción de memoria disponible que se permite paraJOIN. Una vez alcanzada, el hash join se convertirá en grace hash join para volcar en disco los datos del lado derecho.
Por ejemplo, si se establece en 0.6, JOIN permitirá usar el 60% de la memoria disponible (para server/user/merges) para la tabla hash del lado derecho al comienzo de la ejecución; a partir de ese momento, comenzará a volcar datos a disco.
Si se establecen tanto max_bytes_before_external_join como max_bytes_ratio_before_external_join, se usa el umbral resultante más bajo. Si la proporción es 0, solo se aplica la configuración absoluta.
Tiene efecto en todos los join_algorithm basados en hash, incluido grace_hash, siempre que haya configurada una ruta de datos temporales.
max_bytes_ratio_before_external_sort
La proporción de la memoria disponible que puede usarse paraORDER BY. Al alcanzarse, se utiliza la ordenación externa.
Por ejemplo, si se establece en 0.6, ORDER BY permitirá usar el 60% de la memoria disponible (para server/user/merges) al inicio de la ejecución; a partir de ese momento, empezará a usar ordenación externa.
Tenga en cuenta que max_bytes_before_external_sort sigue respetándose; el volcado a disco solo se realizará si el bloque de ordenación es mayor que max_bytes_before_external_sort.
max_bytes_to_read
El número máximo de bytes (de datos sin comprimir) que se pueden leer de una tabla al ejecutar una consulta. La restricción se comprueba para cada fragmento de datos procesado, se aplica solo a la expresión de tabla más interna y, al leer desde un servidor remoto, se comprueba solo en el servidor remoto.max_bytes_to_read_leaf
La cantidad máxima de bytes (de datos sin comprimir) que se pueden leer de una tabla local en un nodo hoja al ejecutar una consulta distribuida. Aunque las consultas distribuidas pueden emitir varias subconsultas a cada segmento (hoja), este límite solo se comprobará en la etapa de lectura en los nodos hoja y se ignorará en la etapa de combinación de resultados en el nodo raíz. Por ejemplo, un clúster consta de 2 segmentos y cada segmento contiene una tabla con 100 bytes de datos. Una consulta distribuida que deba leer todos los datos de ambas tablas con la configuraciónmax_bytes_to_read=150 fallará, ya que en total
serán 200 bytes. Una consulta con max_bytes_to_read_leaf=150 tendrá éxito, puesto que
los nodos hoja leerán como máximo 100 bytes.
La restricción se comprueba para cada fragmento de datos procesado.
Esta configuración es inestable con
prefer_localhost_replica=1.max_bytes_to_sort
El número máximo de bytes antes de la ordenación. Si es necesario procesar una cantidad de bytes sin comprimir superior a la especificada para la operación ORDER BY, el comportamiento vendrá determinado porsort_overflow_mode, que de forma predeterminada está establecido en throw.