Política de cache (cache frequente e frio)

  • Artigo

O Azure Data Explorer usa um sistema de cache de dados de várias camadas para garantir o desempenho rápido da consulta. Os dados são armazenados em armazenamento confiável, como Armazenamento de Blobs do Azure, mas partes deles são armazenadas em cache em nós de processamento, SSD ou até mesmo na RAM para acesso mais rápido.

Real-Time Analytics usa um sistema de cache de dados de várias camadas para garantir o desempenho rápido da consulta. Os dados são armazenados em armazenamento confiável, como o OneLake, 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 o cache de dados frequentes e o cache de dados frios definindo uma política de cache em dados frequentes. Os dados quentes são mantidos no armazenamento SSD local para obter um desempenho de consulta mais rápido, enquanto os dados frios são armazenados no armazenamento confiável, o que é mais barato, mas mais lento para acessar.

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

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

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

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

O cluster foi projetado para consultas ad hoc com conjuntos de resultados intermediários que se ajustam à RAM total do cluster. Para trabalhos grandes, como a redução de mapa, 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 o HDInsight ou o 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 da extensão que foi criada. 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 pré-existentes), é usado para avaliar a política de cache.

Observação

Você pode especificar um valor para a data e hora da ingestão usando a propriedade creationTimede ingestão . Ao fazer isso, verifique se a Lookback propriedade na política de mesclagem extents efetiva da tabela está 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 frequentes. Uma null política no nível da tabela significa que a política será herdada do banco de dados. null Uma política de nível de tabela não substitui uma política no nível do banco de dados.

Escopo de consultas para o cache ativo

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

Observação

O escopo de dados se aplica apenas 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.

Há 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 do cluster, que determinam que a consulta deve abranger todos os dados.

Se houver uma discrepância entre os diferentes métodos, terá set precedência sobre a propriedade de solicitação do cliente. Especificar 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 frequente, exceto para 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 estarão no SSD do cluster e os 28 dias adicionais de dados serão armazenados no Armazenamento de Blobs do Azure. Você pode executar consultas nos 56 dias completos de dados.

Conteúdo relacionado