Compartilhar via

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

  • Artigo

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

O Real-Time Intelligence usa um sistema de cache de dados de várias camadas para garantir um desempenho de consulta rápido. Os dados são armazenados em armazenamento confiável, como o OneLake, mas partes deles são armazenados 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 quentes 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 de acesso mais lento.

O cache usa 95% do disco SSD local para dados quentes. Se não houver espaço suficiente, os dados mais recentes serã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 removerão dados quentes do cache.

O melhor desempenho da 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 ativo. 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 menor 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

Seu cluster foi projetado para consultas ad hoc com conjuntos de resultados intermediários que se encaixam na RAM total do cluster. Para trabalhos grandes, como redução de mapa, pode ser útil armazenar resultados intermediários no armazenamento persistente. Para isso, crie um trabalho de exportação contínuo. 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 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 de ingestão usando a propriedade creationTimede ingestão . Ao fazer isso, verifique se a Lookback propriedade na política de mesclagem de extensões 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 quentes. Uma null política no nível da tabela significa que a política será herdada do banco de dados. Uma política que nãonull seja de nível de tabela substitui uma política de nível de banco de dados.

Definindo o escopo de consultas no cache ativo

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

Observação

O escopo de dados se aplica somente a entidades que oferecem 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 do cluster, que determinam que a consulta deve abranger todos os dados.

Se houver uma discrepância entre os diferentes métodos, 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 ambas.

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 escopo para todos os dados:

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

Política de cache vs 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 consultáveis 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