TPC-H BENCHMARKING NO MYSQL Abel S. Camati Zacarias João Holden Dulo Bioco University of Coimbra University of Coimbra DEI – CISUC DEI Coimbra, Portugal Coimbra, Portugal [email protected][email protected]RESUMO Devido a padronização existente nos motores de base de dados, a diferença entre os produtos dos vários fornecedores passa a ser o nível de desempenho proporcionado. (Lorena, 2007). O presente trabalho faz um estudo sobre a performance do Mysql; Para tal, utilizou-se o TPC-H, um benchmark de apoio a decisão que é fornecido gratuitamente pela TPC (Transaction Processing Performance Council), O TPC é uma organização sem fins lucrativos, tendo como objetivo principal estabelecer critérios para se obter informações a respeito da performance de processamento de transações e de base de dados através de benchmarks. O TPC-H é um dos testes padronizados para obter resultados de performance, e posteriormente são divulgados os dados reais dessa performance. Os testes permitem que organizações escolham motores em função do resultado da performance. No TPC-H, o benchmark é definido como a execução de um teste de carregamento seguido por um teste de desempenho. Os testes de desempenho começaram desde a criação das tabelas, carregamento de dados (foram carregados 6 GB de dados) até a criação de índices e chaves, ou seja todas as actividades necessárias para levar o sistema a ser testado. O teste de desempenho consistiu na execução de dez consultas add hoc todas com a anotação dos tempos de duração, e posteriormente fez-se um conjunto de tabelas e gráficos espelhando os resultados (tempos) tanto da fase de carregamento como na execução das consultas. Key words- TPC-H, Brenchmark, MySql, Base de Dados, performance e query.
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
TPC-H BENCHMARKING NO MYSQL
Abel S. Camati Zacarias João Holden Dulo Bioco University of Coimbra University of Coimbra DEI – CISUC DEI Coimbra, Portugal Coimbra, Portugal [email protected][email protected] RESUMO Devido a padronização existente nos motores de base de dados, a diferença entre os produtos dos vários fornecedores passa a ser o nível de desempenho proporcionado. (Lorena, 2007). O presente trabalho faz um estudo sobre a performance do Mysql; Para tal, utilizou-se o TPC-H, um benchmark de apoio a decisão que é fornecido gratuitamente pela TPC (Transaction Processing Performance Council), O TPC é uma organização sem fins lucrativos, tendo como objetivo principal estabelecer critérios para se obter informações a respeito da performance de processamento de transações e de base de dados através de benchmarks. O TPC-H é um dos testes padronizados para obter resultados de performance, e posteriormente são divulgados os dados reais dessa performance. Os testes permitem que organizações escolham motores em função do resultado da performance. No TPC-H, o benchmark é definido como a execução de um teste de carregamento seguido por um teste de desempenho. Os testes de desempenho começaram desde a criação das tabelas, carregamento de dados (foram carregados 6 GB de dados) até a criação de índices e chaves, ou seja todas as actividades necessárias para levar o sistema a ser testado. O teste de desempenho consistiu na execução de dez consultas add hoc todas com a anotação dos tempos de duração, e posteriormente fez-se um conjunto de tabelas e gráficos espelhando os resultados (tempos) tanto da fase de carregamento como na execução das consultas. Key words- TPC-H, Brenchmark, MySql, Base de Dados, performance e query.
1
1- INTRODUÇÃO Avaliação de desempenho consiste em avaliar um sistema (computacional ou não),
buscar uma métrica que indique quantidade ou qualidade, por exemplo, de um
serviço prestado ou ainda determinar a eficiência com a qual um sistema atinge seus
objetivos, determinar a eficiência com a qual um sistema atinge as necessidades e
expectativas de seus utilizadores e de seus desenvolvedores, para uma dada
Gráfico2-‐ Tempo de carregamento dos dados nas tabelas por segundos. O gráfico acima, apresenta o tempo de carregamento de cada uma das 8 tabelas
existente na Base de Dados. E pelos resultados pode-se verificar que a tabela
LINEITEM é a que mais tempo de execução levou, cerca de 71,66% em relação as
outras. Este tempo de execução que a mesma levou, deve-se principalmente a
quantidade de linhas (360.00.147linhas) que a mesma possui bem como a
quantidade de informação nela contida (7.7GB). A tabela que menos tempo de
execução levou foi a tabela NATION, cerca de 0,00046%.
5.3- CARREGAMENTO DAS CHAVES PRIMÁRIAS E ESTRANGEIRAS.
Criou-se de seguida as chaves primárias e secundarias nas tabelas da Base de
Dados, com o objectivo de garantir a integridade dos dados.
7,2178
309,8828
0,002
62,8393
8,5028 43,5401
0,009 0,4197
TEMPO DE EXECUÇÃO/ SEC
CUSTOMER
LINEITEM
NATION
ORDERS
PART
PARTSUPP
REGION
SUPPLIER
8
5.3.1- CHAVES PRIMÁRIAS
A tabela abaixo e o respectivo gráfico, mostram os tempos (em segundos),
de carregamento das chaves primárias.
Nº O TABELAS Temp. Carreg. Primary Key/ Seg
1 CUSTOMER 8,1814
3 LINEITEM 677,1544
4 NATION 0,0209
4 ORDERS 79,5134
5 PART 10,4987
6 PARTSUPP 46,2618
7 REGION 0,0375
8 SUPPLIER 0,5324 Tabela3- Carregamento das chaves Primária
Gráfico3- Carregamento das chaves Primarias.
5.3.2- CHAVES ESTRANGEIRAS
Pode-se verificar, na tabela e gráfico abaixo os resultados obtidos na criação
das chaves estrangeiras.
8,1814
677,1544
0,0209
79,5134
10,4987
46,2618
0,0375 0,5324
Tempo de Carreg.
CUSTOMER
LINEITEM
NATION
ORDERS
PART
PARTSUPP
REGION
SUPPLIER
Nº O TABELAS Temp. Carreg. Foreign Key/ Seg
1 CUSTOMER 9,4518
2 LINEITEM 9291,1391
3 NATION 0,0582
9
Tabela4- Carregamento das Chaves Estrangeiras.
Gráfico4-‐ Carregamento das Chaves Estrangeiras.
5.4- TEMPO DE CRIAÇÃO DOS ÍNDECES
Os índices foram criados com base nos campos utilizados nos critérios de busca.
TABELA ÍNDECE TEMPO/SEC CUSTOMER INDEX_CUSTOMER 2,972 LINEITEM INDEX_LINEITEM 288,8038 NATION INDEX_NATION 0,0452 ORDERS INDEX_ORDERS 35,9125 PART INDEX_PART 5,5986 PARTSUPP INDEX_PARTSUPP 16,0626 REGION INDEX_REGION 0,0662 SUPPLIER INDEX_SUPPLIER 0,1889 Tabela5- Tempo da criação dos índices por tabelas
9,4518
9291,1391
0,0582
1660,2618
115,5943
0,7479
Temp. Carreg. Foreign Key
CUSTOMER
LINEITEM
NATION
ORDERS
PARTSUPP
SUPPLIER
4 ORDERS 1660,2618
5 PARTSUPP 115,5943
6 SUPPLIER 0,7479
10
Gráfico5- Criação de índices
5.5-‐ PESQUISA Na próxima tabela e gráfico, mostra-se os resultados de cada uma das queries
efetuadas na Base de Dados. Apresentamos na mesma tabela e gráfico o tempo que
levou para a execução de cada query. O tempo apresentado está expresso em
segundos.
Query Rows Tempo de Execução/Seg Q1 4 104,2518 Q 2 2.809 84,1047 Q 3 68.496 466,2878 4 5 44,6434 5 5 299,5164 6 1 20,0214 7 4 248,6847 8 2 523,8567 9 175 1.840,9723 10 228.580 738,6247 Total 300.081 4.370,9639 Tabela6-‐ Tempo do carregamento das chaves primárias.
2,972
288,8038
0,0452
35,9125 5,5986
16,0626
0,0662
0,1889
TEMPO/SEC INDEX_CUSTOMER
INDEX_LINEITEM
INDEX_NATION
INDEX_ORDERS
INDEX_PART
INDEX_PARTSUPP
INDEX_REGION
INDEX_SUPPLIER
11
Gráfico6-‐ Carregamento das chaves primárias. Pode-se também verificar o tempo de execução de cada uma das 10 queries
escolhidas na Base de Dados de teste. Constatou-se que a query número 9 é a que
mais tempo levou para a execução (1.840,9723segundos) cerca de 42% em relação
as demais consultas. Isto deve-se ao facto de a consulta número 9 englobar 7 das 8
tabelas (part, supplier, lineitem, partsupp, orders, nation ) o que corresponde a
87,5% das tabelas e isso torna a consulta muito lenta.
104,2518 84,1047
466,2878 44,6434
299,5164
20,0214 248,6847 523,8567
1840,9723 738,6247
Q1 Q2 Q3 Q4 Q5 Q6 Q7 Q8 Q9 Q10
0 200 400 600 800 1000 1200 1400 1600 1800 2000
TIME EXECUTION/ SEC
12
6 – CONCLUSÕES Com base nos testes feitos, constatou-‐se o seguinte:
! Quanto maior for o volume de dados, menor é desempenho do MySql, obrigando o escalonamento vertical ou horizontal;
! Servidores com maiores capacidade de processamento e armazenamento contribuem para o melhor desempenho do MySql no que diz respeito ao carregamento de dados e execução de consultas;
! As consultas com elevadas junções, agregações de tabelas foram as mais lentas no que diz respeito ao tempo de execução;
! MySql pode suportar bases de dados transacionais, mas não é o motor adequado para implementar uma base de dados de apoio a decisão.