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
Aplicando processamento paralelo em instruções SQLMsc. Mauro Pichiliani (@pichiliani)
AVISO
14/04/2012 |2 |
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 |
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 |
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
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 |
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)
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 |
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 |
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 |
Testes de desempenho – Configurações
14/04/2012 |11 |
Testes de desempenho – Aquecimento
14/04/2012 |12 |
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 |
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
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 |
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)
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 |
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)
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 |
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
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
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 |
#prontofalei
Perguntas?
14/04/2012 |23 |