Análise comparativa de desempenho entre MySQL e PostgreSQL

Apresentação em tema: "Análise comparativa de desempenho entre MySQL e PostgreSQL"— Transcrição da apresentação:

1 Análise comparativa de desempenho entre MySQL e PostgreSQL
30/03/2017 Maio/2006 Análise comparativa de desempenho entre MySQL e PostgreSQL Fábio Ávila

2 Agenda Introdução Benchmarks utilizados Resultados
30/03/2017 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
30/03/2017 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 Objetivos Resultados
30/03/2017 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

5 Equipe TPC Carlos Eduardo Pires Rilson Nascimento Fábio Ávila
30/03/2017 Carlos Eduardo Pires Rilson Nascimento Fábio Ávila Francisco Carvalho Marcelo Rodrigues

6 Benchmarks Definição Características desejáveis
30/03/2017 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
30/03/2017 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)
30/03/2017 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)
30/03/2017 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
30/03/2017 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
30/03/2017 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 C 1 Switch 1Gbps

12 Software Utilizado 30/03/2017 Linux Fedora Core 4, Kernel _FC4smp, filesystem ext3 PostgreSQL on i686-pc-linux-gnu, compiled by GCC gcc (GCC) (Red Hat ) MySQL beta-standard-log dbt2-0.37, Novembro de 2005

13 DBT-2 e OSDB: Console VNC PolePosition: Gerador de Carga
Ambiente de Teste 30/03/2017 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
30/03/2017 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
30/03/2017 Warehouse W 10 District W * 10 History W * 30k+ 100k 3k 1+ Stock W * 100k Customer W * 30k New-Order W * 9k+ 0-1 1+ W 3+ Item 100k Order-Line W * 300k+ Orders W * 30k+ 5-15

16 Exemplo: PostgreSQL, 115w Total (incluindo índices): 11.7 GB Warehouse
30/03/2017 Warehouse (115) 24 KB District (1.150) 184 KB History ( ) 290 MB Stock ( ) 3.8 GB Customer ( ) 2.2 GB New-Order ( ) 40 MB Item ( ) 10.8 MB Order-Line ( ) 3 GB Orders ( ) 221 MB Total (incluindo índices): 11.7 GB

17 Transações do DBT-2 Escrita e leitura Consulta New-Order Payment
30/03/2017 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
30/03/2017 Payment 43% Order-Status 4% Delivery 4% Stock Level 4% New-Order ≡ 45% (restante)

19 Métricas NOTPM Regra de escalabilidade do TPC-C
30/03/2017 NOTPM Número de Transações New-Order por minuto Regra de escalabilidade do TPC-C 1 warehouse  10 usuários Exemplo para 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
30/03/2017 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 Tuning – DBT-2 PostgreSQL 8.1.3 (postgresql.conf) fsync = off [on]
30/03/2017 PostgreSQL (postgresql.conf) fsync = off [on] shared_buffers = (156 MB) [1.000] checkpoint_segments = 256 [6] checkpoint_timeout = 1800 s [300] stats_* = off [on] work_mem = 1024K [512] MySQL 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] ================ PostgreSQL =========================================== shared_buffers: it is the block of dedicated memory PostgreSQL uses for active operations, and should be a minority of your total RAM on the machine, since PostgreSQL uses the OS disk cache as well. On dedicated servers, useful values seem to be between between 8MB and 400MB (between 1000 and 50,000 for 8K page size). Factors which raise the desired shared buffers are larger active portions of the database, large complex queries, large numbers of simultaneous queries, long-running procedures or transactions, more available RAM, and faster/more CPUs. And, of course, other applications on the machine. Contrary to some expectations, allocating much too much shared_buffers can actually lower peformance, due time required for scanning. work_mem: covers sorts, aggregates, and a few other operations. This is non-shared memory, which is allocated per-operation (one to several times per query); the setting is here to put a ceiling on the amount of RAM any single operation can grab before being forced to disk. This should be set according to a calculation based on dividing the available RAM (after applications and shared_buffers) by the expected maximum concurrent queries times the average number of memory-using operations per query. Consideration should also be paid to the amount of work_mem needed by each query; processing large data sets requires more. Web database applications generally set this quite low, as the number of connections is high but queries are simple; 512K to 2048K generally suffices. checkpoint_segments: defines the on-disk cache size of the transaction log for write operations. You can ignore this in mostly-read web database, but for transaction processing databases or reporting databases involving large data loads, raising it is performance-critical. Depening on the volume of data, raise it to between 12 and 256 segments, starting conservatively and raising it if you start to see warning messages in the log. The space required on disk is equal to (checkpoint_segments * 2 + 1) * 16MB, so make sure you have enough disk space (32 means over 1GB). max_connections: determines the maximum number of concurrent connections to the database server. fsync: If this option is on, the PostgreSQL server will try to make sure that updates are physically written to disk, by issuing fsync() system calls or various equivalent methods (see wal_sync_method). This ensures that the database cluster can recover to a consistent state after an operating system or hardware crash. However, using fsync results in a performance penalty: when a transaction is committed, PostgreSQL must wait for the operating system to flush the write-ahead log to disk. When fsync is disabled, the operating system is allowed to do its best in buffering, ordering, and delaying writes. This can result in significantly improved performance. However, if the system crashes, the results of the last few committed transactions may be lost in part or whole. In the worst case, unrecoverable data corruption may occur. (Crashes of the database software itself are not a risk factor here. Only an operating-system-level crash creates a risk of corruption.) Due to the risks involved, there is no universally correct setting for fsync. Some administrators always disable fsync, while others only turn it off during initial bulk data loads, where there is a clear restart point if something goes wrong. Others always leave fsync enabled. The default is to enable fsync, for maximum reliability. If you trust your operating system, your hardware, and your utility company (or your battery backup), you can consider disabling fsync. checkpoint_segments: maximum distance between automatic WAL checkpoints, in log file segments (each segment is normally 16 megabytes). The default is three. This option can only be set at server start or in the postgresql.conf file. checkpoint_timeout: maximum time between automatic WAL checkpoints, in seconds. The default is 300 seconds. effective_cache_size: tells the query planner the largest possible database object that could be expected to be cached. Generally should be set to about 2/3 of RAM, if on a dedicated server. This parameter has no effect on the size of shared memory allocated by PostgreSQL, nor does it reserve kernel disk cache; it is used only for estimation purposes. The value is measured in disk pages, which are normally 8192 bytes each. The default is 1000. ================ MySQL =========================================== innodb_buffer_pool_size = 1638M :: 80% da memória física (2 GB) innodb_log_file_size=1024M :: 25% do buffer pool size thread_concurrency = 8 :: thread concurrency do mysqld [#cpu*(2..4)] (default) Innodb_additional_mem_pool_size = 20M (default) :: caching internal structures innodb_flush_log_at_trx_commit=2 :: Comportamento do InnoDB log flush 0 :: No log flushing on transaction commit (se MySQL bugar, perda de transações) 2 :: (um pouco menos rápido do que 0) Log is not flushed to the disk but to the OS cache (se OS/HW bugar, há perda de transações) 1 :: (valor default do MySQL) fully ACID, log flushed to disk on commit innodb_lock_wait_timeout = 50 :: Timeout waiting for InnoDB row locks =================================================================

22 Número de Transações New-Order por Minuto (NOTPM)
30/03/2017 [08/05/2006 Rilson] Slide Atualizado

23 CPU 30/03/2017 Sendo este o melhor resultado de cada SGBD.
[08/05/2006 Rilson] Slide Atualizado Sendo este o melhor resultado de cada SGBD. O PostgreSQL fez melhor uso da CPU, pois gastou mais tempo com processos usuários (user) do que com o sistema (system) e espera com I/O (I/O wait). Uma observação importante é que o MySQL está esperando muito mais por I/O do que o PostgreSQL (25% contra 5%), o que reflete na diferença de tempo gasto com processos usuários (50% contra 75%). O Total (user+system+wait) foi praticamente perto de 100% para o PostgreSQL, por conta do seu baixo I/O Wait (espera por IO) e por conseguinte do tempo idle. Para o MySQL, o IO Wait 20% maior do que o PostgreSQL, causou um idle time maior e dessa forma um menor tempo Total gasto servindo.

24 Context Switches 30/03/2017

25 I/O 30/03/2017

26 Benchmark AS3AP Trabalho acadêmico Normalização Métrica
30/03/2017 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 Implementação do AS3AP
30/03/2017 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 Ideal: mínimo de 2GB Credibilidade
30/03/2017 Nossos testes Tamanho do banco: 1GB 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
30/03/2017 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% Categoria PostgreSQL MySQL Empate Criação e População de Tabelas 16 6 1 Testes mono-usuário 7 35 4 Testes multi-usuário 17

30 OSDB – Anomalias bulk_modify bulk_delete Bug, implementação ou tuning?
30/03/2017 bulk_modify update updates set key=key 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 34 minutos no PostgreSQL Bug, implementação ou tuning?

31 Benchmark PolePosition
30/03/2017 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
30/03/2017 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
30/03/2017 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: , , , Imola: , , , Sepang: 36, 55, 78, 105

34 Resultados PolePosition
30/03/2017 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% Circuito PostgreSQL MySQL Empate Barhain 16 11 3 Barcelona 7 12 1 Imola 4 Melbourne Sepang

35 PolePosition - Anomalias
30/03/2017 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, 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.
30/03/2017 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 foi equivalente
30/03/2017 No DBT-2, o desempenho foi equivalente 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 mostrou superior 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 [08/05/2006 Rilson] Slide Atualizado

38 Trabalhos Futuros Poleposition: circuito Interlagos
30/03/2017 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
30/03/2017 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 Análise comparativa de desempenho entre MySQL e PostgreSQL
30/03/2017 Maio/2006 Análise comparativa de desempenho entre MySQL e PostgreSQL Fábio Ávila

41 Referências Bibliográficas
30/03/2017 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) OSDL Database Test Suite Sourceforce, 2006, "The Open Source Database Benchmark" - PolePosition – The Open Source Database Benchmark

42 Referências Bibliográficas
30/03/2017 Itautec S/A Fedora Project PostgreSQL Zaitsev, P., Asplund T. Advanced Innodb Optimization, MySQL Users Conference 2005. Power PostgreSQL