Otimizando o desempenho dos aplicativos
O desempenho dos aplicativos pode ser aprimorado com a redução do seu tamanho, com modelos de dados simplificados e por meio do uso estratégico de análises de conjuntos. Esta seção ajudará você a evitar problemas de desempenho, apontando áreas nas quais o desempenho pode ser afetado e como você pode avaliar e monitorar o desempenho do aplicativo.
É possível ver o desempenho do aplicativo com a ferramenta de avaliação de desempenho. Para obter mais informações, consulte Avaliação de desempenho de aplicativos.
Complexidade do aplicativo
Essas são categorias abertas que podem ajudar no diagnóstico de problemas. Os aplicativos mais complexos apresentam o menor desempenho.
Aplicativos simples:
- Não incluem análises complexas de conjuntos ou comandos If().
- Não incluem tabelas grandes.
- Têm um modelo de dados simples.
- Contêm cálculos simples.
- Podem ter grandes volumes de dados.
Aplicativos moderados:
- Têm um modelo de dados com muitas tabelas, mas seguem práticas recomendadas.
- Usam análise de conjuntos e vários comandos If().
- Têm tabelas grandes ou amplas em pastas (15 colunas ou mais).
Aplicativos complexos:
-
Têm um modelo de dados muito complexo.
- Conectam-se a grandes volumes de dados.
- Contêm cálculos, gráficos e tabelas complexos.
Grandes volumes de dados
Você pode empregar estas estratégias de arquitetura ao se conectar a grandes volumes de dados.
Segmentação
É possível segmentar QVDs por dimensões, como período, região ou nível de agregação. Por exemplo, você pode ter:
- Um QVD que contém dados dos dois anos mais recentes.
- Um QVD que contém dados históricos além de dois anos.
Um QVD que contém todos os dados agregados em um nível mais alto. Por exemplo, por mês em vez de data, ou por país em vez de clientes individuais.
- Um QVD grande com todos os dados, que são usados apenas por um pequeno subconjunto de usuários.
Os aplicativos podem ser segmentados de maneira semelhante. Aplicativos menores atenderão às necessidades analíticas da maioria dos usuários. Isso economiza memória.
Você também pode ter vários aplicativos focados em diferentes regiões. Dessa forma, os usuários não abrirão um aplicativo com dados nos quais não estejam interessados ou aos quais não tenham direitos de acesso. Os dados não acessíveis via Section Access ainda afetam a memória.
Geração de aplicativos sob demanda (ODAG)
Aplicativos Qlik Sense sob demanda oferecem aos usuários exibições agregadas de repositórios de big data. Eles podem identificar e carregar subconjuntos relevantes dos dados para análises detalhadas.
Da perspectiva do usuário, existem dois aplicativos:
- Um carrinho de compras com dados agregados.
- Um aplicativo modelo vazio usado para exibir detalhes.
O usuário faz seleções no aplicativo de carrinho de compras. Depois que um limite é atingido, é criado um script LOAD personalizado que preenche o aplicativo modelo com os detalhes solicitados. Para obter mais informações, consulte Gerenciando big data com aplicativos on-demand.
Encadeamento de aplicativos
O encadeamento de aplicativos (conhecido como encadeamento de documentos no QlikView) significa que existe um aplicativo agregado, que os usuários consomem regularmente. Se um usuário precisar de mais detalhes, seleções poderão ser transmitidas do aplicativo agregado a um aplicativo de detalhes, para que esse usuário possa visualizar um nível mais baixo de granularidade. Isso economiza memória, pois o usuário não está carregando detalhes desnecessários. O encadeamento de aplicativos pode ser executado adicionando objetos de botão a uma pasta. Para obter mais informações, consulte Encadeamento de aplicativos.
O encadeamento de aplicativos também tem suporte por meio do APIs. Por exemplo, você pode usar a API de integração de aplicativos para criar encadeamentos de aplicativos personalizados. Para mais informações, consulte API de integração de aplicativos (somente em inglês).
Exibições dinâmicas
Exibições dinâmicas permitem visualizações atualizadas para alto volume de dados ou cenários de dados que mudam rapidamente. Considere o seguinte ao trabalhar com exibições dinâmicas:
Ao atualizar visualizações dinâmicas, a fonte de dados é carregada diretamente. O desempenho da atualização é afetado pelo desempenho da fonte de dados subjacente.
Aplicativos de modelo de exibição dinâmica podem ajudar a criar gráficos dinâmicos.
Para obter mais informações sobre como usar exibições dinâmicas, consulte Gerenciando dados com exibições dinâmicas.
(DIRECT QUERY *)
Embora aplicativos na memória sejam recomendados, o Direct Query permite manter os dados em sua fonte original. Considere o seguinte para otimizar o uso do Direct Query:
O desempenho do Direct Query é fortemente afetado pelo desempenho da fonte de dados subjacente.
Mantenha seu modelo de dados do Direct Query o mais simples possível, pois consultas complexas podem causar problemas de desempenho.
Para obter mais informações sobre o Direct Query, consulte Acessando bancos de dados na nuvem diretamente com o Direct Query.
Desempenho do modelo de dados
Estes são indicadores que podem afetar o desempenho do modelo de dados. Cada um deles é uma prática recomendada que melhorará a utilidade do aplicativo.
| Ação | Descrição |
|---|---|
Chaves sintéticas removidas | O Qlik Sense cria chaves sintéticas quando duas ou mais tabelas de dados têm dois ou mais campos em comum. Isso pode significar que há um erro no script ou no modelo de dados. Para diagnosticar chaves sintéticas, consulte Chaves sintéticas. |
Referências circulares removidas do modelo de dados | Referências circulares ocorrem quando dois campos têm mais de uma associação. O Qlik Sense tentará resolvê-las, alterando a conexão com uma das tabelas. No entanto, todos os avisos de referência circular devem ser resolvidos. Consulte Entendendo e solucionando as referências circulares. |
Granularidade apropriada dos dados | Você deve carregar apenas os dados necessários. Por exemplo: um grupo de usuários precisa apenas de dados divididos por semana, mês e ano. É possível carregar os dados agregados ou agregar esses dados no script de carregamento para economizar memória. Se um usuário precisar visualizar dados em um nível mais baixo de granularidade, você poderá usar o ODAG ou o encadeamento de documentos. |
QVDs usados sempre que possível | Um QVD é um arquivo que contém uma tabela de dados exportada do Qlik Sense. Esse formato de arquivo é otimizado para velocidade ao ler dados de um script, mas ainda é muito compacto. A leitura de dados de um arquivo QVD é geralmente de 10 a 100 vezes mais rápida do que a leitura de outras fontes de dados. Para obter mais informações, consulte: Trabalhando com arquivos QVD. |
Arquivos QVD otimizados no carregamento | Os arquivos QVD podem ser lidos em dois modos, padrão (rápido) e otimizado (mais rápido). O modo selecionado é determinado automaticamente pelo mecanismo de script. Existem algumas limitações em relação a carregamentos otimizados. É possível renomear campos, mas qualquer uma dessas operações resultará em um carregamento padrão:
|
Carregamentos incrementais otimizados | Se o seu aplicativo se conectar a uma grande quantidade de dados provenientes de bancos de dados atualizados continuamente, recarregar todo o conjunto de dados pode ser muito demorado. Em vez disso, você deve usar o carregamento incremental para recuperar registros novos ou alterados do banco de dados. Para obter mais informações, consulte Carregando registros novos e atualizados com carregamento incremental. |
Modelo Snowflake consolidado | Se você tiver um modelo de dados Snowflake, poderá reduzir o número de tabelas de dados ao unir algumas delas com o uso do prefixo Join ou outro mapeamento. Isso é especialmente importante para tabelas de fatos grandes. Uma boa regra é ter apenas uma tabela grande. Para obter mais informações, consulte Unir ou não unir. |
Tabelas que possuem um pequeno número de campos são desnormalizadas | Se você tiver duas tabelas com poucos campos, uni-las poderá melhorar o desempenho. Para obter mais informações, consulte Combinando tabelas com Join e Keep. |
Tabelas de pesquisa (folha) desnormalizadas com carregamentos de mapeamentos | Não use o prefixo Join se precisar adicionar apenas um campo de uma tabela a outra tabela. Você deve usar a função de consulta ApplyMap. Consulte Não una - use ApplyMap. |
Carimbos de data/hora removidos ou dissociados do campo de data | Campos de data podem preencher espaço quando o carimbo de data/hora está presente, pois a representação da string é maior e o número de valores distintos também é maior. Se a precisão não for necessária para sua análise, você poderá arredondar o carimbo de data/hora para, por exemplo, a hora mais próxima usando Timestamp(Floor(YourTimestamp,1/24)) ou remover o componente de tempo completamente usando Date(Floor(YourTimestamp)). Se o carimbo de data/hora não for desejável, você poderá dissociá-lo da própria data. É possível usar a mesma função Floor() e, em seguida, criar um novo campo com a hora extraída, usando algo semelhante ao seguinte: Time(Frac(YourTimestamp)). |
Campos desnecessários removidos do modelo de dados | Você deve carregar apenas os campos necessários no seu modelo de dados. Evite usar Load * e SELECT. Certifique-se de manter:
|
Tabelas de links evitadas ao lidar com grandes volumes de dados | Você deve usar tabelas de links sempre que possível. No entanto, se estiver lidando com grandes volumes de dados, tabelas concatenadas poderão superar tabelas de links. |
Dimensões concatenadas divididas em novos campos | Você deve dividir dimensões concatenadas em campos separados. Isso reduz o número de ocorrências exclusivas de valores nos seus campos. Esse processo é semelhante a como carimbos de data/hora podem ser otimizados. |
Comando AutoNumber usado sempre que possível | É possível criar um carregamento otimizado, carregando seus dados primeiramente de um arquivo QVD e depois usando o comando AutoNumber para converter valores em chaves de símbolos. Para obter mais informações, consulte AutoNumber. |
Ilhas de dados evitadas | Ilhas de dados podem ser úteis, mas geralmente afetam o desempenho. Se estiver criando ilhas para valores de seleção, use variáveis. |
QVDs são armazenados com base em períodos incrementais | Você deve armazenar QVDs em segmentos, como mensalmente. Esses QVDs mensais menores podem então oferecer suporte a muitos aplicativos diferentes que talvez não precisem de todos os dados. |
Desempenho de pastas
Estas são práticas recomendadas que melhorarão o desempenho de pastas e visualizações.
| Ação | Descrição |
|---|---|
A função If() é evitada sempre que possível | Se a função If() for usada dentro de uma função de agregação, ela operará no nível do registro e será avaliada muitas vezes. Por exemplo, se você tiver 1000 registros em uma agregação, uma condição If() será avaliada 1000 vezes. Isso poderá gerar rapidamente um efeito cascata se você aninhar comandos. Em vez disso, use análises de conjunto. Um filtro de análise de conjunto é aplicado antes da agregação, resultando em uma resposta mais rápida. Essas respostas também podem ser armazenadas em cache via análise de conjuntos, o que não é possível com If(). Você também pode considerar outras funções e modificações no modelo de dados. |
| Campos de diferentes tabelas dentro de uma tabela de agregação são evitados sempre que possível. | Quando uma agregação é avaliada, o cálculo é executado em duas etapas:
A parte com encadeamento único pode afetar o desempenho consideravelmente. Um exemplo é quando existem vários campos dentro da agregação, como Sum(Quantity*ListPrice). Se Quantity estiver na tabela de fatos e ListPrice estiver na tabela de produtos mestre, primeiro o mecanismo precisará unir as duas tabelas para encontrar as combinações para poder começar a somar o produto. A união é a parte de encadeamento único, e a soma é parte de vários encadeamentos. Se ambos os campos forem encontrados na mesma tabela, nenhuma união será necessária, e a agregação será avaliada de maneira consideravelmente mais rápida. |
Aggr() e funções Aggr() aninhadas são usadas minimamente | A função Aggr() afeta muito o desempenho. Seu uso incorreto pode gerar resultados imprecisos. Por exemplo, em uma tabela com dimensões que variam das dimensões dentro da função Aggr(). Para obter mais informações, consulte Quando o AGGR não deve ser usado? |
A análise de conjuntos é usada sempre que possível | É possível usar a análise de conjuntos para definir um conjunto de valores de dados diferente do conjunto normal definido pelas seleções atuais. Para obter mais informações, consulte Análise de conjunto. |
Comparações de strings evitadas sempre que possível | Comparações de strings não são tão eficientes quanto análises de conjuntos. Por exemplo, você deve evitar Match(), MixMatch(), WildMatch() e Pick(). Crie sinalizadores no script ou use a análise de conjunto como alternativa. Para obter mais informações, consulte Funções condicionais e Desempenho de agregações condicionais. |
Condições de cálculo são usadas em objetos que contêm cálculos intensivos | Você pode ter visualizações com muitos registros quando não existem seleções. Como prática recomendada, adicione condições de cálculo aos objetos para que eles sejam renderizados somente depois que determinadas seleções forem feitas. Isso interrompe a criação de hipercubos muito grandes. Por exemplo: GetSelectedCount([Country])=1 OR GetPossibleCount([Country])=1. Nesse cenário, a visualização não será renderizada, a menos que o usuário selecione um único país ou faça outras seleções em que apenas um único país é possível. |
Medidas são pré-calculadas no script sempre que possível | Qualquer medida que esteja no nível mais baixo de granularidade do modelo de dados deve ser calculada no script. Por exemplo, no mesmo registro de uma tabela, se você tiver Sales e Cost, será possível derivar a margem calculando Sales - Cost AS Margin. Você também poderá agregar outros valores antecipadamente se souber que eles não variarão com base na seleção ou que estão vinculados a um nível diferente de granularidade. |
Tabelas têm menos de 15 colunas e têm condições de cálculo | Uma tabela com 15 colunas pode ser considerada ampla. Se as suas tabelas consistirem em muitos registros, você deverá usar condições calculadas no objeto da tabela, para que ele seja processado somente depois que determinadas seleções ou critérios forem atendidos. Se sua tabela for muito grande, considere o seguinte:
|
As pastas não têm um número excessivo de objetos | Os objetos são calculados quando o usuário navega até a pasta. Sempre que um usuário fizer uma seleção nessa pasta, cada objeto será recalculado se esse estado atual não existir no cache. Se você tiver uma pasta com muitos gráficos, o usuário terá que esperar que cada objeto seja calculado em quase todas as seleções. Isso coloca uma carga significativa sobre o mecanismo. Como prática recomendada, siga o conceito de Dashboard/Analysis/Reporting (DAR) para desenvolver um aplicativo limpo e minimalista.Para obter mais informações, consulte Metodologia DAR. |
Sinalizadores numéricos são otimizados no script para uso na análise de conjuntos | A análise de conjuntos com sinalizadores pode ser mais eficiente do que usar comparações ou a multiplicação de strings. |
| Itens mestre permitem arrastar e soltar métricas controladas e garantir que as expressões sejam armazenadas em cache. Por exemplo, Sum(Sales) é diferente de SUM(Sales). Expressões são armazenadas em cache em nível de ortografia e formatação de maiúsculas e minúsculas e precisam corresponder literalmente para serem reutilizadas. |
Desempenho de carregamento dos dados
Otimizar o carregamento de dados é importante para uma experiência contínua e responsiva ao trabalhar com aplicativos no Qlik Cloud. Esta seção destaca os fatores que afetam o desempenho e fornece orientação sobre como evitar problemas de desempenho.
Qlik Data Gateway - Direct Access
Quando você usa o Qlik Data Gateway - Direct Access para recarregar dados no seu aplicativo, os seguintes fatores afetam o desempenho:
Velocidade da conexão e latência entre a máquina que hospeda o Data Gateway e o banco de dados.
Velocidade da conexão e latência entre a máquina que hospeda o Data Gateway e o seu locatário do Qlik Cloud. O ideal é hospedar o Data Gateway na mesma região do seu locatário do Qlik Cloud para melhorar o desempenho.
Armazenamento do banco de dados
Conexões de armazenamento lentas podem aumentar o tempo de recarregamento. Considere o seguinte para bancos de dados hospedados no local ou na nuvem:
No local: Se o seu banco de dados estiver local e compartilhar um servidor com outros aplicativos, seu desempenho poderá ser afetado pelas atividades desses outros aplicativos.
Nuvem: Quando dimensionados corretamente, os bancos de dados na nuvem normalmente oferecem melhor desempenho do que os bancos de dados locais. Para obter os melhores resultados, escolha uma região para seu armazenamento em nuvem que seja próxima ao seu locatário do Qlik Cloud.