Uso de resultados de consultas persistentes

Quando uma consulta é executada, o resultado persiste (ou seja, é armazenado em cache) por um período. Ao fim do período, o resultado é purgado do sistema.

O Snowflake usa resultados de consulta persistentes para evitar repetir a geração de resultados quando nada mudou (ou seja, “otimização da recuperação”). Além disso, você pode usar os resultados de consulta persistentes para pós-processar os resultados (por exemplo, colocando uma nova consulta sobre os resultados já calculados).

Para resultados de consulta persistentes de todos os tamanhos, o cache expira após 24 horas.

Note que o token de segurança usado para acessar grandes resultados de consulta persistentes (ou seja, maiores que 100 KB em tamanho) expira após 6 horas. Um novo token pode ser recuperado para acessar os resultados enquanto eles ainda estão em cache. Resultados de consultas menores persistem e não utilizam um token de acesso.

Nota

O token fornecido ao Conector Snowflake para Spark (“conector Spark”) expira após 24 horas, independentemente do tamanho do resultado de consulta persistente. O conector Spark aproveita o maior tempo de expiração do cache para evitar o tempo limite em alguns casos de uso.

Consulte também Como otimizar o cache do warehouse, que discute como os dados da tabela podem ser armazenados em cache e reutilizados por um warehouse ativo.

Neste tópico:

Otimização da recuperação

Se um usuário repete uma consulta que já foi executada, e os dados na(s) tabela(s) não mudaram desde a última vez que a consulta foi executada, então o resultado da consulta é o mesmo. Em vez de executar a consulta novamente, Snowflake simplesmente retorna o mesmo resultado que retornou anteriormente. Isto pode reduzir substancialmente o tempo de consulta, pois o Snowflake ignora a execução da consulta e, em vez disso, recupera o resultado diretamente do cache.

Normalmente, os resultados das consultas são reutilizados se todas as seguintes condições forem atendidas:

  • A nova consulta corresponde exatamente à consulta executada anteriormente. Qualquer diferença na sintaxe, incluindo letras minúsculas versus maiúsculas, ou o uso de aliases de tabela, inibirá 100% a reutilização do cache. Por exemplo, considere as seguintes consultas, executadas em sucessão:

    SELECT DISTINCT(severity) FROM weather_events;
    SELECT DISTINCT(severity) FROM weather_events;
    SELECT DISTINCT(severity) FROM weather_events we;
    select distinct(severity) from weather_events;
    
    Copy

    A primeira consulta preencherá o cache, e a segunda consulta idêntica se beneficiará da reutilização de 100% do cache. No entanto, a terceira e a quarta consultas não acionarão a reutilização do cache, simplesmente porque a terceira consulta introduz um alias de tabela e a quarta consulta usa palavras-chave em letras minúsculas.

  • A consulta não inclui funções não reutilizáveis, que retornam resultados diferentes para execuções sucessivas da mesma consulta. UUID_STRING, RANDOM e RANDSTR são bons exemplos de funções não reutilizáveis.

  • A consulta não inclui funções externas.

  • Os dados da tabela que contribuem para o resultado da consulta não foram alterados.

  • O resultado persistente para a consulta anterior ainda está disponível.

  • A função que acessa os resultados em cache tem os privilégios necessários.

    • Se a consulta foi uma consulta SELECT, a função que executa a consulta deve ter os privilégios de acesso necessários para todas as tabelas utilizadas na consulta em cache.

    • Se a consulta foi uma consulta SHOW, a função que executou a consulta deve corresponder à função que gerou os resultados em cache.

  • As opções de configuração que afetam a forma como o resultado foi produzido não mudaram.

  • As micropartições da tabela não foram alteradas (por exemplo, foram reagrupadas ou consolidadas) devido a mudanças em outros dados da tabela.

Nota

O cumprimento de todas estas condições não garante que o Snowflake reutilize os resultados da consulta.

Por padrão, a reutilização dos resultados é ativada, mas pode ser substituída em nível de conta, usuário e sessão usando o parâmetro de sessão USE_CACHED_RESULT.

Nota

Cada vez que o resultado persistente de uma consulta é reutilizado, o Snowflake restabelece o período de retenção de 24 horas para o resultado, até um máximo de 31 dias a partir da data e hora em que a consulta foi executada pela primeira vez. Após 31 dias, o resultado é limpo e na próxima vez que a consulta é submetida, um novo resultado é gerado e persiste.

Pós-processamento dos resultados de consultas

Em alguns casos, você pode querer realizar um processamento adicional sobre o resultado de uma consulta que já tenha sido feita. Por exemplo:

  • Você está desenvolvendo uma consulta complexa passo a passo e deseja adicionar uma nova camada sobre a consulta anterior e executar a nova consulta sem recalcular os resultados parciais a partir do zero.

  • A consulta anterior era uma instrução SHOW <objetos>, DESCRIBE <objeto> ou CALL, que retorna resultados em uma forma que não é fácil de reutilizar.

    Por exemplo, você não pode chamar um procedimento armazenado dentro de uma instrução SQL mais complexa da maneira como você pode chamar uma função dentro de uma instrução SQL, então a única maneira de processar a saída do procedimento armazenado é pós-processar os resultados da consulta armazenada.

O pós-processamento pode ser realizado utilizando a função de tabela RESULT_SCAN. A função retorna os resultados da consulta anterior como uma “tabela” e uma nova consulta pode então ser executada sobre os dados tabulares.

Exemplos

Processe o resultado de um comando SHOW TABLES e extraia as seguintes colunas e linhas do resultado:

  • Colunas schema_name, table_name e rows.

  • Linhas para tabelas que estão vazias.

SHOW TABLES;

+-----+-------------------------------+-------------+-------+-------+------+
| Row |           created_on          | name        | ...   | ...   | rows |
+-----+-------------------------------+-------------+-------+-------+------+
|  1  | 2018-07-02 09:43:49.971 -0700 | employees   | ...   | ...   | 2405 |
+-----+-------------------------------+-------------+-------+-------+------+
|  2  | 2018-07-02 09:43:52.483 -0700 | dependents  | ...   | ...   | 5280 |
+-----+-------------------------------+-------------+-------+-------+------+
|  3  | 2018-07-03 11:43:52.483 -0700 | injuries    | ...   | ...   |    0 |
+-----+-------------------------------+-------------+-------+-------+------+
|  4  | 2018-07-03 11:43:52.483 -0700 | claims      | ...   | ...   |    0 |
+-----+-------------------------------+-------------+-------+-------+------+
| ...                                                                      |
| ...                                                                      |
+-----+-------------------------------+-------------+-------+-------+------+

-- Show the tables that are empty.
SELECT  "schema_name", "name" as "table_name", "rows"
    FROM table(RESULT_SCAN(LAST_QUERY_ID()))
    WHERE "rows" = 0;

+-----+-------------+-------------+------+
| Row | schema_name | name        | rows |
+-----+-------------+-------------+------+
|  1  |  PUBLIC     | injuries    |    0 |
+-----+-------------+-------------+------+
|  2  |  PUBLIC     | claims      |    0 |
+-----+-------------+-------------+------+
| ...                                    |
| ...                                    |
+-----+-------------+-------------+------+
Copy

Exemplos adicionais são fornecidos em RESULT_SCAN.