Armazenamento em cache do conjunto de resultados (versão de pré-visualização)

Aplica-se a:✅ endpoint de análise SQL e armazém de dados no Microsoft Fabric

O armazenamento em cache do conjunto de resultados (prévia) é uma otimização de desempenho incorporada para endpoints de análise do Fabric Data Warehouse e Lakehouse SQL, melhorando a latência de leitura.

A cache de conjuntos de resultados funciona persistindo os conjuntos de resultados finais para consultas T-SQL aplicáveis SELECT, de modo que as execuções subsequentes que acertarem no cache processem somente o conjunto de resultados final. Isso pode ignorar a compilação complexa e o processamento de dados da consulta original e retornar consultas subsequentes mais rapidamente.

Os cenários de armazenamento de dados normalmente envolvem consultas analíticas que processam grandes quantidades de dados para produzir um resultado relativamente pequeno. Por exemplo, uma SELECT consulta que contém várias associações e executa leituras e embaralhamentos em milhões de linhas de dados pode resultar numa agregação com apenas algumas linhas. Para cargas de trabalho como relatórios ou painéis que tendem a acionar as mesmas consultas analíticas repetidamente, a mesma computação pesada pode ser acionada várias vezes, mesmo que o resultado final permaneça o mesmo. O cache do conjunto de resultados melhora o desempenho neste e em cenários semelhantes por aproximadamente o mesmo custo.

Gerenciamento automático de cache

O cache do conjunto de resultados funciona de forma transparente. Uma vez habilitado, a criação e a reutilização do cache são aplicadas oportunisticamente para consultas.

O cache dos conjuntos de resultados aplica-se a SELECT consultas T-SQL em tabelas de armazém, atalhos para fontes OneLake e atalhos para fontes que não são do Azure. O gerenciamento de cache é tratado automaticamente, removendo regularmente o cache conforme necessário.

Além disso, à medida que os dados mudam, a consistência dos resultados é garantida invalidando o cache criado anteriormente.

Configurar o armazenamento em cache de conjuntos de resultados

O cache do conjunto de resultados é configurável no nível do item.

Uma vez ativado, ele pode ser desativado no nível do item ou para consultas individuais, se necessário.

Durante a visualização, o cache do conjunto de resultados está desativado por padrão para todos os itens.

Configuração no nível do item

Use o comando T-SQL ALTER DATABASE SET para habilitar o armazenamento em cache do conjunto de resultados para um lakehouse ou armazém de dados. Utilize o ponto de extremidade de análise SQL de um Lakehouse para ligar e executar consultas T-SQL.

ALTER DATABASE <Fabric_item_name>
SET RESULT_SET_CACHING ON;

O valor da configuração pode ser verificado em sys.databases, por exemplo, para ver o valor do contexto atual no Fabric Warehouse ou no ponto de extremidade de análise SQL no Lakehouse:

SELECT name, is_result_set_caching_on 
FROM sys.databases
WHERE database_id = db_id();

Para desativar o cache do conjunto de resultados:

ALTER DATABASE <Fabric_item_name>
SET RESULT_SET_CACHING OFF;

Configuração no nível de consulta

Quando o cache do conjunto de resultados é habilitado em um item, ele pode ser desabilitado para uma consulta individual.

Isso pode ser útil para depuração ou teste A/B de uma consulta. Desative o cache do conjunto de resultados para uma consulta anexando esta dica no final do SELECT:

OPTION ( USE HINT ('DISABLE_RESULT_SET_CACHE') );

Verificar o uso do cache do conjunto de resultados

O uso do cache do conjunto de resultados pode ser verificado em dois locais: Saída de mensagem e a visualização queryinsights.exec_requests_history do sistema.

Na saída da mensagem de uma consulta (visível no editor de Consultas de Malha ou no SQL Server Management Studio), a instrução "O cache do conjunto de resultados foi usado" será exibida após a execução da consulta se a consulta puder usar um cache de conjunto de resultados existente.

No queryinsights.exec_requests_history, a coluna result_cache_hit exibe um valor que indica o uso do cache do conjunto de resultados para cada execução de consulta:

• 2: a consulta usou o cache do conjunto de resultados (acerto de cache)
• 1: a consulta criou o cache do conjunto de resultados
• 0: a consulta não era aplicável para a criação ou uso do cache do conjunto de resultados

Por exemplo:

SELECT result_cache_hit, command, *
FROM queryinsights.exec_requests_history
ORDER BY submit_time DESC;

Qualificar o cache do conjunto de resultados

Quando uma SELECT consulta é emitida, ela é avaliada quanto ao cache do conjunto de resultados. Vários requisitos devem ser atendidos para ser elegível para criar e usar o cache do conjunto de resultados. Alguns deles ajudam a manter o armazenamento em cachê dentro de limites internos, alguns ajudam a reservar o cachê para consultas complexas, enquanto outros ajudam a manter a correção dos resultados após acessos repetitivos. Um exemplo óbvio é restringir SELECT as consultas de GETDATE() de terem os seus resultados em cache, mas existem outros casos mais subtis também em que o Fabric opta por não armazenar os resultados em cache.

A lista a seguir contém desqualificações comuns para o cache do conjunto de resultados no Fabric Data Warehouse. Se você achar que uma consulta não era aplicável para criar o cache do conjunto de resultados, isso pode ser devido a um ou mais destes motivos:

• A cache do conjunto de resultados não está ativada no item conectado atualmente, ou está ativada no item, mas a consulta incluiu o sinalizador DISABLE_RESULT_SET_CACHE.
• A consulta não é pura SELECT, por exemplo, (CTAS), CREATE TABLE AS SELECTSELECT-INTO, outra linguagem de modificação de dados
• A consulta faz referência a um objeto do sistema, uma tabela temporária, uma função de metadados ou não faz referência a nenhum objeto distribuído
• A consulta não faz referência a pelo menos uma tabela de pelo menos 100.000 linhas
• A consulta faz referência a um objeto fora do item Fabric atualmente conectado (por exemplo, consulta entre bases de dados)
• A consulta está dentro de uma transação explícita ou de um WHILE loop
• A saída da consulta contém tipos de dados não suportados e/ou o tipo de dados VARCHAR(MAX) e/ou o tipo de dados VARBINARY(MAX). Para tipos de dados suportados, consulte Tipos de dados no Fabric Data Warehouse
• A consulta contém um CAST ou CONVERT que tem alguma referência a data ou sql_variant tipo de dados
• A consulta contém constantes de tempo de execução (como CURRENT_USER ou GETDATE())
• O resultado da consulta é estimado em > 10.000 linhas
• A consulta contém funções internas não determinísticas, funções de agregação de janelas ou funções ordenadas como PARTITION BY … ORDER BY. Ver Funções determinísticas e não determinísticas.
• A consulta usa mascaramento dinâmico de dados, segurança em nível de linha ou outros recursos de segurança
• A consulta usa viagens no tempo
• A consulta aplica ORDER BY em uma coluna ou expressão que não está incluída na saída da consulta
• A consulta está numa sessão que tem instruções de SET ao nível da sessão com valores não padrão (por exemplo, definindo QUOTED_IDENTIFIER como OFF)
• O sistema atingiu limites internos para cache. Os processos de remoção de cache em segundo plano liberarão espaço antes que o novo cache seja criado.

Essas regras também se aplicam à reutilização de cache em execuções subsequentes da mesma consulta. Além disso, um cache pode não ser usado nos seguintes cenários:

• Qualquer alteração nas tabelas referenciadas desde que o cache foi criado
• O espaço de trabalho ficou offline desde a criação de um cache, semelhante ao cache na memória e no disco
• O usuário não tem permissões suficientes para os objetos na consulta
• A consulta está sendo chamada de uma conexão de lago ou armazém diferente de onde a consulta original foi emitida. (As consultas entre bases de dados não são elegíveis para cache de resultados.)
• A consulta usa colunas de saída, ordenação de colunas ou aliases diferentes da consulta original
• A consulta em cache não foi usada em 24 horas

Conteúdo relacionado

• Cache na memória e em disco
• Diretrizes de desempenho no Fabric Data Warehouse