Aplicando processamento paralelo em instruções SQL

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, 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 |

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 |

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 |

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 |

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 |

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 |

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 |

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 |

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  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 |

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 |

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 |

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 |

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 |

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 |

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 |

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 |

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 |

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 |

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

Aplicando processamento paralelo em instruções SQL

by pichiliani on Apr 15, 2012

Accessibility

Categories

Upload Details

Usage Rights

Statistics

Aplicando processamento paralelo em instruções SQL Presentation Transcript