max_bytes_before_external_distinct
Limiar de memória da consulta, em bytes, para fazer spill de dados deDISTINCT em disco. O uso real de memória pode ultrapassar
esse limiar.
0 desabilita esse limiar. Se max_bytes_ratio_before_external_distinct também definir um limiar,
o menor deles é utilizado. Defina ambas as configurações como 0 para desabilitar o spill.
Consulte DISTINCT em memória externa.
max_bytes_before_external_group_by
Valor padrão no Cloud: metade da memória por réplica. Ativa ou desativa a execução de cláusulasGROUP BY em memória externa.
(Consulte GROUP BY em memória externa)
Valores possíveis:
- Volume máximo de RAM (em bytes) que pode ser usado por uma única operação de GROUP BY.
0—GROUP BYem memória externa desativado.
Se o uso de memória durante operações de GROUP BY exceder esse limite em bytes,
ative o modo de agregação externa (gravando os dados em disco).O valor recomendado é metade da memória disponível no sistema.
max_bytes_before_external_join
Se for definido com um valor diferente de zero, o hash join será convertido automaticamente em grace hash join para permitir o spill em disco quando os dados do lado direito excederem essa quantidade de bytes. Junto commax_bytes_ratio_before_external_join, este é o gatilho de spill baseado em limiar para todo join_algorithm baseado em hash, incluindo grace_hash, que exige que um dos dois seja diferente de zero. Quando um limiar diferente de zero torna uma junção capaz de realizar spill, enable_adaptive_memory_spill_scheduler pode forçá-la a realizar spill sob pressão de memória antes que o limiar seja atingido; com ambas as configurações em 0, a junção nunca realiza spill, portanto o scheduler não tem nada para acionar. A exceção é legacy_join_size_limits_trigger_spilling: quando habilitada, grace_hash independente ignora ambas e realiza spill com base em max_rows_in_join / max_bytes_in_join. Quando definido como 0 (padrão), esse limite absoluto em bytes fica desabilitado, mas o spill automático ainda pode ocorrer por meio de max_bytes_ratio_before_external_join (cujo valor padrão é 0.5); defina ambos como 0 para desabilitar completamente o spill automático. Isso impede a otimização de leitura read in order por meio de join.
max_bytes_before_external_sort
Valor padrão no Cloud: metade da memória por réplica. Habilita ou desabilita a execução de cláusulasORDER BY na memória externa. Consulte Detalhes de implementação do ORDER BY
Se o uso de memória durante a operação ORDER BY exceder esse limite em bytes, o modo de “ordenação externa” (gravar dados em disco) será ativado.
Valores possíveis:
- Volume máximo de RAM (em bytes) que pode ser usado por uma única operação ORDER BY. O valor recomendado é metade da memória disponível no sistema
0—ORDER BYna memória externa desabilitado.
max_bytes_before_remerge_sort
No caso de ORDER BY com LIMIT, quando o uso de memória for maior que o limite especificado, execute etapas adicionais de mesclagem de blocos antes da mesclagem final para manter apenas as primeiras LIMIT linhas.max_bytes_for_lazy_final
Número máximo de bytes no conjunto para a otimização lazy do FINAL. Se esse limite for excedido, volta para o FINAL normal.max_bytes_in_distinct
O número máximo de bytes do estado (em bytes não comprimidos) na memória usado por uma tabela hash ao utilizar DISTINCT.max_bytes_in_join
O tamanho máximo, em bytes, da estrutura de dados do lado direito (geralmente, uma tabela hash) usada em junções entre tabelas. Essa configuração se aplica às operações SELECT … JOIN e ao Join table engine. Se uma consulta contiver várias junções, o ClickHouse verificará essa configuração para cada resultado intermediário. Trata-se de um limite rígido para todojoin_algorithm baseado em hash: quando o limite
é atingido, a consulta lança um erro ou interrompe conforme
join_overflow_mode.
Ela nunca faz uma junção gravar em disco (spill) — essa decisão cabe a
max_bytes_before_external_join
e
max_bytes_ratio_before_external_join.
Por ser um limite rígido e não um gatilho, defini-la em um valor igual ou inferior ao limiar de spill
normalmente faz a consulta falhar antes que a junção possa sequer fazer spill —
a menos que a junção suporte spill e enable_adaptive_memory_spill_scheduler
force um spill primeiro, ou que
legacy_join_size_limits_trigger_spilling transforme esse limite novamente em um gatilho de spill
para a parte de uma junção que já é executada em disco.
O limite contabiliza o que as tabelas hash armazenam, de modo que uma junção que fez spill o atinge à
medida que cada bucket é carregado, e não enquanto o lado direito é lido: ela pode ler mais
do lado direito antes de parar do que um hash join em memória faria.
Valores possíveis:
- Inteiro positivo.
- 0 — O controle de memória está desabilitado.
max_bytes_in_set
O número máximo de bytes (de dados não comprimidos) usados por um conjunto criado a partir de uma subconsulta na cláusula IN.max_bytes_ratio_before_external_distinct
Fração da memória disponível do servidor ou do usuário usada para calcular o limiar doDISTINCT externo no
início da execução. Por exemplo, 0.5 usa metade da memória disponível.
Os valores devem ser no mínimo 0 e menores que 1. 0 desabilita esse limiar. Sem um limite de memória
aplicável de servidor ou de usuário, a razão não tem efeito.
max_memory_usage não afeta esse cálculo. Para configurar o spill em relação a esse limite,
use max_bytes_before_external_distinct, deixando espaço para uso adicional de memória.
max_bytes_ratio_before_external_group_by
A razão da memória disponível que pode ser usada peloGROUP BY. Ao atingir esse limite,
a memória externa é usada para agregação.
Por exemplo, se definido como 0.6, o GROUP BY permitirá usar 60% da memória disponível
(para servidor/usuário/merges) no início da execução; depois disso,
começará a usar agregação externa.
max_bytes_ratio_before_external_join
A razão da memória disponível que pode ser usada peloJOIN. Quando esse limite é atingido, o hash join será convertido em grace hash join para gravar em disco os dados do lado direito.
Por exemplo, se definido como 0.6, o JOIN permitirá usar 60% da memória disponível (para servidor/usuário/merges) para a tabela hash do lado direito no início da execução; depois disso, começará a gravar em disco.
Se max_bytes_before_external_join e max_bytes_ratio_before_external_join estiverem ambos definidos, será usado o menor limiar resultante. Se a razão for 0, somente a configuração absoluta se aplica.
Tem efeito para todo join_algorithm baseado em hash, incluindo grace_hash, desde que um caminho temporário de dados esteja configurado.
max_bytes_ratio_before_external_sort
A razão da memória disponível que pode ser usada peloORDER BY. Quando esse limite é atingido, a ordenação externa é usada.
Por exemplo, se definido como 0.6, o ORDER BY permitirá usar 60% da memória disponível (para servidor/usuário/merges) no início da execução; depois disso, começará a usar ordenação externa.
Observe que max_bytes_before_external_sort continua sendo respeitado; o spill em disco será feito apenas se o bloco de ordenação for maior que max_bytes_before_external_sort.
max_bytes_to_read
O número máximo de bytes (de dados não comprimidos) que pode ser lido de uma tabela ao executar uma consulta. A restrição é verificada para cada fragmento de dados processado, aplicada apenas à expressão de tabela mais profunda e, ao ler de um servidor remoto, verificada apenas no servidor remoto.max_bytes_to_read_leaf
O número máximo de bytes (de dados não comprimidos) que podem ser lidos de uma tabela local em um nó folha ao executar uma consulta distribuída. Embora consultas distribuídas possam emitir várias subconsultas para cada shard (folha), esse limite será verificado apenas no estágio de leitura nos nós folha e será ignorado no estágio de mesclagem dos resultados no nó raiz. Por exemplo, um cluster consiste em 2 shards, e cada shard contém uma tabela com 100 bytes de dados. Uma consulta distribuída que deve ler todos os dados de ambas as tabelas com a configuraçãomax_bytes_to_read=150 falhará, pois o total
será de 200 bytes. Uma consulta com max_bytes_to_read_leaf=150 terá êxito, já que
os nós folha lerão no máximo 100 bytes.
A restrição é verificada para cada fragmento de dados processado.
Essa configuração é instável com
prefer_localhost_replica=1.max_bytes_to_sort
O número máximo de bytes antes da ordenação. Se for necessário processar, na operação ORDER BY, mais bytes não comprimidos do que a quantidade especificada, o comportamento será determinado porsort_overflow_mode, que por padrão é definido como throw.