Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
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,539 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
  • Be the first to comment

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 |

×