Compartilhar via

Política de cache (cache em armazenamento hot e cold)

  • Artigo

Aplica-se a: ✅Microsoft Fabric✅Azure Data Explorer

Para garantir um desempenho rápido da consulta, um sistema de cache de dados de várias camadas é usado. Os dados são armazenados em armazenamento confiável, mas partes deles são armazenadas em cache em nós de processamento, SSD ou até mesmo na RAM para acesso mais rápido.

A política de cache permite que você escolha quais dados devem ser armazenados em cache. Você pode diferenciar entre cache de dados quente e cache de dados frios definindo uma política de cache em dados quentes. Os dados quentes são mantidos no armazenamento SSD local para um desempenho de consulta mais rápido, enquanto os dados frios são armazenados em armazenamento confiável, que é mais barato, mas mais lento de acessar.

O cache usa 95% do disco SSD local para dados quentes. Se não houver espaço suficiente, os dados mais recentes são preferencialmente mantidos no cache. Os 5% restantes são usados para dados que não são categorizados como quentes. Esse design garante que as consultas que carregam muitos dados frios não expulsem os dados quentes do cache.

O melhor desempenho de consulta é obtido quando todos os dados ingeridos são armazenados em cache. No entanto, certos dados podem não justificar a despesa de serem mantidos no cache quente. Por exemplo, registros de log antigos acessados com pouca frequência podem ser considerados menos cruciais. Nesses casos, as equipes geralmente optam por um desempenho de consulta mais baixo em vez de pagar para manter os dados aquecidos.

Use comandos de gerenciamento para alterar a política de cache no nível do banco de dados, da tabela ou da exibição materializada.

Observação

Para obter informações sobre a taxa de consumo, consulte Consumo do banco de dados Eventhouse e KQL.

Use comandos de gerenciamento para alterar a política de cache no nível de cluster, banco de dados, tabela ou exibição materializada.

Dica

Seu cluster foi projetado para consultas ad hoc com conjuntos de resultados intermediários que se ajustam à RAM total do cluster. Para trabalhos grandes, como map-reduce, pode ser útil armazenar resultados intermediários no armazenamento persistente. Para fazer isso, crie um trabalho de exportação contínua. Esse recurso permite que você faça consultas em lote de longa execução usando serviços como HDInsight ou Azure Databricks.

Como a política de cache é aplicada

Quando os dados são ingeridos, o sistema controla a data e a hora da ingestão e a extensão em que foram criados. O valor de data e hora de ingestão da extensão (ou valor máximo, se uma extensão foi criada a partir de várias extensões preexistentes) é usado para avaliar a política de cache.

Observação

Você pode especificar um valor para a data e hora de assimilação usando a propriedade creationTimede assimilação . Ao fazer isso, certifique-se de que a Lookback propriedade na política de mesclagem de extensões efetiva da tabela esteja alinhada com os valores definidos para creationTime.

Por padrão, a política efetiva é null, o que significa que todos os dados são considerados quentes. Uma null política no nível da tabela significa que a política é herdada do banco de dados. Uma política que não é denull nível de tabela substitui uma política de nível de banco de dados.

Definindo o escopo de consultas para cache quente

Ao executar consultas, você pode limitar o escopo para consultar apenas dados no cache quente.

Observação

O escopo de dados se aplica somente a entidades que dão suporte a políticas de cache, como tabelas e exibições materializadas. Ele é ignorado para outras entidades, como tabelas externas e dados no repositório de linhas.

Existem várias possibilidades de consulta:

  • Adicione uma propriedade de solicitação de cliente chamada query_datascope à consulta. Valores possíveis: default, all e hotcache.
  • Use uma set instrução no texto da consulta: set query_datascope='...'. Os valores possíveis são os mesmos da propriedade de solicitação do cliente.
  • Adicione um datascope=... texto imediatamente após uma referência de tabela no corpo da consulta. Os valores possíveis são all e hotcache.

O default valor indica o uso das configurações padrão, que determinam que a consulta deve abranger todos os dados.

Se houver uma discrepância entre os diferentes métodos, o então set terá precedência sobre a propriedade de solicitação do cliente. A especificação de um valor para uma referência de tabela tem precedência sobre ambos.

Por exemplo, na consulta a seguir, todas as referências de tabela usam apenas dados de cache quente, exceto a segunda referência a "T" que tem como escopo todos os dados:

set query_datascope="hotcache";
T | union U | join (T datascope=all | where Timestamp < ago(365d)) on X

Política de cache versus política de retenção

A política de cache é independente da política de retenção:

  • A política de cache define como priorizar recursos. As consultas de dados importantes são mais rápidas.
  • A política de retenção define a extensão dos dados que podem ser consultados em uma tabela/banco de dados (especificamente, SoftDeletePeriod).

Configure essa política para obter o equilíbrio ideal entre custo e desempenho, com base no padrão de consulta esperado.

Exemplo:

  • SoftDeletePeriod = 56d
  • hot cache policy = 28d

No exemplo, os últimos 28 dias de dados são armazenados no SSD e os 28 dias adicionais de dados são armazenados no armazenamento de blobs do Azure. Você pode executar consultas nos 56 dias completos de dados.

Conteúdo relacionado