Os testes foram executados em uma instância AWS db.t4g.micro (2 vCPU ARM Graviton, 1 GB RAM) com SSD GP2, utilizando commits em lote de 10.000 registros. O principal indicador é o tempo total de inserção (em segundos).
Observações:
MariaDB apresentou a melhor escalabilidade.
MySQL também escalou linearmente, porém cerca de 75% mais lento.
PostgreSQL manteve crescimento linear, mas com latência muito superior.
DynamoDB teve comportamento consistente, porém limitado pela capacidade de gravação.
Ganho relativo entre os bancos
Considerando o teste de 1 milhão de registros:
Quanto maior a barra, maior o aproveitamento da infraestrutura.
Interpretação técnica
1. MariaDB (PyMySQL) — Melhor desempenho
Tempo: 22,64 s
Motivos prováveis:
Engine InnoDB muito eficiente para cargas de escrita em lote.
Commit a cada 10.000 registros reduz drasticamente o custo de sincronização em disco.
Menor overhead de protocolo em relação ao PostgreSQL.
Excelente aproveitamento da memória limitada (1 GB).
Conclusão: melhor opção para workloads de ETL, IoT e importação massiva.
2. MySQL (PyMySQL)
Tempo: 39,72 s
Embora utilize praticamente a mesma arquitetura do MariaDB, ficou cerca de 1,75× mais lento.
Possíveis causas:
Diferenças de otimização entre versões do MySQL e MariaDB.
Configuração padrão do RDS (flush, buffer pool e parâmetros de redo log).
Implementação do driver PyMySQL.
Ainda assim, o desempenho é muito bom para aplicações transacionais.
3. PostgreSQL (psycopg2)
Tempo: 2.307 s (38,5 minutos)
O resultado é bastante inferior.
Tecnicamente, isso pode ocorrer devido a:
WAL (Write Ahead Log) gerando maior volume de escrita.
Sincronização (
fsync) a cada commit.Checkpoints frequentes em instância com apenas 1 GB RAM.
Inserções individuais em vez de
COPY,execute_valuesouCOPY FROM.
Importante: esse resultado não significa que PostgreSQL seja lento. Ele indica que o método de inserção utilizado não foi o mais eficiente para esse banco.
Com COPY, o desempenho normalmente aumenta em dezenas de vezes.
4. DynamoDB
O comportamento foi curioso.
Método | 1 milhão |
|---|---|
Padrão | 1224 s |
Otimizado | 1254 s |
O modo “otimizado para gravação (40.000)” praticamente não trouxe ganho.
Isso sugere que o gargalo não estava na capacidade provisionada, mas em outro fator, como:
Latência de rede.
BatchWriteItem limitado a 25 itens.
Overhead do cliente Python.
Particionamento (hot partition).
Considerações sobre a infraestrutura
Instância utilizada
Recurso | Valor |
|---|---|
Tipo | db.t4g.micro |
vCPU | 2 |
RAM | 1 GB |
Armazenamento | GP2 SSD |
Essa é uma instância de entrada. Mesmo assim, MariaDB ultrapassou 44 mil inserções por segundo, demonstrando que o gargalo não foi o SSD GP2, mas principalmente o mecanismo de persistência de cada banco.
Conclusão
Melhor desempenho: MariaDB
22,64 s para 1 milhão de registros, cerca de 44 mil registros/s.
MySQL foi competitivo
Entregou cerca de 25 mil registros/s, suficiente para muitas aplicações OLTP.
Para cargas massivas, o correto seria testar COPY FROM ou execute_values; o método atual penaliza fortemente o banco.
DynamoDB não é indicado para carga massiva sequencial
Ele é excelente para baixa latência e escalabilidade distribuída, mas não para importar milhões de registros via cliente Python nesse formato.
Nenhum comentário:
Postar um comentário