O que é uma latência / desempenho “normal” de inserções em mariadb ou mysql?

Question

Não usava a família MySQL há anos. Agora é necessário mover do OracleDB para o MariaDB ou PostgreSQL.

Portanto, em um "hardware" semelhante ( Openstack VM: RHEL 7.3 , 4HT cores of 2.5GHz Xeon E312xx , "local" SAN & SATA storage ) obteve Oracle11g e MariaDB10.3 lado a lado.

Criado um conjunto simples de tabelas de 10 colunas com chave primária numérica e sem índices / acionadores / etc. Um aplicativo de 1 conexão java (hibernate + jdbc) de 1 thread fazendo apenas 6 inserções em um loop (com commit a cada 100 ciclos).

Estou fazendo algo errado ou esperando demais o desempenho do MariaDB, mas no OracleDB essa rotina está recebendo 348ms / cycle (6 * 100 inserts + commit) no MariaDB, o mesmo leva 3291ms / cycle, em outras palavras, cerca de 10x mais lento que o OracleDB no mesmo hardware (tudo que eu estou trocando no aplicativo java é o dialeto de hibernação e a conexão url / user / pass). Eu verifiquei novamente usando o tcpdumps que o aplicativo está se comportando da mesma forma, é o tempo de resposta do DB que difere muito.

Dado o que eu vejo até agora - devo apenas diminuir as expectativas de desempenho do meu MariaDB ou devo continuar a investigar o IOwait-tracing ou o ajuste fino do MariaDB? Simplesmente não consegui encontrar uma referência em nenhum lugar do que seria um desempenho "normal" para o MariaDB (em algum hardware de referência) ... 5 + ms / insert parece "muito" ...

Atualização:

Encontrou um artigo :

showing their PrepareStatementBatch100InsertPrepareHit.mariadb
(doing 1000-inserts batch) completing in 5ms, so about 5 MICRO(!)-seconds per insert....
Seems our setup works about 1000x slower than expected...

Atualização 2

Movido para longe da VM Openstack para um equivalente bare-metal (todos os mesmos parâmetros, exceto pelo fato da CPU ser núcleos 4HT do Xeon E5450 @ 3GHz). Instalado o OracleDB e o MariaDB com configurações padrão, migrou os esquemas.

No bare-metal MariaDB, o "6 * 100 INSERTs + commit" levou 430ms / cycle, o que é totalmente comparável ao OracleDB (também totalmente bom no sentido de fazê-lo via jdbc / PreparedStatements sem qualquer lote - bastante aceitável). Mesmo com "6 * 100 DELETEs + commit" - 625ms / cycle. Agora o único problema restante que estou enfrentando é o SelectForUpdates / UPDATEs sendo lento ...

A seguinte mistura (o mesmo feito por aplicativo e, portanto, escolhido como micro-banco) desempenho no MariaDB:

• 13 SELECTs + 5 SFUs + 6 UPDATEs + commit = 252ms na configuração anterior da VM do Openstack
• 13 SELECTs + 5 SFUs + 6 UPDATEs + commit = 133ms na nova configuração bare-metal
• 13 SELECTs + 0 SFUs + 6 UPDATEs + commit = 122ms na nova configuração bare-metal
• 13 SELECTs + 5 SFUs + 0 UPDATEs + commit = 122ms na nova configuração bare-metal

para comparação, no OracleDB Openstack VM:

• 13 SELECTs + 5 SFUs + 6 UPDATEs + commit = 14ms

No momento - esgotou as otimizações óbvias / documentadas e tentou alguns testes contra-intuitivos, como desativar qualquer particionamento / indexes / foreign-keys / etc ...