Aplicando processamento paraleloem instruções SQLMsc. Mauro Pichiliani (@pichiliani)mauro@pichiliani.com.br
AVISO2 | 14/04/2012 |
Sobre mim Mestre e doutorando em computação pelo ITA Escritor da SQL Magazine, Fórum Access, Java  Magazine, SQLServerCe...
Roteiro     Hardware e HPC     Processamento paralelo no SGBDR     Paralelisando instruções SQL     Demonstrações    ...
Processamento paralelo - hardware     Era de processadores multi-core (lógicos/físicos)     Virtualização: controle de p...
Processamento paralelo - HPC    HPC: High Performance Computing    Supercomputadores: lista TOP500 (http://www.top500.or...
Processamento paralelo no SGBDR    Geralmente processamento paralelo é utilizado na aplicação    No SGBDR utiliza-se um ...
Paralelisando instruções SQL - Assembly  Assembly .NET escrito por Alan Kaplan:     Artigo “Asynchronous T-SQL Execution...
Paralelisando instruções SQL - Técnicas  Não substitui as técnicas existentes para tuning de SQL  Para obtenção de desem...
Testes de desempenho – cenário   Testes de desempenho de INSERT, DELETE, UPDATE, SELECT    com e sem cache do SQL Server ...
Testes de desempenho – Configurações11 | 14/04/2012 |
Testes de desempenho – Aquecimento12 | 14/04/2012 |
Testes de desempenho – INSERT   Ferramentas para o INSERT:          Comando INSERT          Comando BULK INSERT        ...
Testes de desempenho – Resultado INSERT      Melhor cenário: N=700.000 com cache (redução de 92%)      Média do tempo de...
Testes de desempenho – DELETE   DELETE apaga linhas passando pelo Transaction Log   Teste didático: para remover todas a...
Testes de desempenho – Resultado DELETE      Melhor cenário: N=500.000 com cache (redução de 99%)      Média do tempo de...
Testes de desempenho – UPDATE   Teste de UPDATE incrementa 1 para cada coluna float   Soma ou subtração geram resultados...
Testes de desempenho – Resultado UPDATE      Melhor cenário: N=500.000 com cache (redução de 99%)      Média do tempo de...
Testes de desempenho – SELECT   Instrução SELECT somou o valor das 10 colunas float   Uso do SUM() sem o group by. Outra...
Testes de desempenho – Resultado SELECT      Nota: diferença de escala com e sem cache      Melhor cenário: N=400.000 se...
Análise dos resultados   Alguns fatores impactam no resultado: plano de execução,    cache, transaction log e I/O do S.O....
Conclusões   Era de processadores com múltiplos núcleos   Programação paralela é necessária para obter desempenho   Pou...
#prontofalei                    Perguntas?23 | 14/04/2012 |
Upcoming SlideShare
Loading in …5
×

Aplicando processamento paralelo em instruções SQL

2,080 views
1,959 views

Published on

Minha apresentação sobre uso de processamento paralelo em instruções SQL para o evento SQL Sat 127 realizado no Rio de Janeiro em 14/04/2012

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,080
On SlideShare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
26
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Aplicando processamento paralelo em instruções SQL

  1. 1. Aplicando processamento paraleloem instruções SQLMsc. Mauro Pichiliani (@pichiliani)mauro@pichiliani.com.br
  2. 2. AVISO2 | 14/04/2012 |
  3. 3. Sobre mim Mestre e doutorando em computação pelo ITA Escritor da SQL Magazine, Fórum Access, Java Magazine, SQLServerCentral.com e outras Colaborador do iMasters há 10 anos Autor do livro “Conversando sobre banco de dados” Co-autor do @databasecast 3 | 14/04/2012 |
  4. 4. Roteiro  Hardware e HPC  Processamento paralelo no SGBDR  Paralelisando instruções SQL  Demonstrações  Testes de desempenho  Análise dos resultados  Conclusão4 | 14/04/2012 |
  5. 5. Processamento paralelo - hardware Era de processadores multi-core (lógicos/físicos) Virtualização: controle de processadores lógicos Licenciamento do SGBD: depende de número de processadores Fabricante fornece o valor máximo de processamento em GFLOPS Para lembrar: 1 megaflop = 1 milhão de flops = 10^6 operações p.f. por segundo 1 gigaflop = 1 bilhão de flops = 10^9 operações p.f. por segundo 1 teraflop = 1 trilhão de flops = 10^12 operações p.f. por segundo 1 petaflop = 1 quatrilhão de flops = 10^15 operações p.f. por segundo Processador topo de linha: 50~70 GFLOPS No máximo 10% disso é utilizado É preciso muito esforço de programação para obter bom desempenho Solução: uso de processamento paralelo 5 | 14/04/2012 |
  6. 6. Processamento paralelo - HPC HPC: High Performance Computing Supercomputadores: lista TOP500 (http://www.top500.org/) Uso de cluster, GPU, SSD, Infini Band e outras tecnologias Uso de linguagens de programação adequadas (C/C++, Fortran, etc)  Modelo de programação paralela  Diversas primitivas para processameto paralelo  Suporte de compilador  Diretivas para lock direto no microcódigo Paralelismo é tradicionamento aplicado em:  Jogos  Simulações  Construção de modelos  Renderização  Segurança (força bruta) 6 | 14/04/2012 |
  7. 7. Processamento paralelo no SGBDR Geralmente processamento paralelo é utilizado na aplicação No SGBDR utiliza-se um plano de execução para cada instrução SQL Plano de execução pode conter operadores indicando paralelismo: Sem recursos para trabalhar com threads no SGBDR. Porém:  SGBDR escala bem pelo número de conexões  Há recursos para tratar problemas de concorrência (locks)  Utiliza linguagem adequada para manipulação de dados  Há como utilizar outras linguagems (C#, Java, Pl/Pg-SQL, etc) no SGBDR Proposta: fornecer recursos para programação paralela com instruções SQL Nota: novos recursos do .NET seguem esta linha (Parallel.ForEach) 7 | 14/04/2012 |
  8. 8. Paralelisando instruções SQL - Assembly  Assembly .NET escrito por Alan Kaplan:  Artigo “Asynchronous T-SQL Execution Without Service Broker” em http://migre.me/8EUFc  Cria até 64 conexões no sevidor local  Executa instruções SQL de forma paralela  Aguarda por término de todas elas  Emprega 6 stored procedures, 2 funções e tabelas internas  Permite controle de transação  Obtenção de tempos de execução e erros  Código fonte disponível (projeto em C# no VS.NET).  Demo 1: Instalação do assembly (Listagem1.sql e Deployment.sql)  Demo 2: Inserção de linhas de forma paralela (Listagem2.sql)  Demo 3: Tempo de execução (Listagem3.sql)8 | 14/04/2012 |
  9. 9. Paralelisando instruções SQL - Técnicas  Não substitui as técnicas existentes para tuning de SQL  Para obtenção de desempenho com paralelismo:  Técnica de independência de instruções  Técnica de divisão do domínio  Procurar utilizar o assembly em cenários de muito processamento (expurgo, fechamento mensal, etc)  Tenha muito cuidado com o controle de concorrência  Evitar colocar paralelismo em consultas „simples‟  Fazer testes para comprovar o ganho de desempenho9 | 14/04/2012 |
  10. 10. Testes de desempenho – cenário  Testes de desempenho de INSERT, DELETE, UPDATE, SELECT com e sem cache do SQL Server  Cenário:  Intel Core i 950 (4 core @ 3.06 GHZ), 12GB RAM, 64KB Cache L1, 256KB Cache L2, 8MB Cache L3, 1 TB SATA 2 ~ 50 GFLOPS  Windows 2008 Enterprise+SP1 64 Bits (real), SQL Server 2008 R2+SP1 64 Bits  Dados:  Tabela com 11 colunas: 1 int (PK) + 10 float. Valores float aleatórios  Número de linhas (N) variando de 100.000 a 1.000.000  64 Threads dividindo o valor de N igualmente  Um banco de dados com Recovery Model bulk-logged+Transaction log adequado  Limpeza de cache: DBCC DROPCLEANBUFFERS e DBCC FREEPROCCACHE10 | 14/04/2012 |
  11. 11. Testes de desempenho – Configurações11 | 14/04/2012 |
  12. 12. Testes de desempenho – Aquecimento12 | 14/04/2012 |
  13. 13. Testes de desempenho – INSERT  Ferramentas para o INSERT:  Comando INSERT  Comando BULK INSERT  Utilitário bcp.exe [MELHOR DESEMPENHO]  Teste:  Importação de N linhas em 64 threads. Cada thread: N/64 linhas  Todos os arquivos na mesma pasta e divididos por tamanho  Transaction log adequado (50% acima do máximo em cada teste)  Para cada N o teste foi realizado 10 vezes  Limpeza do cache a cada teste para cenário sem cache  Medição do tempo de execução com o SET STATISTICS TIME13 | 14/04/2012 |
  14. 14. Testes de desempenho – Resultado INSERT  Melhor cenário: N=700.000 com cache (redução de 92%)  Média do tempo de execução paralelo:  69% mais rápido sem cache  83% mais rápido com cache  S.O. paralelisa I/O da leitura e gravação de dados14 | 14/04/2012 |
  15. 15. Testes de desempenho – DELETE  DELETE apaga linhas passando pelo Transaction Log  Teste didático: para remover todas as linhas use TRUNCATE TABLE ou DROP TABLE  Uso ou não de lock hints não alteraram resultado  Teste:  Remoção de N linhas em 64 threads. Cada thread: N/64 linhas  TempDB adequado (50% acima do máximo em cada teste)  Transaction log adequado (50% acima do máximo em cada teste)  Para cada N o teste foi realizado 10 vezes  Limpeza do cache a cada teste para cenário sem cache  Medição do tempo de execução com o SET STATISTICS TIME15 | 14/04/2012 |
  16. 16. Testes de desempenho – Resultado DELETE  Melhor cenário: N=500.000 com cache (redução de 99%)  Média do tempo de execução paralelo:  27% mais rápido sem cache  85% mais rápido com cache  Dados não cabem no cache a partir de (N=500.000)16 | 14/04/2012 |
  17. 17. Testes de desempenho – UPDATE  Teste de UPDATE incrementa 1 para cada coluna float  Soma ou subtração geram resultados semelhantes  Uso ou não de lock hints não alteraram resultado  Teste:  Update de N linhas em 64 threads. Cada thread: N/64 linhas  TempDB adequado (50% acima do máximo em cada teste)  Transaction log adequado (50% acima do máximo em cada teste)  Valores float adequados para evitar overflow  Para cada N o teste foi realizado 10 vezes  Limpeza do cache a cada teste para cenário sem cache  Medição do tempo de execução com o SET STATISTICS TIME17 | 14/04/2012 |
  18. 18. Testes de desempenho – Resultado UPDATE  Melhor cenário: N=500.000 com cache (redução de 99%)  Média do tempo de execução paralelo:  70% mais rápido sem cache  63% mais rápido com cache  Novamente, dados não cabem no cache a partir de (N=500.000)18 | 14/04/2012 |
  19. 19. Testes de desempenho – SELECT  Instrução SELECT somou o valor das 10 colunas float  Uso do SUM() sem o group by. Outras aggregações geraram resultados semelhantes  Uso ou não de lock hints não alteraram resultado  Teste:  Select de N linhas em 64 threads. Cada thread: N/64 linhas  TempDB adequado (50% acima do máximo em cada teste)  Valores float adequados para evitar overflow  Para cada N o teste foi realizado 10 vezes  Limpeza do cache a cada teste para cenário sem cache  Medição do tempo de execução com o SET STATISTICS TIME19 | 14/04/2012 |
  20. 20. Testes de desempenho – Resultado SELECT  Nota: diferença de escala com e sem cache  Melhor cenário: N=400.000 sem cache (redução de 98%)  Média do tempo de execução paralelo:  77% mais rápido sem cache  57% mais rápido com cache  Variações no plano de execução explicam picos/declínios no gráfico20 | 14/04/2012 |
  21. 21. Análise dos resultados  Alguns fatores impactam no resultado: plano de execução, cache, transaction log e I/O do S.O.  INSERT: 69% mais rápido sem cache e 83% mais rápido com cache  DELETE: 27% mais rápido sem cache e 85% mais rápido com cache  UPDATE: 70% mais rápido sem cache e 63% mais rápido com cache  SELECT: 77% mais rápido sem cache e 57% mais rápido com cache  Supondo melhor cenário no SELECT: 2*10^8 ~ 1 GFLOP  Isso representa apenas 2% da capacidade total do processador21 | 14/04/2012 |
  22. 22. Conclusões Era de processadores com múltiplos núcleos Programação paralela é necessária para obter desempenho Poucos recursos para paralelismo em SGBDR Custo do paralelismo requer esforço de programação Testes com assembly .NET indicam melhora média de:  76% no tempo de execução do INSERT  56% no tempo de execução do DELETE  66,5% no tempo de execução do UPDATE  67% no tempo de execução do SELECT Há espaço para novas possibilidades e melhorias nos SGBDR em termos de paralelismo e desempenho22 | 14/04/2012 |
  23. 23. #prontofalei Perguntas?23 | 14/04/2012 |

×