O Looker reduz a carga no banco de dados e melhora o desempenho usando resultados armazenados em cache de consultas SQL anteriores quando elas 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, 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 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 saber 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.
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 em cache expiraram. Se os resultados armazenados em cache não tiverem expirado, o Looker 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 resultados das novas consultas serão armazenados em cache.
A política de retenção de cache padrão é de uma hora. A próxima seção, Como modificar políticas de retenção de cache, discute como reduzir ou aumentar esse tempo, além de descrever opções para sincronizar sua política de retenção de cache com o processo ETL (extrair, transformar e carregar) 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 no nível do modelo do LookML.
O mecanismo de armazenamento em 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 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 do Explore. 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 que usar grupos de dados por alguns motivos, conforme 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 será modificada da seguinte maneira:
- Antes do intervalo
persist_forou do intervalomax_cache_agedo grupo de dados expirar: se a consulta for executada novamente, o Looker 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. - Após o intervalo
persist_forou o intervalomax_cache_agedo grupo de dados expirar: se a consulta for executada de novo, o Looker extrai os dados do banco de dados diretamente e redefine 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 expulsos com base em um algoritmo do tipo menos usado 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 vez.
Minimizar o tempo que seus dados permanecem no cache
O Looker sempre grava os resultados da consulta no cache. Mesmo que os intervalos persist_for e max_cache_age estejam definidos como zero, os dados em cache ainda podem ser armazenados por até 10 minutos. Todos os dados do cliente armazenados no cache de disco são criptografados com o Padrão de criptografia avançada (AES).
Para minimizar o tempo de armazenamento de dados em cache:
- Para qualquer parâmetro
persist_for(para um modelo ou Análise) ou parâmetromax_cache_age(para 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 dele. Não é necessário definir o parâmetropersist_fordas TDPs como0 minutespara minimizar a quantidade de dados armazenados no cache. As TDPs são gravadas no próprio banco de dados, e não no cache. - Defina um intervalo pequeno no parâmetro
suggest_persist_for. O valorsuggest_persist_forespecifica por quanto tempo o Looker manterá as sugestões de filtro no cache. As sugestões de filtro são baseadas em uma consulta dos valores do campo 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 as sugestões de filtro em cache por seis horas. Para minimizar o tempo que seus dados permanecem no cache, defina o valorsuggest_persist_forcomo um valor menor, como5 minutes.
Como verificar se uma consulta foi retornada do cache
Em uma janela Explorar, analise as informações ao lado do botão Executar para determinar se uma consulta foi retornada do cache.
Quando uma consulta é retornada do cache, o texto "do cache" é exibido. Caso contrário, será exibido o tempo necessário para retornar a consulta.
Como forçar a geração de novos resultados do banco de dados
Em uma janela Explorar, é possível forçar a recuperação de novos resultados do banco de dados. Depois de fazer uma consulta (incluindo consultas de resultados mesclados), selecione a opção Limpar o cache e atualizar no menu de engrenagem Ações de exploração.
Armazenamento de consultas em cache e recriação de TDPs com grupos de dados
Use grupos de dados para coordenar a programação de ETL (extrair, transformar e carregar) do seu 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 em quando novos dados são adicionados ao seu banco de dados. Em seguida, aplique 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 datagroup para separar o acionador de recriação de TDP 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 TDP que é recriada com menos frequência. Nesse caso, é recomendável que o cache de consultas seja redefinido com uma frequência maior do que a reconstrução da TDP.
Definir um datagroup
Defina um grupo de dados com o parâmetro datagroup em um arquivo modelo ou no próprio arquivo LookML. É possível definir vários grupos de dados se você quiser diferentes políticas de armazenamento em cache e de 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 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 o tempo 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 a enviará ao banco de dados para receber novos resultados.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 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 um grupo de dados com uma sql_trigger configurada para recriar a TDP todos os dias. Além disso, max_cache_age é configurado para limpar o cache de consultas a cada duas horas, caso alguma Análise junte TDPs 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 datagroup, você pode atribuí-lo às Análises e TDPs:
- Para atribuir o datagroup a uma TDP, use o parâmetro
datagroup_triggerno parâmetroderived_table. Consulte a seção Como usar um grupo de dados para especificar um acionador de recriação para TDPs nesta página para ver um exemplo. - Para atribuir o datagroup a uma Análise, use o parâmetro
persist_withno nível do modelo ou no nível da Análise. Confira um exemplo na seção Como usar um grupo de dados para especificar a redefinição do cache de consultas para Análises nesta página.
Como usar um datagroup para especificar um acionador de recriação para TDPs
Para definir um acionador de recriação de TDP 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 TDPs individuais usando o subparâmetro datagroup_trigger na definição derived_table da TDP. Se você usar datagroup_trigger para a 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 o datagroup_trigger vai ser usado.
Veja a seguir 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"]
}
}
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 consultas para Análises
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 se quiser personalizar uma programação de redefinição de cache de consulta para o 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 consultas 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 grupos de dados, 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 consultas em "Explores", use o parâmetro persist_with:
- Para atribuir o datagroup como o padrão para todas as Análises em um modelo, use o parâmetro
persist_withno nível do modelo (em um arquivo de modelo). - Para atribuir o datagroup a Análises específicas, use o parâmetro
persist_withemexplore.
Os exemplos a seguir mostram um grupo de dados chamado orders_datagroup, 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 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 apenas 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 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. Portanto, 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, 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 vai ser usado.
Como usar um grupo de dados para acionar entregas programadas
Os grupos de dados também podem ser usados para acionar a exibição de um painel ou de um Look. Com essa opção, o Looker envia seus dados quando o grupo é concluído para atualizar o conteúdo programado.
Como usar o painel Administrador para grupos de dados
Se você tiver o papel de administrador do Looker, acesse a página Grupos de dados do painel Administrador para conferir os grupos. É possível conferir 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 grupo de dados. Também é possível redefinir o cache de um grupo de dados, 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 da Análise 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).
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 banco de dados.
- É possível reutilizar grupos de dados em vários modelos e Análises. Isso significa que você pode atualizar o
max_cache_agede um grupo de dados, e a política de armazenamento em cache é atualizada em cada local 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.