Política de colocação em cache (cache frequente e fria)

  • Artigo

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

Real-Time Analytics utiliza um sistema de cache de dados de várias camadas para garantir um desempenho de consulta rápido. Os dados são armazenados num armazenamento fiável, como o OneLake, mas partes são colocadas em cache em nós de processamento, SSD ou até mesmo na RAM para um acesso mais rápido.

A política de colocação em cache permite-lhe escolher os dados que devem ser colocados em cache. Pode diferenciar entre a cache de dados frequentes e a cache de dados frios ao definir uma política de colocação em cache em dados frequentes. Os dados frequentes são mantidos no armazenamento SSD local para um desempenho de consultas mais rápido, enquanto os dados frios são armazenados num armazenamento fiável, o que é mais barato, mas mais lento para aceder.

A cache utiliza 95% do disco SSD local para dados frequentes. Se não houver espaço suficiente, os dados mais recentes são guardados preferencialmente na cache. Os restantes 5% são utilizados para dados que não são categorizados como frequentes. Esta estrutura garante que as consultas que carregam muitos dados frios não expulsam dados frequentes da cache.

O melhor desempenho da consulta é alcançado quando todos os dados ingeridos são colocados em cache. No entanto, determinados dados podem não justificar a despesa de serem mantidos na cache frequente. Por exemplo, os registos antigos acedidos com pouca frequência podem ser considerados menos cruciais. Nestes casos, as equipas optam frequentemente por um desempenho de consulta mais baixo em vez de pagarem para manter os dados quentes.

Utilize comandos de gestão para alterar a política de colocação em cache ao nível da base de dados, da tabela ou da vista materializada .

Utilize comandos de gestão para alterar a política de colocação em cache no nível de cluster, base de dados, tabela ou vista materializada .

Dica

O cluster foi concebido para consultas ad hoc com conjuntos de resultados intermédios que se enquadram na RAM total do cluster. Para tarefas grandes, como a redução de mapas, pode ser útil armazenar resultados intermédios no armazenamento persistente. Para tal, crie uma tarefa de exportação contínua . Esta funcionalidade permite-lhe fazer consultas em lote de execução prolongada com serviços como o HDInsight ou o Azure Databricks.

Como é aplicada a política de colocação em cache

Quando os dados são ingeridos, o sistema controla a data e 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 tiver sido criada a partir de múltiplas extensões pré-existentes), é utilizado para avaliar a política de colocação em cache.

Nota

Pode especificar um valor para a data e hora de ingestão com a propriedade creationTimeingestão . Ao fazê-lo, certifique-se de que a Lookback propriedade na política de intercalação Extensões efetiva da tabela está alinhada com os valores que definiu para creationTime.

Por predefinição, a política efetiva é null, o que significa que todos os dados são considerados frequentes. Uma null política ao nível da tabela significa que a política será herdada da base de dados. null Uma política ao nível da tabela substitui uma política ao nível da base de dados.

Análise de consultas para a cache frequente

Ao executar consultas, pode limitar o âmbito a apenas consultar dados na cache frequente.

Nota

O âmbito dos dados aplica-se apenas a entidades que suportam políticas de colocação em cache, como tabelas e vistas materializadas. É ignorado para outras entidades, como tabelas externas e dados no arquivo de linhas.

Existem várias possibilidades de consulta:

  • Adicione uma propriedade de pedido de cliente chamada query_datascope à consulta. Valores possíveis: default, alle hotcache.
  • Utilize uma set instrução no texto da consulta: set query_datascope='...'. Os valores possíveis são os mesmos que para a propriedade do pedido de 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 a utilização das predefinições do cluster, que determinam que a consulta deve abranger todos os dados.

Se existir uma discrepância entre os diferentes métodos, set terá precedência sobre a propriedade do pedido de cliente. Especificar um valor para uma referência de tabela tem precedência sobre ambos.

Por exemplo, na seguinte consulta, todas as referências de tabela utilizam apenas dados de cache frequente, exceto a segunda referência a "T", que está no âmbito de todos os dados:

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

Política de colocação em cache vs política de retenção

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

  • A política de colocação em cache define como atribuir prioridades aos recursos. As consultas para dados importantes são mais rápidas.
  • A política de retenção define a extensão dos dados queryable numa tabela/base de dados (especificamente, SoftDeletePeriod).

Configure esta política para alcançar o equilíbrio ideal entre o custo e o 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. Pode executar consultas nos 56 dias completos de dados.

Conteúdo relacionado