1 / 42

Análise comparativa de desempenho entre MySQL e PostgreSQL

Maio/2006. Análise comparativa de desempenho entre MySQL e PostgreSQL. Fábio Ávila avila@itautec.cin.ufpe.br http://itautec.cin.ufpe.br/. Agenda. Introdução Benchmarks utilizados Destaque ao DBT-2 Resultados Conclusões e trabalhos futuros Perguntas. Objetivo.

tobias
Download Presentation

Análise comparativa de desempenho entre MySQL e PostgreSQL

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Maio/2006 Análise comparativa de desempenho entre MySQL e PostgreSQL Fábio Ávila avila@itautec.cin.ufpe.br http://itautec.cin.ufpe.br/

  2. Agenda • Introdução • Benchmarks utilizados • Destaque ao DBT-2 • Resultados • Conclusões e trabalhos futuros • Perguntas

  3. Objetivo • Comparativo de desempenho entre MySQL e PostgreSQL no Linux • Uso dos benchmarks DBT-2, OSDB e PolePosition • Estimular melhoria do desempenho de SGBD de código aberto • Não promover vencedores e perdedores

  4. Quem Somos • Convênio P&D entre Itautec e CIn/UFPE • Laboratório de Análise de Performance • Fundado em Janeiro/2003 • Objetivos • Análise de desempenho de servidores de missão crítica • Certificação TPC-C em servidores da Itautec • HCT Librix • Resultados • 8 publicações TPC-C • Apresentações em eventos • Releases de white papers e HCT http://itautec.cin.ufpe.br

  5. Equipe TPC Carlos Eduardo Pires Rilson Nascimento Fábio Ávila Francisco Carvalho Marcelo Rodrigues

  6. Benchmarks • Definição • Padrão para medida ou avaliação • Gera métricas de desempenho • Permite comparações • Destaca oportunidades de melhoria • Performance / Feature • Características desejáveis • Especificação detalhada e aberta • Produzido por órgãos neutros • Escalonável (scalable) • Portátil • Reproduzível

  7. Breve Histórico de Benchmarks • Wisconsin Benchmark - David DeWitt (1983) • Provocou criação da “cláusula DeWitt” • Paper Anon et Al - Jim Gray (1985) • AS3AP (1987) - Carolyn Turbyfill • Implementação: OSDB (2001) • TPC (1988) • SPEC (1988) • BAPCo (1991) • TPC-C (1993) • SPC (1997) • TPC-App (2004)

  8. Transaction Processing Performance Council (TPC) • Fundada em 1988 • Realidade parecida com a Fórmula 1 • Grandes investimentos na tentativa de superar os concorrentes • 18 full members • HP, IBM, Oracle, Microsoft, Unisys, Sun, Intel, AMD, Dell, Fujitsu, NEC, Teradata, Novell, Sybase, Bull, Netezza • 4 associate members • OSDL, CIn/UFPE, Ideas, ITOM

  9. Open Source Development Labs (OSDL) • Organização sem fins lucrativos, fundada em 2000 • Missão • Incentivar a utilização do Linux • Reconhecida mundialmente por seus projetos • IPV6-DHCP, kernel testing, DBT-*, etc. • Recebe investimentos de grandes empresas como Fujitsu, HP, IBM e Intel • Associate member da TPC

  10. Benchmarks Utilizados • DBT-2 • Implementação da OSDL do TPC-C • OSDB • Implementação OpenSource do AS3AP • PolePosition • Instanciando objetos em Java

  11. Hardware Utilizado • Servidor Itautec • 2 Processadores Pentium III Xeon 1.0 GHz • 2GB RAM, Cache L2 256KB • 1 Disco Interno SCSI Seagate 10Krpm • 1 Storage com 14 Discos SCSI Seagate 15Krpm de 36GB RAID 0 • 1 Placa Controladora Mylex Extreme RAID 2000 4C • 1 Switch 1Gbps

  12. Software Utilizado • Linux Fedora Core 4, Kernel 2.6.11-1.1369_FC4smp, filesystem ext3 • PostgreSQL 8.1.3 on i686-pc-linux-gnu, compiled by GCC gcc (GCC) 4.0.0 20050519 (Red Hat 4.0.0-8) • MySQL 5.0.12-beta-standard-log • dbt2-0.37, Novembro de 2005

  13. Ambiente de Teste Sistema sob Avaliação Switch DBT-2 e OSDB: Console VNC PolePosition: Gerador de Carga Eclipse Servidor Itautec Storage Linux + DBT-2 + SGBD Banco de Dados

  14. Database Test 2 (DBT-2) • Implementação incompleta do TPC-C • Não comparável aos resultados oficiais TPC-C • Código Aberto • Simula um ambiente OLTP • Operações refletem as 5 atividades principais de uma empresa atacadista • Explora consultas, transações curtas e concorrência • Acesso não-uniforme aos dados • Ambiente multi-usuário

  15. Modelo Lógico do Banco de Dados Warehouse W 10 District W * 10 History W * 30k+ 100k 3k 1+ Stock W * 100k Customer W * 30k New-Order W * 9k+ 1+ 0-1 W 3+ Item 100k Order-Line W * 300k+ Orders W * 30k+ 5-15

  16. Exemplo: PostgreSQL, 115w Warehouse (115) 24 KB District (1.150) 184 KB History (3.450.000) 290 MB Stock (11.500.000) 3.8 GB Customer (3.450.000) 2.2 GB New-Order (1.035.000) 40 MB Item (100.000) 10.8 MB Order-Line (32.767.533) 3 GB Orders (3.450.000) 221 MB Total (incluindo índices): 11.7 GB

  17. Transações do DBT-2 • Escrita e leitura • New-Order • Entrada de um novo pedido • Payment • Registra um pagamento de cliente • Delivery • Processa a entrega de um lote de 10 pedidos • Consulta • Order-Status • Retorna o status do último pedido de um cliente • Stock-Level • Retorna itens que têm nível de estoque abaixo de um limite específico

  18. Percentuais de Execução • Payment 43% • Order-Status 4% • Delivery 4% • Stock Level 4% • New-Order ≡ 45% (restante)

  19. Métricas • NOTPM • Número de Transações New-Order por minuto • Regra de escalabilidade do TPC-C • 1 warehouse  10 usuários • Exemplo para 1.000 usuários: • BD: 100 warehouses • Desempenho mínimo: 900 NOTPM • Desempenho máximo: 1286 NOTPM

  20. Emulação de usuários 1 – Escolhe tipo da transação 2 – Tempo de resposta do menu (após exibição na tela) 3 – Tempo de espera (keying time) 4 – Tempo de processamento (após exibir dados na tela) 5 – Tempo de espera (think time)

  21. PostgreSQL 8.1.3 (postgresql.conf) fsync = off [on] shared_buffers = 20.000 (156 MB) [1.000] checkpoint_segments = 256 [6] checkpoint_timeout = 1800 s [300] stats_* = off [on] work_mem = 1024K [512] MySQL 5.0.12 Beta (my-huge.cnf) innodb_buffer_pool_size = 1228 MB[384] innodb_log_file_size = 307 MB[100] innodb_flush_log_at_trx_commit = 0[1] thread_concurrency = 4[8] Tuning – DBT-2

  22. Número de Transações New-Order por Minuto (NOTPM)

  23. CPU

  24. Context Switches

  25. I/O

  26. Benchmark AS3AP • Trabalho acadêmico • Carolyn Turbyfill / Cyril Orji / Dina Bitton • Aberto e neutro • Evolução do famoso “Wisconsin Benchmark” • Normalização • Tamanho do BD >= memória física • Métrica • Maximum database size (under 12 hours) • Boa cobertura dos recursos de um SGBD • Métodos de acesso, tipos de dados, índices • Joins, projections, aggregates • Updates • Bulk load, output mode • Testes multi-usuário

  27. OSDB • Open Source Database Benchmark • Última versão: 0.17, Out/2004 • Código aberto, disponível no SourceForge • Problemas de estabilidade • Implementação do AS3AP • Mais um Feature Benchmark • Algumas funcionalidades não muito relevantes • Apresentamos comparativo no fisl6.0 • Versões anteriores, maior detalhamento • Métrica • Maximum database size / 12h

  28. OSDB • Nossos testes • Tamanho do banco: 1GB • 2.500.000 registros por tabela + índices • 4 tabelas: uniques, hundred, tenpct, updates • Registros de 100 bytes • Não houve tuning • Ideal: mínimo de 2GB • Problemas para estabilizar o teste • Credibilidade • O AS3AP é bastante respeitado, mas OSDB é pouco utilizado e referenciado • “I wish you’d stop using it” • Josh Berkus, PostgreSQL Lead Developer

  29. Resultados OSDB (1GB) • 93 operações realizadas pelo benchmark • 23 etapas de criação e população de tabelas • 46 testes mono-usuário • 24 testes multi-usuário • A tabela mostra o número de vezes que cada SGBD teve melhor desempenho em determinada categoria • Critério de empate: Diferença inferior a 10%

  30. OSDB – Anomalias • bulk_modify • update updates set key=key-100000 where key between 5000 and 5999 • Tempo de execução • 33 minutos no PostgreSQL • Menos de 1 segundo no MySQL • bulk_delete • delete updates where key < 0 • Tempo de execução • 34 minutos no PostgreSQL • Menos de 1 segundo no MySQL • Bug, implementação ou tuning?

  31. Benchmark PolePosition • Implementação aberta em Java • Neutra para SGBD • Desempenho da persistência de objetos no SGBD • Mede mapeamento de acesso relacional e objeto-relacional • Leitura, escrita, manipulação de árvore de objetos • Circuitos • Representação de um conjunto de testes • Lap • Teste individual em um circuito • Ex: Melbourne: delete, read, read_hot, write • Número de objetos configurável

  32. Benchmark PolePosition • Bahrain • escreve, lê, atualiza e apaga objetos sem hierarquia individualmente • Barcelona • escreve, lê, consulta e apaga objetos de uma estrutura de cinco níveis • Imola • Lê objetos por chave primária • Melbourne • Escreve, lê e apaga objetos não-estruturados de um tipo em modo bulk • Sepang • Escreve, lê e depois apaga uma árvore de objetos

  33. Benchmark PolePosition • Fácil de rodar, bastante estável e reproduzível • Oportunidades de tuning • No carro • Tecnologia de acesso: db4o, Hibernate, JDBC, etc. • No piloto • SGBD: MySQL, PostgreSQL, HSQLDB, Derby • Nossos testes • Carro único: JDBC • SGBD sem tuning • Número de objetos • Barhain e Barcelona: 1.000, 3.000, 5.000, 7.000, 9.000 • Melbourne: 25.000, 50.000, 75.000, 100.000 • Imola: 10.000, 30.000, 100.000, 300.000 • Sepang: 36, 55, 78, 105

  34. Resultados PolePosition • 86 operações realizadas pelo benchmark • A tabela mostra o número de vezes que cada SGBD teve melhor desempenho em determinado circuito • Critério de empate: Diferença inferior a 10%

  35. PolePosition - Anomalias • Barcelona write • MySQL de 5x a 39x mais rápido que o PostgreSQL • Barcelona delete • 1.000 objetos  PostgreSQL 5x mais rápido que MySQL • 3.000, 5.000, 7.000, 9.000 objetos  MySQL 5x a 40x mais rápido que PostgreSQL • Melbourne read_hot • PostgreSQL ganha no read, mas mostra anomalia de desempenho no read_hot • “JDBC caching is a known issue with the current JDBC driver. JDBC lead Dave Cramer is currently working on a fix, sponsored by Sun Microsystems” – Josh Berkus • Bugs, implementação ou tuning?

  36. Conclusões • Tuning aumenta significativamente o desempenho. • MySQL no DBT-2: 75% • PostgreSQL no DBT-2: 15% • Para uma boa análise, um só benchmark não basta • Participação fundamental de especialistas • PostgreSQL: Josh Berkus (DBT-2) • MySQL: Peter Zaitsev (DBT-2) • DBT-2: Mark Wong

  37. Conclusões • No DBT-2, o desempenho foiequivalente • PostgreSQL mostrou ligeira vantagem • MySQL mostrou espaço para melhoria via tuning • “The difference between the procedure and plain statements version is some 30% in our tests” – Peter Zaitsev • No OSDB, o MySQL se mostrousuperior na maioria dos testes • Verificadas anomalias no PostgreSQL • No PolePosition, o MySQL se mostrou superior na maioria dos testes • Verificadas anomalias no PostgreSQL e MySQL

  38. Trabalhos Futuros • Poleposition: circuito Interlagos • Melhor implementação dos benchmarks • Mais tuning • Utilizar um ambiente com 2 ou 3 camadas • Utilizar servidores mais poderosos • Testar outros filesystems • Testar outros SGBD • Usar distro da Itautec: Librix Server

  39. Agradecimentos especiais • Peter Zaitsev, Senior Support Engineer, Lead of Performance Group • Josh Berkus, Lead Developer • Mark Wong • Isabel Cristina Lopes, Maria Antonieta Lucianetti, Edmundo Dotta, Attila Nagy, Ébion Miranda

  40. Maio/2006 Análise comparativa de desempenho entre MySQL e PostgreSQL Fábio Ávila avila@itautec.cin.ufpe.br http://itautec.cin.ufpe.br/

  41. Referências Bibliográficas • Gray, J. Benchmark Handbook: For Database and Transaction Processing Systems, Morgan Kaufmann Publishers Inc. San Francisco, CA, USA, 1992. • OSDL Database Test 2 (DBT-2TM) http://www.osdl.org/lab_activities/kernel_testing/osdl_database_test_suite/osdl_dbt-2/ • OSDL Database Test Suite http://www.osdl.org/ • Sourceforce, 2006, "The Open Source Database Benchmark" - http://osdb.sourceforge.net/ • PolePosition – The Open Source Database Benchmarkhttp://www.polepos.org/

  42. Referências Bibliográficas • Itautec S/A http://www.itautec.com • Fedora Project http://www.fedora.redhat.com • PostgreSQL http://www.postgresql.org • Zaitsev, P., Asplund T. Advanced Innodb Optimization, MySQL Users Conference 2005. http://www.mysqluc.com • Power PostgreSQL http://www.powerpostgresql.com/

More Related