Como armazenar consultas em cache

O Looker reduz a carga no seu banco de dados e melhora o desempenho usando resultados armazenados em cache de consultas SQL anteriores quando eles estão disponíveis e quando essa função é permitida pela política de armazenamento em cache. Nesta página, descrevemos a política de armazenamento em cache padrão do Looker e as opções disponíveis para modificar a duração dos resultados armazenados em cache na sua instância do Looker.

Como o Looker usa consultas em cache

Para consultas SQL, o mecanismo de armazenamento em cache no Looker funciona da seguinte maneira:

  1. Quando uma consulta SQL é executada em uma Análise, um Look ou um dashboard, o Looker verifica se já há resultados armazenados em cache para essa consulta. Os resultados armazenados em cache serão usados somente se todos os aspectos da consulta forem iguais, incluindo campos, filtros, parâmetros e limites de linhas.

  2. Se forem encontrados resultados armazenados em cache, o Looker verificará a política de armazenamento em cache definida no modelo LookML para determinar se os resultados armazenados expiraram. Se os resultados armazenados em cache não expirarem, o Looker vai usá-los para a consulta.

  3. Se nenhum resultado armazenado em cache for encontrado para a consulta ou se os resultados armazenados expirarem, o Looker executará a consulta no banco de dados. Os novos resultados da consulta serão armazenados em cache.

A política de retenção de cache padrão é de uma hora. Na próxima seção, Como modificar políticas de retenção de cache, você verá como reduzir ou aumentar esse período e descrever as opções para sincronizar sua política de retenção de cache com o processo de ETL (extração, transformação e carregamento) do banco de dados.

Como modificar políticas de retenção de cache

É possível especificar políticas de retenção de cache no nível do LookML Explore e do modelo do LookML.

O mecanismo de armazenamento em cache recomendado é usar um parâmetro datagroup no nível do modelo. Com os grupos de dados, é possível sincronizar a política de retenção de cache de um modelo com a programação de ETL do banco de dados usando o parâmetro sql_trigger e definindo um intervalo de expiração do cache com o parâmetro max_cache_age. Para mais informações, consulte a seção Como armazenar consultas em cache e recriar TDPs com grupos de dados.

Para uma abordagem mais simples, use o parâmetro persist_for no nível do modelo ou no nível da Análise. Usar o parâmetro persist_for dessa maneira permite definir um intervalo de expiração do cache que substitui o intervalo padrão de uma hora. No entanto, usar persist_for é menos robusto do que usar grupos de dados por alguns motivos, como discutido na seção Como armazenar consultas em cache com persist_for.

Se uma Análise ou um modelo tiver um datagroup ou persist_for definido, a política de armazenamento em cache vai ser modificada da seguinte maneira:

  • Antes do intervalo persist_for ou max_cache_age do grupo de dados expirar: se a consulta for executada novamente, o Looker vai extrair dados do cache.
  • No momento em que o intervalo persist_for ou o intervalo max_cache_age do grupo de dados expira: o Looker exclui os dados do cache.
  • Após o intervalo persist_for ou o intervalo max_cache_age do grupo de dados expirar: se a consulta for executada novamente, o Looker extrairá os dados do banco de dados diretamente e redefinirá o intervalo persist_for ou max_cache_age.

Um ponto importante aqui é que os dados são excluídos do cache quando o intervalo persist_for ou max_cache_age expira.

Se o cache atingir o limite de armazenamento, os dados vão ser expulsos com base em um algoritmo de menos uso recente (LRU, na sigla em inglês), sem garantia de que os dados com intervalos persist_for ou max_cache_age expirados serão excluídos de uma só vez.

Minimizar o tempo que seus dados passam no cache

O Looker sempre grava os resultados da consulta no cache. Mesmo que os intervalos persist_for e max_cache_age sejam definidos como zero, os dados em cache ainda poderão ser armazenados por até 10 minutos. Todos os dados do cliente armazenados no cache de disco são criptografados com Padrão de Criptografia Avançado (AES).

Para minimizar o tempo de armazenamento de dados no cache:

  • Para qualquer parâmetro persist_for (para um modelo ou uma Análise) ou max_cache_age (para um grupo de dados), defina o valor como 0 minutes. O Looker exclui o cache quando o intervalo persist_for expira ou quando os dados atingem o intervalo max_cache_age especificado no grupo de dados. Não é necessário definir o parâmetro persist_for das TDPs como 0 minutes para minimizar a quantidade de dados armazenados no cache. TDPs são gravadas no próprio banco de dados, e não no cache.)
  • Defina o parâmetro suggest_persist_for com um intervalo pequeno. O valor suggest_persist_for especifica por quanto tempo o Looker precisa manter as sugestões de filtro no cache. As sugestões de filtro são baseadas em uma consulta dos valores do campo que está sendo filtrado. Esses resultados de consulta são mantidos no cache para que o Looker possa fornecer sugestões rapidamente enquanto o usuário digita no campo de texto do filtro. O padrão é armazenar as sugestões de filtro em cache por seis horas. Para minimizar o tempo que seus dados permanecem no cache, defina o valor suggest_persist_for como um valor menor, como 5 minutes.

Como verificar se uma consulta foi retornada do cache

Em uma janela Explore, analise o canto superior direito depois de executar uma consulta para determinar se ela foi retornada do cache.

Quando uma consulta é retornada do cache, a mensagem "from cache" é exibida. Caso contrário, o tempo necessário para retornar a consulta será exibido.

Como forçar a geração de novos resultados a partir do banco de dados

Em uma janela Explore, é possível forçar a recuperação de novos resultados do banco de dados. Depois de executar uma consulta (incluindo consultas de resultados mesclados), selecione a opção Limpar o cache e atualizar no menu de engrenagem Explore Actions, localizado no canto superior direito da tela.

Como armazenar consultas em cache e recriar TDPs com grupos de dados

Use grupos de dados para coordenar a programação de ETL (extração, transformação e carregamento) do banco de dados com a política de armazenamento em cache do Looker e a programação de recriação de TDPs.

É possível usar um datagroup para especificar o acionador de recriação para TDPs com base na data em que novos dados são adicionados ao seu banco de dados. Em seguida, é possível aplicar o mesmo grupo de dados à Análise ou ao modelo para que os resultados armazenados em cache também expirem quando as TDPs forem recriadas.

Como alternativa, é possível usar um grupo de dados para desacoplar o acionador de recriação de TDP da sua idade máxima do cache. Isso pode ser útil se você tiver uma Análise baseada em dados atualizados com muita frequência e associada a uma TDP que é recriada com menos frequência. Nesse caso, talvez você queira que o cache da consulta seja redefinido com mais frequência do que a TDP é recriada.

Como definir um datagroup

Defina um grupo de dados com o parâmetro datagroup em um arquivo de modelo ou em um arquivo LookML próprio. É possível definir vários grupos de dados se quiser diferentes políticas de armazenamento em cache e recriação de TDPs para diferentes Explores e/ou TDPs no seu projeto.

O parâmetro datagroup pode ter os seguintes subparâmetros:

  • label: especifica um identificador opcional para o grupo de dados.
  • description: especifica uma descrição opcional do grupo de dados, que pode ser usada para explicar a finalidade e o mecanismo dele.
  • max_cache_age: especifica uma string que define um período. Quando a idade do cache de uma consulta excede o período, o Looker invalida o cache. Na próxima vez que uma consulta é emitida, o Looker a envia ao banco de dados para receber resultados novos.
  • sql_trigger: especifica uma consulta SQL que retorna uma linha com uma coluna. Se o valor retornado pela consulta for diferente dos resultados anteriores, o grupo de dados entrará em um estado acionado.
  • interval_trigger: especifica uma programação de horário para acionar o grupo de dados, como "24 hours".

Consulte a página de documentação do datagroup para mais informações sobre esses parâmetros.

No mínimo, um grupo de dados precisa ter pelo menos o parâmetro max_cache_age, sql_trigger ou interval_trigger.

Veja um exemplo de um grupo de dados com uma sql_trigger configurada para recriar a TDP todos os dias. Além disso, a max_cache_age está configurada para limpar o cache de consultas a cada duas horas, caso alguma Análise junte TDPs a outros dados atualizados com mais frequência do que uma vez por dia.

datagroup: customers_datagroup {
  sql_trigger: SELECT DATE(NOW());;
  max_cache_age: "2 hours"
}

Depois de definir o grupo de dados, ele pode ser atribuído às Análises e TDPs:

Como usar um grupo de dados para especificar um gatilho de recriação para TDPs

Para definir um acionador de recriação de TDPs usando datagroups, crie um parâmetro datagroup com o subparâmetro sql_trigger ou interval_trigger. Em seguida, atribua o grupo de dados a TDPs individuais usando o subparâmetro datagroup_trigger na definição derived_table da TDP. Se você usar datagroup_trigger para sua TDP, não será necessário especificar nenhuma outra estratégia de persistência para a tabela derivada. Se você especificar várias estratégias de persistência para uma TDP, vai receber um aviso no ambiente de desenvolvimento integrado do Looker, e apenas a datagroup_trigger será usada.

Veja um exemplo de definição de TDP que usa o grupo de dados customers_datagroup. Essa definição também adiciona vários índices em customer_id e first_order_date. Para mais informações sobre como definir TDPs, consulte a página de documentação Tabelas derivadas no Looker.

view: customer_order_facts {
  derived_table: {
    sql: ... ;;
    datagroup_trigger: customers_datagroup
    indexes: ["customer_id", "first_order_date"]
  }
}

Se você tiver TDPs em cascata e TDPs que dependem de outras TDPs, tenha cuidado para não especificar políticas incompatíveis de armazenamento em cache de grupos de dados.

Para conexões com atributos de usuário para especificar os parâmetros de conexão, crie uma conexão separada usando os campos de substituição de TDP se quiser:

  • Usar TDPs no seu modelo
  • Usar um datagroup para definir um gatilho de recriação de TDP

Sem as substituições de TDP, ainda é possível usar um datagroup com max_cache_age para definir a política de armazenamento em cache para as Análises detalhadas.

Consulte a página de documentação Tabelas derivadas no Looker para mais informações sobre como os grupos de dados funcionam com TDPs.

Como usar um datagroup para especificar a redefinição do cache de consulta para "Explores"

Quando um grupo de dados é acionado, o regenerador do Looker recria as TDPs que usam esse grupo de dados como uma estratégia de persistência. Depois que as TDPs do grupo de dados forem recriadas, o Looker vai limpar o cache das Análises que usam as TDPs recriadas do grupo de dados. Adicione o parâmetro max_cache_age à definição do grupo de dados para personalizar a programação de redefinição do cache de consulta do grupo de dados. O parâmetro max_cache_age permite limpar o cache de consultas em uma programação especificada, além da redefinição automática do cache de consulta que o Looker realiza quando as TDPs do grupo de dados são recriadas.

Para definir uma política de armazenamento em cache de consultas com datagroups, crie um parâmetro datagroup com o subparâmetro max_cache_age.

Para especificar um grupo de dados a ser usado para redefinições de cache de consulta em "Explores", use o parâmetro persist_with:

Os exemplos a seguir mostram um grupo de dados chamado orders_datagroup, que é definido em um arquivo de modelo. O datagroup tem um parâmetro sql_trigger, que especifica que a consulta select max(id) from my_tablename vai ser usada para detectar quando um ETL acontecer. Mesmo que esse ETL não aconteça por um tempo, o max_cache_age do grupo de dados especifica que os dados armazenados em cache serão usados por, no máximo, 24 horas.

O parâmetro persist_with do modelo aponta para a política de armazenamento em cache orders_datagroup, o que significa que essa será a política de armazenamento em cache padrão para todas as Análises no modelo. No entanto, não queremos usar a política de armazenamento em cache padrão do modelo para as Análises customer_facts e customer_background, então podemos adicionar o parâmetro persist_with para especificar uma política de armazenamento em cache diferente para elas. As Análises orders e orders_facts não têm um parâmetro persist_with, portanto, usam a política de armazenamento em cache padrão do modelo: orders_datagroup.

datagroup: orders_datagroup {
  sql_trigger: SELECT max(id) FROM my_tablename ;;
  max_cache_age: "24 hours"
}

datagroup: customers_datagroup {
  sql_trigger: SELECT max(id) FROM my_other_tablename ;;
}

persist_with: orders_datagroup

explore: orders { ... }

explore: order_facts { ... }

explore: customer_facts {
  persist_with: customers_datagroup
  ...
}

explore: customer_background {
  persist_with: customers_datagroup
  ...
}

Se persist_with e persist_for forem especificados, você vai receber um aviso de validação, e o persist_with vai ser usado.

Como usar um grupo de dados para acionar entregas programadas

Os datagroups também podem ser usados para acionar o envio de um painel ou de um Look. Com essa opção, o Looker envia seus dados quando o grupo é concluído para que o conteúdo programado fique atualizado.

Como usar o painel Administrador em grupos de dados

Se você tiver o papel de administrador do Looker, acesse a página Grupos de dados do painel Administrador para ver os grupos de dados atuais. É possível ver a conexão, o modelo e o status atual de cada grupo de dados e, se especificado no LookML, um rótulo e uma descrição para cada um. Também é possível redefinir o cache de um datagroup, acionar o grupo de dados ou navegar até o LookML dele.

Como armazenar consultas em cache com persist_for

Use o parâmetro persist_for no nível do modelo ou no nível do Explore para modificar o intervalo de retenção de cache padrão do Looker de uma hora. Você pode definir intervalos de até 0 minutes e de até 8760 hours (1 ano) ou maiores.

Definir parâmetros persist_for pode ser mais rápido e simples, mas menos robusto, do que definir grupos de dados. Os datagroups são recomendados em vez do persist_for pelos seguintes motivos:

  • Os datagroups podem ser sincronizados com o processo de ETL do seu banco de dados.
  • É possível reutilizar os grupos de dados em vários modelos e Análises. Isso significa que é possível atualizar o max_cache_age de um datagroup. A política de armazenamento em cache é atualizada em cada local em que o datagroup é usado.
  • É possível limpar todo o cache associado a um grupo de dados na página Grupos de dados.