O Looker reduz a carga no banco de dados e melhora o desempenho usando resultados armazenados em cache de consultas SQL anteriores, quando 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 conferir se já existem resultados armazenados em cache para essa consulta. Os resultados armazenados em cache serão usados somente se todos os aspectos da consulta forem os mesmos, incluindo campos, filtros, parâmetros e limites de linhas.
Se 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 eles expiraram. Se os resultados armazenados em cache não tiverem expirado, o Looker vai usá-los para a consulta.
Se nenhum resultado armazenado em cache for encontrado para a consulta ou se eles 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, Como modificar políticas de retenção de cache, discute como reduzir 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.
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 como recriar PDTs com grupos de dados.
Para uma abordagem mais simples, use o parâmetro persist_for
no nível do modelo ou no nível de exploração. 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, o uso de persist_for
é menos robusto do que o uso de grupos de dados por alguns motivos, conforme discutido na seção Armazenamento em cache de consultas com persist_for.
Se uma Análise detalhada ou um modelo tiver um grupo de dados ou persist_for
definido, a política de armazenamento em cache será modificada da seguinte maneira:
- Antes do vencimento do intervalo
persist_for
ou domax_cache_age
do grupo de dados: se a consulta for executada novamente, o Looker vai extrair dados do cache. - Quando o intervalo
persist_for
ou o intervalomax_cache_age
do grupo de dados expirar: o Looker excluirá os dados do cache. - Depois que o intervalo
persist_for
ou o intervalomax_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 intervalopersist_for
oumax_cache_age
.
Um ponto importante é que os dados são excluídos do cache quando o intervalo de persist_for
ou max_cache_age
expira.
Quando o cache atinge o limite de armazenamento, os dados são expulsos com base em um algoritmo de LRU, 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 ficam 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 o Padrão de criptografia avançada (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_for
expira ou quando os dados atingem o intervalomax_cache_age
especificado no datagroup. Não é necessário definir o parâmetropersist_for
de PDTs como0 minutes
para 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 o parâmetro
suggest_persist_for
como um pequeno intervalo. O valorsuggest_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 oferecer 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 em que os dados ficam no cache, defina o valor desuggest_persist_for
como algo menor, como5 minutes
.
Como verificar se uma consulta foi retornada do cache
Em uma janela Explorar, é possível determinar se uma consulta foi retornada do cache analisando 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 que levou para retornar a consulta será exibido.
Como forçar a geração de novos resultados a partir do banco de dados
Em uma janela Explorar, é possível forçar a recuperação de novos resultados do banco de dados. Após executar uma consulta (incluindo consultas de resultados mesclados), selecione a opção Limpar cache e Atualizar a opção no menu de engrenagem Análise de ações.
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 PDT.
É possível usar um grupo de dados para especificar o gatilho de recriação para PDTs com base em quando novos dados são adicionados ao seu 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 desacoplar 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 atualizados com muita frequência e associada a uma PDT 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.
Como 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. Você pode definir vários grupos de dados se quiser diferentes políticas de recriação de armazenamento em cache e PDT para diferentes Análises e/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 o tempo do cache de uma consulta excede o período, o Looker o invalida. Na próxima vez que a consulta é emitida, o Looker a envia ao banco de dados para 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 datagroup 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 os parâmetros max_cache_age
, sql_trigger
ou interval_trigger
.
Confira um exemplo de um grupo de dados com uma sql_trigger
configurada para recriar o 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 junte PDTs a outros dados atualizados com mais frequência de 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_trigger
no parâmetroderived_table
. Consulte a seção Como 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, use o parâmetro
persist_with
no nível do modelo ou no nível da Análise. Consulte a seção Como usar um grupo de dados para especificar a redefinição do cache de consultas para "Análises" nesta página para ver um exemplo.
Como usar um grupo de dados para especificar um gatilho 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 de derived_table
da PDT. Se você usar datagroup_trigger
para sua TDP, não precisará 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 ambiente de desenvolvimento integrado do Looker, e apenas o datagroup_trigger
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 PDTs.
Como usar um grupo de dados para especificar a redefinição do cache de consultas para "Análises"
Quando um grupo de dados é acionado, o regenerador do Looker recria as PDTs que usam esse grupo como uma estratégia de persistência. Depois que as PDTs do grupo de dados forem recriadas, o Looker 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 do cache de consultas para o grupo. O parâmetro max_cache_age
permite limpar o cache de consultas de acordo com uma programação especificada, além da redefinição automática do cache de consulta que o Looker realiza quando as PDTs 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 consulta nas análises detalhadas, use o parâmetro persist_with
:
- Para atribuir o grupo de dados como padrão para todas as Análises em um modelo, use o parâmetro
persist_with
no nível do modelo (em um arquivo de modelo). - Para atribuir o grupo de dados a Análises individuais, use o parâmetro
persist_with
em umexplore
.
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
será usada para detectar quando um ETL ocorreu. 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 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
. Portanto, podemos adicionar o parâmetro persist_with
para especificar uma política de armazenamento em cache diferente para essas duas. As Análises orders
e orders_facts
não têm um parâmetro persist_with
. Portanto, 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 persist_with
será usado.
Usar um grupo de dados para acionar entregas programadas
Os grupos de dados também podem ser usados para acionar o envio de um painel ou uma visualização. Com essa opção, o Looker enviará seus dados quando o grupo for concluído, para que o conteúdo programado fique atualizado.
Como usar o painel do administrador para grupos de dados
Se você tiver a função de administrador do Looker, poderá usar a página Grupos de dados no 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 um deles. Também é possível redefinir o cache de um grupo de dados, acioná-lo ou navegar até o LookML do grupo de dados.
Armazenamento em cache de consultas 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 padrão de retenção de cache de 1 hora do Looker. É possível definir intervalos tão pequenos quanto 0 minutes
e até 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. Recomendamos os grupos de dados 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.
- Você pode reutilizar grupos de dados em vários modelos e análises detalhadas. Isso significa que você pode atualizar o
max_cache_age
de um grupo de dados para atualizar a política de armazenamento em 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.