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 instância do Looker.
Como o Looker usa consultas armazenadas em cache
Para consultas SQL, o mecanismo de armazenamento em cache no Looker funciona da seguinte maneira:
Quando uma consulta SQL é executada em uma Análise, um Look ou um dashboard, o Looker verifica o cache para conferir se já há resultados armazenados em cache para essa consulta. Os resultados armazenados em cache serão usados apenas se todos os aspectos da consulta forem iguais, incluindo campos, filtros, parâmetros e limites de linhas.
Se os resultados armazenados em cache forem encontrados, o Looker vai verificar a política de armazenamento em cache definida no modelo do LookML para determinar se os resultados armazenados em cache expiraram. Se os resultados armazenados em cache não tiverem expirado, o Looker vai usar os resultados armazenados em cache para a consulta.
Se nenhum resultado armazenado em cache for encontrado para a consulta ou se os resultados armazenados 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, Modificação de políticas de retenção de cache, discute como encurtar ou aumentar esse período, além de descrever opções para sincronizar a política de retenção de cache com o processo de ETL (extração, transformação e carregamento) do banco de dados.
Modificação de políticas de retenção de cache
É possível especificar políticas de retenção de cache no nível da Análise do LookML e no nível do modelo do LookML.
O mecanismo de armazenamento em cache recomendado é usar um datagroup parâmetro no nível do modelo. Os datagroups 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 de cache com o parâmetro max_cache_age. Para mais informações, consulte a seção Armazenamento de consultas em cache e recriação de tabelas derivadas persistentes (PDTs) com datagroups.
Para uma abordagem mais simples, use o persist_for parâmetro no nível do modelo ou no nível da Análise. O uso do parâmetro persist_for dessa forma permite definir um intervalo de expiração de cache que substitui o intervalo padrão de uma hora. No entanto, o uso de persist_for é menos robusto do que o uso de datagroups por alguns motivos, conforme discutido na seção Armazenamento de consultas em cache com persist_for.
Se uma Análise ou modelo tiver um datagroup ou persist_for definido, a política de armazenamento em cache será modificada da seguinte maneira:
- Antes do intervalo
persist_forou do intervalomax_cache_agedo datagroup expirar: se a consulta for executada novamente, o Looker vai extrair dados do cache. - No momento em que o intervalo
persist_forou o intervalomax_cache_agedo datagroup expira: o Looker exclui dados do cache. - Depois do intervalo
persist_forou do intervalomax_cache_agedo datagroup expirar: 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 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 serão removidos com base em um algoritmo usado menos recentemente (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.
Como 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 poderão ser armazenados por até 10 minutos. Todos os dados do cliente armazenados no cache em disco são criptografados pelo padrão de criptografia avançada (AES, na sigla em inglês).
Para minimizar o tempo que os dados são armazenados no cache:
- Para qualquer parâmetro
persist_for(para um modelo ou uma Análise) oumax_cache_age(para um datagroup), defina o valor como0 minutes. O Looker exclui o cache quando o intervalopersist_forexpira ou quando os dados atingem o intervalomax_cache_ageespecificado no datagroup. Não é necessário definir o parâmetropersist_forde tabelas derivadas persistentes (PDTs) como0 minutespara minimizar a quantidade de dados armazenados no cache. As PDTs são gravadas no próprio banco de dados e não no cache. - Defina o
suggest_persist_forparâmetro como 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 à medida que o usuário digita no campo de texto do filtro. O padrão é armazenar em cache as sugestões de filtro por 6 horas. Para minimizar o tempo que os dados ficam no cache, defina o valorsuggest_persist_forcomo algo menor, como5 minutes.
Como verificar se uma consulta foi retornada do cache
Em uma janela de Análise, é possível determinar se uma consulta foi retornada do cache observando 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.
Como forçar a geração de novos resultados do banco de dados
Em uma janela de Análise, é possível forçar a recuperação de novos resultados do banco de dados. Depois de executar uma consulta (incluindo resultados mesclados consultas), selecione a opção Limpar cache e atualizar no menu de engrenagem Ações de análise.
Armazenamento de consultas em cache e recriação de tabelas derivadas persistentes (PDTs) com datagroups
Use datagroups 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 tabelas derivadas persistentes (PDTs).
É possível usar um datagroup para especificar o gatilho de recriação para PDTs com base em quando novos dados são adicionados ao banco de dados. Em seguida, aplique o mesmo datagroup à Análise ou ao modelo para que os resultados armazenados em cache também expirem quando as PDTs forem recriadas.
Como alternativa, é possível usar um datagroup para desvincular o gatilho de recriação de PDT do tempo máximo de cache. Isso pode ser útil se você tiver uma Análise baseada em dados que são atualizados com muita frequência e unidos 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 TDP é recriada.
Definição de um datagroup
Defina um datagroup com o parâmetro datagroup, em um arquivo de modelo ou no próprio arquivo do LookML. É possível definir vários datagroups se você quiser políticas diferentes de armazenamento em cache e recriação de tabelas derivadas persistentes (PDTs) para diferentes Análises ou PDTs no projeto.
O parâmetro datagroup pode ter os seguintes subparâmetros:
label: especifica um rótulo opcional para o datagroup.description: especifica uma descrição opcional para o datagroup que pode ser usada para explicar a finalidade e o mecanismo do datagroup.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 enviar a consulta para o banco de dados para obter 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 da consulta, o datagroup vai para um estado acionado.interval_trigger: especifica uma programação de tempo para acionar o datagroup, como"24 hours".
No mínimo, um datagroup precisa ter pelo menos o parâmetro max_cache_age, o parâmetro sql_trigger ou o parâmetro interval_trigger.
Confira um exemplo de um datagroup que tem um sql_trigger configurado para recriar a PDT todos os dias. Além disso, o max_cache_age está definido para limpar o cache de consultas a cada duas horas, caso alguma Análise una PDTs a outros dados que sejam 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 datagroup, é possível atribuí-lo a Análises e PDTs:
- Para atribuir o datagroup a uma PDT, use o
datagroup_triggerparâmetro noderived_tableparâmetro. Consulte a seção Como usar um datagroup para especificar um gatilho de recriação para PDTs nesta página para ver um exemplo. - Para atribuir o datagroup a uma Análise, use o
persist_withparâmetro no nível do modelo ou no nível da Análise. Consulte a seção Como usar um datagroup para especificar a redefinição do cache de consultas para Análises nesta página para ver um exemplo.
Como usar um datagroup para especificar um gatilho de recriação para PDTs
Para definir um gatilho de recriação de PDT usando datagroups, crie um datagroup parâmetro com o sql_trigger ou o interval_trigger subparâmetro. Em seguida, atribua o datagroup a PDTs individuais usando o datagroup_trigger subparâmetro na definição derived_table da PDT. Se você usar datagroup_trigger para a 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, um aviso será exibido no ambiente de desenvolvimento integrado do Looker, e apenas o datagroup_trigger será usado.
A seguir, confira um exemplo de uma definição de PDT que usa o datagroup 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 datagroups funcionam com PDTs.
Como usar um datagroup para especificar a redefinição do cache de consultas para Análises
Quando um datagroup é acionado, o regenerador do Looker recria as PDTs que usam esse datagroup como uma estratégia de persistência. Depois que as PDTs do datagroup são recriadas, o Looker limpa o cache para Análises que usam as PDTs recriadas do datagroup. É possível adicionar o max_cache_age parâmetro à definição do datagroup se você quiser personalizar uma programação de redefinição do cache de consultas para o datagroup. 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 consultas que o Looker realiza quando as PDTs do datagroup são recriadas.
Para definir uma política de armazenamento em cache de consultas com datagroups, crie um datagroup parâmetro com o max_cache_age subparâmetro.
Para especificar um datagroup a ser usado para redefinições de cache de consultas em Análises, use o persist_with parâmetro:
- Para atribuir o datagroup como padrão para todas as Análises em um modelo, use o
persist_withparâmetro no nível do modelo (em um arquivo modelo). - Para atribuir o datagroup a Análises individuais, use o
persist_withparâmetro em umexploreparâmetro.
Os exemplos a seguir mostram um datagroup chamado orders_datagroup definido em um arquivo modelo. O datagroup tem um parâmetro sql_trigger, que especifica que a consulta select max(id) from my_tablename será usada para detectar quando um ETL ocorreu. Mesmo que esse ETL não aconteça por um tempo, o max_cache_age do datagroup especifica que os dados armazenados em cache serão usados apenas por um máximo de 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. Por isso, podemos adicionar o parâmetro persist_with para especificar uma política de armazenamento em cache diferente para essas duas Análises. As Análises orders e orders_facts não têm um parâmetro persist_with, então elas vão usar 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 será usado.
Como usar um datagroup para acionar entregas programadas
Os datagroups também podem ser usados para acionar a entrega de um dashboard ou um Look. Com essa opção, o Looker vai enviar seus dados quando o datagroup for concluído, para que o conteúdo programado fique atualizado.
Como usar o painel Admin para datagroups
Se você tiver a função de administrador do Looker, poderá usar a página Datagroups do painel Admin para conferir os datagroups atuais. É possível conferir a conexão, o modelo e o status atual de cada datagroup e, se especificado no LookML, um rótulo e uma descrição para cada datagroup. Também é possível redefinir o cache de um datagroup, acionar o datagroup ou navegar até o LookML do datagroup.
Armazenamento de consultas em cache com persist_for
Use o parâmetro persist_for no nível do modelo ou no nível da Análise para modificar o intervalo de retenção de cache padrão do Looker de 1 hora. É possível definir intervalos tão pequenos quanto 0 minutes e intervalos tão altos quanto 8760 hours (1 ano) ou mais.
A definição de parâmetros persist_for pode ser mais rápida e simples, mas menos robusta, do que a definição de datagroups. Os datagroups são recomendados em vez de persist_for pelos seguintes motivos:
- Os datagroups podem ser sincronizados com o processo de ETL do banco de dados.
- É possível reutilizar datagroups em vários modelos e Análises. Isso significa que é possível atualizar o
max_cache_agede um datagroup, e ele vai atualizar a política de armazenamento em cache em cada lugar em que o datagroup é usado. - É possível limpar todo o cache associado a um datagroup na página Datagroups.