Diferença de desempenho entre MySQL e PostgreSQL para o mesmo esquema / consultas [fechado]

Sou um DBA iniciante e tenho experiência no Microsoft SQL Server, mas quero pular para o FLOSS.

Estou iniciando uma empresa e desenvolvemos um aplicativo (PHP) com um back-end do Postgres, e também fizemos alguns testes comparando com o MySQL. Observamos que o MySQL é duas vezes mais rápido que o PostgreSQL.

Fiz um teste de desempenho tangível:

• Mesmas colunas na tabela com tipos de dados de coluna equivalentes.
• Mesmo número de linhas.
• Mesmos índices em ambos (chave primária incluída).
• A carga da CPU está ociosa e a máquina do Postgres é significativamente melhor.
• E a mesma consulta (obviamente).

O que estou fazendo errado?

PS: Eu li muitos "howtos" sobre ajuste de desempenho para mecanismos de banco de dados.
PS (2): Estamos usando o InnoDB (um arquivo por tabela) no banco de dados MySQL.

Oi Mat!

Fiz as três consultas comuns de seleção (e as mais difíceis).

A questão sobre disco, certamente não é a mesma; No Postgres, é um SSD (quase três vezes mais rápido).

Dados de cache do MySQL:

+------------------------------+----------------------+
| Variable_name                | Value                |
+------------------------------+----------------------+
| binlog_cache_size            | 32768                |
| have_query_cache             | YES                  |
| key_cache_age_threshold      | 300                  |
| key_cache_block_size         | 1024                 |
| key_cache_division_limit     | 100                  |
| max_binlog_cache_size        | 18446744073709547520 |
| query_cache_limit            | 1048576              |
| query_cache_min_res_unit     | 4096                 |
| query_cache_size             | 16777216             |
| query_cache_type             | ON                   |
| query_cache_wlock_invalidate | OFF                  |
| table_definition_cache       | 256                  |
| table_open_cache             | 64                   |
| thread_cache_size            | 8                    |
+------------------------------+----------------------+

Não sei como ver isso no PostgreSQL.

Desde já, obrigado.

MySQL e PostgreSQL são bastante diferentes em termos de desempenho. As tabelas InnoDB e PostgreSQL são otimizadas para diferentes tipos de consultas. Entender essas diferenças é importante para entender como obter um bom desempenho.

Como exemplo, vejamos a diferença mais óbvia.

Estrutura da tabela do PostgreSQL x MySQL / InnoDB e o que isso significa para desempenho

Em geral, em cargas de trabalho complexas, o PostgreSQL será mais rápido, mas em pesquisas simples de chave primária, o MySQL com InnoDB será mais rápido.

As tabelas do PostgreSQL são tabelas de heap. Não há opção para criar uma tabela que não seja uma tabela de heap. O clustercomando simplesmente reescreve a pilha ordenada por um índice especificado. Os índices fornecem locais de heap para tuplas com vários valores. Os índices não podem ser percorridos em ordem física, apenas ordem lógica, para que eles tenham muitas E / S aleatórias de disco durante a leitura de uma tabela em sequência, geralmente significa muita E / S de disco seqüencial, pois é possível ler uma tabela em ordem física. A E / S de disco seqüencial utiliza o cache de leitura antecipada e alguma outra otimização no nível do SO.

O que isso significa é que, se você precisar de uma parte significativa dos registros ou de algumas páginas, geralmente é mais rápido ler as páginas do disco. Por outro lado, uma pesquisa de chave primária para uma tabela exige que você acerte o índice, procure o local no arquivo, depois acerte a tabela de heap e puxe o registro. Isso significa várias partes de E / S de disco aleatório.

O InnoDB usa uma abordagem diferente. Com o InnoDB, a tabela é um índice de árvore b com os dados reais na carga útil do índice. Isso significa que uma pesquisa de chave primária já consegue extrair os dados da página folha e, portanto, menos E / S de disco aleatória é necessária para isso. Ao mesmo tempo, uma varredura de índice requer a passagem de dois índices em vez de um, o que significa que o uso de qualquer índice que não seja a chave primária acaba sendo mais lento e as varreduras seqüenciais ainda mais lentas.

Obtendo diagnósticos no PostgreSQL

Eu acho que você deseja usar algo como:

 EXPLAIN (analyse, buffers, verbose)
 [query];

Isso fornecerá o plano de consulta, estimativas iniciais, horários reais, uso de buffer e muito mais.