|
 |
|
|
Receba nosso boletim semanal! |
|
|
|
Tecnologia que Interessa! |
|
|
|
|
Em função de novas atribuições assumidas em 2012, passei a me interessar mais profundamente (ui!) pelo
SQL Server, e vocês devem ter percebido que passei a postar
algumas coisas sobre o assunto. Como parte do processo de planejamento para migrar para a mais recente versão do SGBD de Redmond, resolvi conduzir alguns testes empíricos, e pretendo realizar também testes mais cientìficos, usando o HammerDB, que me pareceu uma ótima ferramenta para testes de desempenho em bancos de dados livres e não livres. Posteriormente devo publicar os novos resultados.
Considerando meus parcos conhecimentos em bancos de dados, resolvi fazer alguns testes de desempenho por conta própria, e por isso este texto (como diria Lulu Santos) não tem a “menor pretensão de convencer”, mas sim de validar se os resultados obtidos são legítimos. Aliás, ficarei extremamente grato se, diante de alguma barbeirada cometida nos testes, os queridos leitores mais experientes fizerem a gentileza de apontá-la e sugerir correções nos procedimentos de teste. Mas deixemos de blá blá blá e vamos ao que interessa, que são os testes, e seus resultados, que aliás foram o principal motivador deste texto. Já adianto que, se meu empirismo estiver em dia, o recado é claro: você tem muito a ganhar atualizando para o SQL Server 2012.
Para a realização dos testes, foram utilizados dois servidores com configurações idênticas (ou o mais próximo disso que conseguimos):
- 4 processadores, 12 GB de RAM e cerca de 500 GB de disco;
- Os dois servidores são máquinas virtuais executando sob hosts distintos, mas idênticos em termos de configurações de hardware;
- Além disso, tivemos o cuidado (tanto eu quanto os colegas que colaboraram na montagem do ambiente) de verificar que a alocação dos discos das máquinas virtuais no storage tivesse características de desempenho bem próximas.
Foram definidas 3 medidas para os testes:
1 – Tempo da consulta no SQL Server 2005;
2 – Tempo da consulta no SQL Server 2012 – base em modo de compatibilidade SQL 2005;
3 – Tempo da consulta no SQL Server 2012 – base em modo de compatibilidade SQL 2012;
Um colega sugeriu reiniciar os servidores e recriar os índices das tabelas, afim de deixar o banco de dados em situação minimamente otimizada para a realização dos testes. Assim, o procedimento foi realizado para cada tabela utilizada nos testes. Tentei realizar testes diversificados, afim de avaliar a diferença de desempenho em situações bem distintas, mas sempre considerando um volume significativo de dados, pois acreditava que para volumes pequenos a diferença seria reduzida.
Primeiro teste: SELECT * em tabela com 5,4 milhões de registros
1 – SQL Server 2005 – 7min59s
2 – SQL Server 2012 (2005) – 4min22s (~ 83% mais rápido)
3 – SQL Server 2012 (2012) – 4min24s (~ 83% mais rápido)
Segundo teste: SELECT com JOIN em duas tabelas com 5,4 e 1,18 milhões de registros
1 – SQL Server 2005 – 14min13s
2 – SQL Server 2012 (2005) – 6min16s (~ 127% mais rápido)
3 – SQL Server 2012 (2012) – 5min54s (~ 141% mais rápido)
Terceiro teste: SELECT * em tabela com 22,6 milhões de registros
1 – SQL Server 2005 – 16min41s
2 – SQL Server 2012 (2005) – 6min13s (~ 169% mais rápido)
3 – SQL Server 2012 (2012) – 5min49s (~ 187% mais rápido)
Quarto teste: SELECT com JOIN e ORDER BY em duas tabelas com 22,6 e 13,48 milhões de registros
1 – SQL Server 2005 – 20min03s
2 – SQL Server 2012 (2005) – 16min29s (~ 21,6% mais rápido)
3 – SQL Server 2012 (2012) – 15min04s (~ 33% mais rápido)
Quinto teste: SELECT * em tabela com 188 milhões de registros
1 – SQL Server 2005 – 20min50s
2 – SQL Server 2012 (2005) – 13min42s (~ 52,6% mais rápido)
3 – SQL Server 2012 (2012) – 8min28s (~ 145% mais rápido)
Observações
Em alguns testes foi necessário o uso da cláusula TOP, variando entre 2 e 20 milhões de registros obtidos, afim de viabilizar a conclusão dos testes. Alguns testes mais complexos foram tentados mas o servidor com SQL Server 2005 não aguentou, talvez por limitação do ambiente (tempdb, etc).
Cabe lembrar que não foram feitas quaisquer otimizações no SQL Server 2012, como criação de índice ColumnStore e outras possibilidades de melhoria de desempenho específicas desta versão, o que sugere que o ganho pode ser ainda maior. Não foi aplicado sequer o Service Pack 1, já disponível.
Podem haver ainda outros fatores a considerar de modo a garantir que a comparação seja válida, mas, em princípio, as diferenças de desempenho observadas se referem a melhorias no SQL Server mesmo.
Fiquei com a impressão de que às vezes, no SQL Server 2012, executar a mesma consulta sucessivamente tem resultado cada vez melhor. Em tese, uma melhor utilização de memória poderia explicar isso, mas não tenho informações para afirmar.
Conclusão
A tabela abaixo relaciona os ganhos em cada teste, bem como a média de ganho no desempenho para todos os testes.
| Teste |
1 |
2 |
3 |
4 |
5 |
Média |
| Ganho (2012/2005) |
83% |
127% |
169% |
21,6% |
52,6% |
90,64% |
| Ganho (2012/2012) |
83% |
141% |
187% |
33% |
145% |
117,8% |
Com base nestes dados podemos afirmar que há ganho bastante significativo de desempenho no SQL Server 2012.
Cabe lembrar, entretanto, que estes testes refletem a realidade de um ambiente específico, e portanto não podem nem devem ser utilizados como referência geral de desempenho. De todo modo, ficamos bem animados com os resultados.
Resta agora fazer os testes com o HammerDB para confirmar as conclusões.
Siga-nos no Twitter!
Curta nossa página no facebook!
Confira outros textos sobre o tema!
