Consultas de colocação em cache

O Looker reduz a carga na sua base de dados e melhora o desempenho através da utilização de resultados em cache de consultas SQL anteriores quando estão disponíveis e quando esta função é permitida pela sua política de colocação em cache. Esta página descreve a política de colocação em cache predefinida do Looker, juntamente com as opções disponíveis para modificar a duração dos resultados em cache na sua instância do Looker.

Como o Looker usa consultas em cache

Para consultas SQL, o mecanismo de colocação em cache no Looker funciona da seguinte forma:

  1. Quando uma consulta SQL é executada a partir de uma exploração, um Look ou um painel de controlo, o Looker verifica a cache para ver se já existem resultados em cache para essa consulta. Os resultados em cache só são usados se todos os aspetos da consulta forem iguais, incluindo campos, filtros, parâmetros e limites de linhas.

  2. Se forem encontrados resultados em cache, o Looker verifica a política de colocação em cache definida no modelo LookML para determinar se os resultados em cache expiraram. Se os resultados em cache não tiverem expirado, o Looker usa os resultados em cache para a consulta.

  3. Se não forem encontrados resultados em cache para a consulta ou se os resultados em cache tiverem expirado, o Looker executa a consulta na base de dados. Os novos resultados da consulta são, então, colocados em cache.

A política de retenção da cache predefinida é de uma hora. A secção seguinte, Modificar as políticas de retenção da cache, aborda a forma de reduzir ou aumentar este período, bem como descreve as opções para sincronizar a política de retenção da cache com o processo ETL (extração, transformação e carregamento) da base de dados.

Modificar políticas de retenção da cache

Pode especificar políticas de retenção de cache ao nível da exploração do LookML e ao nível do modelo do LookML.

O mecanismo de colocação em cache recomendado é usar um parâmetro datagroup ao nível do modelo. Os grupos de dados permitem-lhe sincronizar a política de retenção da cache de um modelo com a programação de ETL da sua base de dados através do parâmetro sql_trigger e da definição de um intervalo de expiração da cache com o parâmetro max_cache_age. Para mais informações, consulte a secção Colocar em cache consultas e reconstruir tabelas derivadas persistentes (PDTs) com grupos de dados.

Para uma abordagem mais simples, pode usar o parâmetro persist_for ao nível do modelo ou ao nível de exploração. A utilização do parâmetro persist_for desta forma permite-lhe definir um intervalo de expiração da cache que substitui o intervalo predefinido de uma hora. No entanto, a utilização de persist_for é menos robusta do que a utilização de grupos de dados por alguns motivos, conforme abordado na secção Colocar em cache consultas com persist_for.

Se uma exploração ou um modelo tiver um grupo de dados ou um persist_for definido, a política de colocação em cache é modificada da seguinte forma:

  • Antes de o intervalo de persist_for ou o intervalo do grupo de dados max_cache_age expirar: se a consulta for executada novamente, o Looker extrai dados da cache.
  • No momento em que o intervalo persist_for ou o intervalo do grupo de dados max_cache_age expira: o Looker elimina os dados da 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 extrai os dados diretamente da base de dados e repõe o intervalo persist_for ou max_cache_age.

Um ponto fundamental aqui é que os dados são eliminados da cache quando o intervalo persist_for ou max_cache_age expira.

Se a cache atingir o limite de armazenamento, os dados são rejeitados com base num algoritmo de menos usados recentemente (LRU), sem garantia de que os dados com intervalos persist_for ou max_cache_age expirados são eliminados de uma só vez.

Minimizar o tempo que os seus dados passam na cache

O Looker escreve sempre os resultados das consultas na cache. Mesmo que os intervalos de persist_for e max_cache_age estejam definidos como zero, os dados em cache podem continuar a ser armazenados durante até 10 minutos. Todos os dados dos clientes armazenados na cache de disco são encriptados com o padrão de encriptação avançada (AES).

Para minimizar o período durante o qual os dados são armazenados na cache:

  • Para qualquer parâmetro persist_for (para um modelo ou uma exploração) ou parâmetro max_cache_age (para um grupo de dados), defina o valor como 0 minutes. O Looker elimina a cache quando o intervalo persist_for expira ou quando os dados atingem o intervalo max_cache_age especificado no respetivo datagroup. (Não é necessário definir o parâmetro persist_for das tabelas derivadas persistentes (PDTs) como 0 minutes para minimizar a quantidade de dados armazenados na cache. Os PDTs são escritos na própria base de dados e não na cache.)
  • Defina o parâmetro suggest_persist_for para um intervalo pequeno. O valor suggest_persist_for especifica durante quanto tempo o Looker deve manter as sugestões de filtros na cache. As sugestões de filtros baseiam-se numa consulta dos valores do campo que está a ser filtrado. Estes resultados da consulta são mantidos na cache para que o Looker possa fornecer rapidamente sugestões à medida que o utilizador escreve no campo de texto do filtro. A predefinição é colocar as sugestões de filtros em cache durante 6 horas. Para minimizar o tempo que os dados permanecem na cache, defina o valor suggest_persist_for para algo inferior, como 5 minutes.

Verificar se uma consulta foi devolvida a partir da cache

Numa janela Explorar, pode determinar se uma consulta foi devolvida da cache consultando as informações junto ao botão Executar depois de executar uma consulta.

Quando uma consulta é devolvida da cache, é apresentado o texto "da cache". Caso contrário, é apresentado o tempo que demorou a devolver a consulta.

Forçar a geração de novos resultados a partir da base de dados

Numa janela Explorar, pode forçar a obtenção de novos resultados da base de dados. Depois de executar uma consulta (incluindo consultas de resultados unidos), selecione a opção Limpar cache e atualizar no menu de engrenagem Explorar ações.

Colocar em cache consultas e recompilar 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) da sua base de dados com a política de colocação em cache do Looker e a programação de recompilação da tabela derivada persistente (PDT).

Pode usar um grupo de dados para especificar o acionador de recompilação para PDTs com base no momento em que são adicionados novos dados à sua base de dados. Em seguida, pode aplicar o mesmo grupo de dados à sua exploração ou modelo para que os resultados em cache também expirem quando as PDTs forem reconstruídas.

Em alternativa, pode usar um grupo de dados para desassociar o acionador de recompilação de PDTs da idade máxima da cache. Isto pode ser útil se tiver um conteúdo de Explorar baseado em dados que são atualizados com muita frequência e associado a um PDT que é reconstruído com menos frequência. Neste caso, pode querer que a cache de consultas seja reposta com mais frequência do que a PDT é reconstruída.

Definir um grupo de dados

Defina um grupo de dados com o parâmetro datagroup, num ficheiro de modelo ou no respetivo ficheiro LookML. Pode definir vários grupos de dados se quiser políticas de recriação de tabelas derivadas persistentes (PDTs) e de colocação em cache diferentes para diferentes explorações ou PDTs no seu projeto.

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

  • label: especifica uma etiqueta 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 do grupo de dados.
  • max_cache_age: especifica uma string que define um período. Quando a idade da cache de uma consulta excede o período, o Looker invalida a cache. Na próxima vez que a consulta for emitida, o Looker envia a consulta para a base de dados para obter resultados atualizados.
  • sql_trigger: especifica uma consulta SQL que devolve uma linha com uma coluna. Se o valor devolvido pela consulta for diferente dos resultados anteriores da consulta, o grupo de dados entra num estado acionado.
  • interval_trigger: especifica uma agenda de tempo para acionar o grupo de dados, como "24 hours".

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

Segue-se um exemplo de um grupo de dados que tem um sql_trigger configurado para reconstruir o PDT todos os dias. Além disso, o max_cache_age está definido para limpar a cache de consultas a cada duas horas, caso alguma exploração 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, pode atribuí-lo a explorações e PDTs:

Usar um grupo de dados para especificar um acionador de recompilação para PDTs

Para definir um acionador de recompilação de PDTs através de 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 através do subparâmetro datagroup_trigger na definição derived_table do PDT. Se usar datagroup_trigger para a PDT, não precisa de especificar nenhuma outra estratégia de persistência para a tabela derivada. Se especificar várias estratégias de persistência para um PDT, recebe um aviso no IDE do Looker e apenas a datagroup_trigger é usada.

Segue-se um exemplo de uma definição de PDT que usa o grupo de dados customers_datagroup. Esta definição também adiciona vários índices, tanto em customer_id como em first_order_date. Para mais informações sobre a definição de 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 ver mais informações sobre como os grupos de dados funcionam com as PDTs.

Usar um grupo de dados para especificar a reposição da cache de consultas para explorações

Quando um grupo de dados é acionado, o regenerador do Looker recompila as PDTs que usam esse grupo de dados como uma estratégia de persistência. Assim que as PDTs do grupo de dados forem reconstruídas, o Looker limpa a cache das análises detalhadas que usam as PDTs reconstruídas do grupo de dados. Pode adicionar o parâmetro max_cache_age à definição do grupo de dados se quiser personalizar uma agenda de reposição da cache de consultas para o grupo de dados. O parâmetro max_cache_age permite-lhe limpar a cache de consultas numa programação especificada, além da reposição automática da cache de consultas que o Looker executa quando as PDTs do grupo de dados são reconstruídas.

Para definir uma política de colocação 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 usar para repor a cache de consultas em Explorações, use o parâmetro persist_with:

Os exemplos seguintes mostram um grupo de dados denominado orders_datagroup que está definido num ficheiro de modelo. O grupo de dados tem um parâmetro sql_trigger, que especifica que a consulta select max(id) from my_tablename vai ser usada para detetar quando ocorreu um ETL. Mesmo que essa ETL não ocorra durante algum tempo, o elemento max_cache_age do grupo de dados especifica que os dados em cache só são usados durante um máximo de 24 horas.

O parâmetro persist_with do modelo aponta para a política de colocação em cache orders_datagroup, o que significa que esta será a política de colocação em cache predefinida para todos os elementos Explorar no modelo. No entanto, não queremos usar a política de colocação em cache predefinida do modelo para as análises detalhadas customer_facts e customer_background, pelo que podemos adicionar o parâmetro persist_with para especificar uma política de colocação em cache diferente para estas duas análises detalhadas. As explorações orders e orders_facts não têm um parâmetro persist_with, pelo que usam a política de colocação em cache predefinida 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 especificar persist_with e persist_for, recebe um aviso de validação e é usado o valor persist_with.

Usar um grupo de dados para acionar envios agendados

Os grupos de dados também podem ser usados para acionar uma entrega de um painel de controlo ou de um Look. Com esta opção, o Looker envia os seus dados quando o grupo de dados estiver concluído, para que o conteúdo agendado esteja atualizado.

Usar o painel Administração para grupos de dados

Se tiver a função de administrador do Looker, pode usar a página Grupos de dados do painel Administração para ver os grupos de dados existentes. Pode ver a ligação, o modelo e o estado atual de cada grupo de dados e, se especificado no LookML, uma etiqueta e uma descrição para cada grupo de dados. Também pode repor a cache de um grupo de dados, acionar o grupo de dados ou navegar para o LookML do grupo de dados.

Colocar em cache consultas com persist_for

Use o parâmetro persist_for ao nível do modelo ou ao nível de exploração para modificar o intervalo de retenção da cache predefinido do Looker de 1 hora. Pode definir intervalos tão pequenos como 0 minutes e tão grandes como 8760 hours (1 ano) ou mais.

A definição de persist_forparâmetros pode ser mais rápida e simples, mas menos robusta do que a definição de 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 ETL da sua base de dados.
  • Pode reutilizar grupos de dados em vários modelos e explorações. Isto significa que pode atualizar o max_cache_age de um grupo de dados e a política de colocação em cache é atualizada em todos os locais onde o grupo de dados é usado.
  • Pode limpar toda a cache associada a um grupo de dados na página Grupos de dados.