aplicando processamento paralelo em instruções sql
DESCRIPTION
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/2012TRANSCRIPT
![Page 1: Aplicando processamento paralelo em instruções SQL](https://reader033.vdocuments.pub/reader033/viewer/2022061215/54a0bc85ac7959365a8b457c/html5/thumbnails/1.jpg)
Aplicando processamento paralelo em instruções SQLMsc. Mauro Pichiliani (@pichiliani)
![Page 2: Aplicando processamento paralelo em instruções SQL](https://reader033.vdocuments.pub/reader033/viewer/2022061215/54a0bc85ac7959365a8b457c/html5/thumbnails/2.jpg)
AVISO
14/04/2012 |2 |
![Page 3: Aplicando processamento paralelo em instruções SQL](https://reader033.vdocuments.pub/reader033/viewer/2022061215/54a0bc85ac7959365a8b457c/html5/thumbnails/3.jpg)
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
14/04/2012 |3 |
![Page 4: Aplicando processamento paralelo em instruções SQL](https://reader033.vdocuments.pub/reader033/viewer/2022061215/54a0bc85ac7959365a8b457c/html5/thumbnails/4.jpg)
Roteiro
Hardware e HPC Processamento paralelo no SGBDR Paralelisando instruções SQL Demonstrações Testes de desempenho Análise dos resultados Conclusão
14/04/2012 |4 |
![Page 5: Aplicando processamento paralelo em instruções SQL](https://reader033.vdocuments.pub/reader033/viewer/2022061215/54a0bc85ac7959365a8b457c/html5/thumbnails/5.jpg)
Processamento paralelo - hardware
14/04/2012 |5 |
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
![Page 6: Aplicando processamento paralelo em instruções SQL](https://reader033.vdocuments.pub/reader033/viewer/2022061215/54a0bc85ac7959365a8b457c/html5/thumbnails/6.jpg)
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)
14/04/2012 |6 |
![Page 7: Aplicando processamento paralelo em instruções SQL](https://reader033.vdocuments.pub/reader033/viewer/2022061215/54a0bc85ac7959365a8b457c/html5/thumbnails/7.jpg)
Processamento paralelo no SGBDR
14/04/2012 |7 |
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)
![Page 8: Aplicando processamento paralelo em instruções SQL](https://reader033.vdocuments.pub/reader033/viewer/2022061215/54a0bc85ac7959365a8b457c/html5/thumbnails/8.jpg)
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)
14/04/2012 |8 |
![Page 9: Aplicando processamento paralelo em instruções SQL](https://reader033.vdocuments.pub/reader033/viewer/2022061215/54a0bc85ac7959365a8b457c/html5/thumbnails/9.jpg)
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 desempenho
14/04/2012 |9 |
![Page 10: Aplicando processamento paralelo em instruções SQL](https://reader033.vdocuments.pub/reader033/viewer/2022061215/54a0bc85ac7959365a8b457c/html5/thumbnails/10.jpg)
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
FREEPROCCACHE
14/04/2012 |10 |
![Page 11: Aplicando processamento paralelo em instruções SQL](https://reader033.vdocuments.pub/reader033/viewer/2022061215/54a0bc85ac7959365a8b457c/html5/thumbnails/11.jpg)
Testes de desempenho – Configurações
14/04/2012 |11 |
![Page 12: Aplicando processamento paralelo em instruções SQL](https://reader033.vdocuments.pub/reader033/viewer/2022061215/54a0bc85ac7959365a8b457c/html5/thumbnails/12.jpg)
Testes de desempenho – Aquecimento
14/04/2012 |12 |
![Page 13: Aplicando processamento paralelo em instruções SQL](https://reader033.vdocuments.pub/reader033/viewer/2022061215/54a0bc85ac7959365a8b457c/html5/thumbnails/13.jpg)
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 TIME
14/04/2012 |13 |
![Page 14: Aplicando processamento paralelo em instruções SQL](https://reader033.vdocuments.pub/reader033/viewer/2022061215/54a0bc85ac7959365a8b457c/html5/thumbnails/14.jpg)
Testes de desempenho – Resultado INSERT
14/04/2012 |14 |
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 dados
![Page 15: Aplicando processamento paralelo em instruções SQL](https://reader033.vdocuments.pub/reader033/viewer/2022061215/54a0bc85ac7959365a8b457c/html5/thumbnails/15.jpg)
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 TIME
14/04/2012 |15 |
![Page 16: Aplicando processamento paralelo em instruções SQL](https://reader033.vdocuments.pub/reader033/viewer/2022061215/54a0bc85ac7959365a8b457c/html5/thumbnails/16.jpg)
Testes de desempenho – Resultado DELETE
14/04/2012 |16 |
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)
![Page 17: Aplicando processamento paralelo em instruções SQL](https://reader033.vdocuments.pub/reader033/viewer/2022061215/54a0bc85ac7959365a8b457c/html5/thumbnails/17.jpg)
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 TIME
14/04/2012 |17 |
![Page 18: Aplicando processamento paralelo em instruções SQL](https://reader033.vdocuments.pub/reader033/viewer/2022061215/54a0bc85ac7959365a8b457c/html5/thumbnails/18.jpg)
Testes de desempenho – Resultado UPDATE
14/04/2012 |18 |
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)
![Page 19: Aplicando processamento paralelo em instruções SQL](https://reader033.vdocuments.pub/reader033/viewer/2022061215/54a0bc85ac7959365a8b457c/html5/thumbnails/19.jpg)
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 TIME
14/04/2012 |19 |
![Page 20: Aplicando processamento paralelo em instruções SQL](https://reader033.vdocuments.pub/reader033/viewer/2022061215/54a0bc85ac7959365a8b457c/html5/thumbnails/20.jpg)
Testes de desempenho – Resultado SELECT
14/04/2012 |20 |
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áfico
![Page 21: Aplicando processamento paralelo em instruções SQL](https://reader033.vdocuments.pub/reader033/viewer/2022061215/54a0bc85ac7959365a8b457c/html5/thumbnails/21.jpg)
Análise dos resultados
14/04/2012 |21 |
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 processador
![Page 22: Aplicando processamento paralelo em instruções SQL](https://reader033.vdocuments.pub/reader033/viewer/2022061215/54a0bc85ac7959365a8b457c/html5/thumbnails/22.jpg)
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 desempenho
14/04/2012 |22 |
![Page 23: Aplicando processamento paralelo em instruções SQL](https://reader033.vdocuments.pub/reader033/viewer/2022061215/54a0bc85ac7959365a8b457c/html5/thumbnails/23.jpg)
#prontofalei
Perguntas?
14/04/2012 |23 |