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

1. Aplicando processamento paralelo
em instruções SQL
Msc. Mauro Pichiliani (@pichiliani)
mauro@pichiliani.com.br

2. AVISO
2 | 14/04/2012 |

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. Roteiro
 Hardware e HPC
 Processamento paralelo no SGBDR
 Paralelisando instruções SQL
 Demonstrações
 Testes de desempenho
 Análise dos resultados
 Conclusão
4 | 14/04/2012 |

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. 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. 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. 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. 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
9 | 14/04/2012 |

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
FREEPROCCACHE
10 | 14/04/2012 |

11. Testes de desempenho – Configurações
11 | 14/04/2012 |

12. Testes de desempenho – Aquecimento
12 | 14/04/2012 |

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 TIME
13 | 14/04/2012 |

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 dados
14 | 14/04/2012 |

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 TIME
15 | 14/04/2012 |

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. 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
17 | 14/04/2012 |

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. 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
19 | 14/04/2012 |

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áfico
20 | 14/04/2012 |

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
processador
21 | 14/04/2012 |

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 desempenho
22 | 14/04/2012 |

23. #prontofalei
Perguntas?
23 | 14/04/2012 |