Melhor performance consulta única tabela sem filtros e joins

Olá pessoal tudo bem.

Atualmente estou trabalhando com extração e transformação de dados porem tenho que trabalha com fonte de dados muitos grandes e que nunca são alteradas .

As vezes tenho que consulta um mesmo volume de dados varias vezes no dia muitas vezes vários dias, pensando em melhorar a performance das query que não mudam estou transformando varias tabelas em uma única tabela por exemplo:

select * from tabela1 t1 inner join tabela2 t2 on t2.coluna1 = t1.coluna1 where t1.coluna2 is not null

estou pegando o resultado e transformando em uma única tabela no caso ficaria tm_t1_t2 assim quando for busca os dados não preciso fica fazendo uniões só faço

select * from tm_t1_t2

foi uma estratégia que pensei não sei ser é melhor mais melhorou um pouco a performance porem estou achando que continua lento ainda.

Tem ideia de como melhorar essas performances dessas consultas.

Detalhes

Tenho SSD

Não estou usando índice nessa tabela intermediário, não é feito união com outras tabelas

Memória esta trabalhando em média 70% a 83% notebook 8G

CPU trabalhando em 38% Processador i5 10º geração

banco de dados Atual é MySQL , as vezes utilizo outros bancos como Firebird, SQL Server etc… sempre relacional

Não tenho experiência com banco normalizado , qualquer coiso estudo ser for o caso.

Tem casos em que chega gasta 5 horas para terminar uma consulta.

Depois que crio esta tabela intermediaria não aplico nenhum join where, ou outro tipo de filtro ou função.

Eu não tenho propriedade para falar sobre ETL, porém existem algumas boas práticas comuns quando estamos lidando com SQL de forma geral, e que trazem ganhos quando temos um grande volume de dados.

  • Incluir na cláusula SELECT somente os campos que serão utilizados naquele devido momento ao invés de SELECT * FROM.
  • Analisar o plano de execução da query para avaliar qual ponto da consulta está demorando mais tempo para ser concluída.
  • Com base na análise anterior, fazer a criação de índices para otimizar a busca feita pela engine do DB.
  • Com grandes volumes de dados podemos adotar a prática de particionamento de tabelas.
  • Se os dados não sofrem modificação (UPDATE/DELETE) pode ser possível utilizar a sumarização de dados e trabalhar com o padrão D -1, ou seja, calcular somente a diferença entre os dados sumarizados do dia anterior com os novos dados do dia atual, o que implicaria em uma redução significativa de tempo, dado que não precisaria ficar recalculando tudo, toda vez, sempre desde o inicio dos tempos até o dia atual.
2 curtidas

Fala ai xará, obrigado pela resposta.

então a questão das projeções todas as colunas e linhas são usadas.
depois que postei a pergunta aqui criei um index só por peso de consciência mais não adiantou nada.
A analise do plano de execução realmente não fiz vou ver que consigo tirar alguma informação.

Agora a questão de particiona é uma boa ideia mesmo pois tinha percebido que a consulta começa rápida porem com o tempo vai fica lenta, imagino que deve fica objetos na memoria do banco, realizei o particionamento vertical separando a consulta em varias thread fiz um teste aqui porem no meio processo aqui aconteceu um erro, mais deve melhorar mais o tempo de conclusão.

qualquer coisa vou parti para uma ideia radical transformando em um banco em NoSQL ou convertendo os dados para csv para fazer um teste,

Não falou o que está usando pra fazer a processamento da transformação, mas recomendo usar stored procedure ou qualquer meio via SQL direto no banco, não só pra extração, mas todo processamento. Deixa rodando em um job schedulado.

1 curtida

Depois de uma analise e testes percebi que meu maior gargalo não estava na busca de dados mais sim no processamento.

Fiz algumas alterações que alterou dramaticamente o tempo de horas para minutos dava até para até melhorar mais, mais esta bom já.

criei as tabelas temporárias e particionei em outras tabelas
criei alguns dicionário em memoria usando a ideia de particionando
ajustei as consultas linq
criei alguns processamentos em thread.

Agora preciso ajusta as escritas dos resultados de processamento, mais é outra historia isso vejo com tempo.
Valeu.

Como seus dados não mudam, crie views, acho que ficará ainda mais rápido.

1 curtida