Política de colocação em cache (cache frequente e fria)
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 creationTime
ingestã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
,all
ehotcache
. - 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ãoall
ehotcache
.
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
= 56dhot 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
Comentários
https://aka.ms/ContentUserFeedback.
Brevemente: Ao longo de 2024, vamos descontinuar progressivamente o GitHub Issues como mecanismo de feedback para conteúdos e substituí-lo por um novo sistema de feedback. Para obter mais informações, veja:Submeter e ver comentários