O Looker reduz a carga no banco de dados e melhora a performance 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. Esta página descreve a política de armazenamento em cache padrão do Looker, além das 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 cache no Looker funciona da seguinte maneira:
Quando uma consulta SQL é executada em uma análise detalhada, um Look ou um painel, o Looker verifica o cache para saber se já há resultados armazenados em cache para essa consulta. Os resultados em cache serão usados apenas se todos os aspectos da consulta forem iguais, incluindo campos, filtros, parâmetros e limites de linhas.
Se forem encontrados resultados em cache, o Looker vai verificar a política de cache definida no modelo da LookML para determinar se os resultados em cache expiraram. Se os resultados armazenados em cache não tiverem expirado, o Looker os usará para a consulta.
Se nenhum resultado em cache for encontrado para a consulta ou se os resultados em cache tiverem expirado, o Looker vai 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. A próxima seção, Modificar políticas de retenção de cache, discute como encurtar ou aumentar esse período, além de descrever 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 da análise detalhada e do modelo do LookML.
O mecanismo de cache recomendado é usar um parâmetro datagroup no nível do modelo. Os grupos de dados permitem 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 Armazenar consultas em cache e recriar tabelas derivadas permanentes (PDTs) com datagroups.
Para uma abordagem mais simples, use o parâmetro persist_for no nível do modelo ou no nível do Explorador. Usar o parâmetro persist_for dessa forma 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, conforme discutido na seção Armazenar consultas em cache com persist_for.
Se uma análise detalhada ou um modelo tiver um grupo de dados ou persist_for definido, a política de cache será modificada da seguinte maneira:
- Antes do vencimento do intervalo
persist_foroumax_cache_agedo grupo de dados: se a consulta for executada novamente, o Looker vai extrair dados do cache. - No momento em que o intervalo
persist_foroumax_cache_agedo grupo de dados expira, o Looker exclui os dados do cache. - Depois que o intervalo
persist_foroumax_cache_agedo grupo de dados expira: se a consulta for executada novamente, o Looker vai extrair os dados diretamente do banco de dados e redefinir o intervalopersist_foroumax_cache_age.
Um ponto importante é 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 serão removidos com base em um algoritmo usado há menos tempo (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 os 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 armazenados em cache ainda podem ser armazenados por até 10 minutos. Todos os dados dos clientes armazenados no cache de disco são criptografados com o Padrão avançado de criptografia (AES).
Para minimizar o tempo de armazenamento dos dados no cache:
- Para qualquer parâmetro
persist_for(de um modelo ou uma análise detalhada) oumax_cache_age(de um grupo de dados), defina o valor como0 minutes. O Looker exclui o cache quando o intervalopersist_forexpira ou quando os dados atingem o intervalomax_cache_ageespecificado no grupo de dados. Não é necessário definir o parâmetropersist_fordas tabelas derivadas permanentes (PDTs) como0 minutespara minimizar a quantidade de dados armazenados no cache. As PDTs são gravadas no próprio banco de dados, não no cache. - Defina o parâmetro
suggest_persist_forcomo um intervalo pequeno. O valorsuggest_persist_forespecifica por quanto tempo o Looker deve 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 conforme o usuário digita no campo de texto do filtro. O padrão é armazenar em cache as sugestões de filtro por seis horas. Para minimizar o tempo que seus dados ficam no cache, defina o valorsuggest_persist_forcomo algo menor, como5 minutes.
Verificar se uma consulta foi retornada do cache
Em uma janela Analisar, é possível determinar se uma consulta foi retornada do cache verificando as informações ao lado do botão Executar depois de executar uma consulta.
Quando uma consulta é retornada do cache, o texto "do cache" é exibido. Caso contrário, o tempo necessário para retornar a consulta será exibido.
Forçar a geração de novos resultados do banco de dados
Em uma janela Análise, é possível forçar a recuperação de novos resultados do banco de dados. Depois de executar uma consulta (incluindo consultas de resultados combinados), selecione a opção Limpar cache e atualizar no menu de engrenagem Ações de análise detalhada.
Armazenamento de consultas em cache e recriação de tabelas derivadas persistentes (PDTs) com grupos de dados
Use grupos de dados para coordenar a programação de ETL (extração, transformação e carregamento) do seu banco de dados com a política de cache do Looker e a programação de reconstrução de tabelas derivadas permanentes (PDTs).
É possível usar um grupo de dados para especificar o gatilho de recriação de PDTs com base em quando novos dados são adicionados ao banco de dados. Em seguida, aplique o mesmo grupo de dados à análise detalhada ou ao modelo para que os resultados armazenados em cache também expirem quando as PDTs forem recriadas.
Como alternativa, use um grupo de dados para separar o gatilho de recriação do PDT da idade máxima do cache. Isso pode ser útil se você tiver uma Análise baseada em dados que são atualizados com muita frequência e associada a uma PDT que é recriada com menos frequência. Nesse caso, talvez você queira que o cache de consultas seja redefinido com mais frequência do que a recriação da PDT.
Definir um grupo de dados
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 você quiser políticas diferentes de reconstrução de cache e tabela derivada permanente (PDT) para diferentes análises detalhadas ou PDTs no seu projeto.
O parâmetro datagroup pode ter os seguintes subparâmetros:
label: especifica um rótulo opcional para o grupo de dados.description: especifica uma descrição opcional para o 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 a consulta for emitida, o Looker vai enviá-la ao banco de dados para receber resultados atualizados.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 vai entrar em um estado acionado.interval_trigger: especifica uma programação para acionar o grupo de dados, como"24 hours".
No mínimo, um grupo de dados precisa ter pelo menos o parâmetro max_cache_age, sql_trigger ou interval_trigger.
Confira um exemplo de grupo de dados com um sql_trigger configurado para recriar a PDT todos os dias. Além disso, o max_cache_age é definido para limpar o cache de consultas a cada duas horas, caso alguma análise detalhada junte PDTs a outros dados que são 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, é possível atribuí-lo a análises detalhadas e PDTs:
- Para atribuir o grupo de dados a uma PDT, use o parâmetro
datagroup_triggeremderived_table. Consulte a seção Usar um grupo de dados para especificar um gatilho de recriação para PDTs nesta página para ver um exemplo. - Para atribuir o grupo de dados a uma análise detalhada, use o parâmetro
persist_withno nível do modelo ou no nível da análise detalhada. Consulte a seção Usar um grupo de dados para especificar a redefinição do cache de consultas em análises detalhadas nesta página para ver um exemplo.
Usar um grupo de dados para especificar um gatilho de recriação para PDTs
Para definir um gatilho de recriação de PDT usando grupos de dados, crie um parâmetro datagroup com o subparâmetro sql_trigger ou interval_trigger. Em seguida, atribua o grupo de dados a PDTs individuais usando o subparâmetro datagroup_trigger na definição derived_table da PDT. Se você usar datagroup_trigger na PDT, não será necessário especificar outra estratégia de persistência para a tabela derivada. Se você especificar várias estratégias de persistência para uma PDT, vai receber um aviso no Looker IDE, e apenas a datagroup_trigger será usada.
Confira a seguir um exemplo de definição de PDT que usa o grupo de dados customers_datagroup. Essa definição também adiciona vários índices, tanto em customer_id quanto em first_order_date. Para mais informações sobre como definir PDTs, 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"]
}
}
Consulte a página de documentação Tabelas derivadas no Looker para mais informações sobre como os grupos de dados funcionam com as PDTs.
Como usar um grupo de dados para especificar a redefinição do cache de consultas em análises detalhadas
Quando um grupo de dados é acionado, o regenerador do Looker recria as PDTs que usam esse grupo de dados como uma estratégia de persistência. Depois que as PDTs do grupo de dados forem recriadas, o Looker vai limpar o cache das análises detalhadas que usam as PDTs recriadas do grupo de dados. Adicione o parâmetro max_cache_age à definição do grupo de dados se quiser personalizar uma programação de redefinição do cache de consultas para o grupo. O parâmetro max_cache_age permite limpar o cache de consultas em uma programação especificada, além da redefinição automática que o Looker realiza quando as PDTs do grupo de dados são reconstruídas.
Para definir uma política de cache de consultas com grupos de dados, crie um parâmetro datagroup com o subparâmetro max_cache_age.
Para especificar um grupo de dados a ser usado em redefinições de cache de consultas nas análises detalhadas, use o parâmetro persist_with:
- Para atribuir o grupo de dados como padrão para todas as análises detalhadas em um modelo, use o parâmetro
persist_withno nível do modelo (em um arquivo de modelo). - Para atribuir o grupo de dados a análises detalhadas individuais, use o parâmetro
persist_withem um parâmetroexplore.
Os exemplos a seguir mostram um grupo de dados chamado orders_datagroup definido em um arquivo de modelo. O grupo de dados tem um parâmetro sql_trigger, que especifica que a consulta select max(id) from my_tablename será usada para detectar quando uma ETL ocorreu. Mesmo que essa 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 um máximo de 24 horas.
O parâmetro persist_with do modelo aponta para a política de cache orders_datagroup, o que significa que essa será a política de cache padrão para todas as análises detalhadas no modelo. No entanto, não queremos usar a política de cache padrão do modelo para as análises detalhadas customer_facts e customer_background. Por isso, podemos adicionar o parâmetro persist_with para especificar uma política de cache diferente para essas duas análises. As análises detalhadas orders e orders_facts não têm um parâmetro persist_with. Portanto, elas usam a política de 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 persist_with será usado.
Como usar um grupo de dados para acionar entregas programadas
Os grupos de dados também podem ser usados para acionar a entrega de um painel ou de um Look. Com essa opção, o Looker envia seus dados quando o grupo de dados é concluído, para que o conteúdo programado esteja atualizado.
Como usar o painel Administrador para grupos de dados
Se você tiver a função de administrador do Looker, use a página Datagroups do painel Administrador para conferir os grupos de dados atuais. É possível conferir a conexão, o modelo e o status atual de cada grupo de dados e, se especificado na LookML, um rótulo e uma descrição para cada grupo. Também é possível redefinir o cache de um grupo de dados, acionar o grupo ou navegar até a LookML dele.
Armazenamento de consultas em cache com persist_for
Use o parâmetro persist_for no nível do modelo ou no nível de análise detalhada para modificar o intervalo padrão de retenção de cache do Looker de 1 hora. É possível definir intervalos de 0 minutes a 8760 hours (1 ano) ou mais.
Definir parâmetros persist_for pode ser mais rápido e simples, mas menos robusto do que definir grupos de dados. Os grupos de dados são recomendados em vez de persist_for pelos seguintes motivos:
- Os grupos de dados podem ser sincronizados com o processo de ETL do seu banco de dados.
- É possível reutilizar grupos de dados em vários modelos e análises detalhadas. Isso significa que você pode atualizar o
max_cache_agede um grupo de dados, e ele vai atualizar a política de cache em cada lugar em que o grupo de dados é usado. - É possível limpar todo o cache associado a um grupo de dados na página Grupos de dados.