DEV Community

Williane Felix
Williane Felix

Posted on

MySQL vs MongoDB vs Redis: Um Estudo de Performance e Carga em Aplicações Web

#redis #performance #mysql #mongodb

O Dilema da Persistência e Latência

No desenvolvimento moderno, a escolha do banco de dados não é mais uma decisão binária entre SQL e NoSQL. O desafio real de engenharia é equilibrar consistência, escalabilidade e latência.

Este estudo nasceu do projeto willyfelix/todolist-db-comparison, onde submeti uma aplicação de Todo List a testes de estresse. O objetivo? Analisar como o MySQL (integridade referencial), o MongoDB (flexibilidade documental) e o Redis (velocidade em memória) se comportam sob carga extrema.

A Aplicação: Todo List

A aplicação consiste em uma API REST desenvolvida em Python/Flask. Foram criadas duas versões idênticas: uma sobre MySQL e outra sobre MongoDB, garantindo que as métricas reflitam o banco de dados e não a lógica de negócio.

Por que uma Todo List?

É um domínio universal que permite medir o impacto real do CRUD sem complexidade adicional:

  • Relacional (MySQL): Testa conexões entre usuários e tarefas.
  • NoSQL (MongoDB): Testa a performance de objetos aninhados.
  • Cache (Redis): Avalia o ganho em cenários de leitura intensiva.

Arquitetura e Implementação

MySQL - Abordagem Relacional

Uso de schema fixo e tipado com índices estratégicos para otimização de busca.

CREATE TABLE todos (
    id INT PRIMARY KEY AUTO_INCREMENT,
    titulo VARCHAR(255) NOT NULL,
    concluida BOOLEAN DEFAULT FALSE,
    data_criacao TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    INDEX idx_concluida (concluida)
);
Enter fullscreen mode Exit fullscreen mode

MongoDB - Abordagem NoSQL

Documentos BSON flexíveis que favorecem a escrita rápida e escalabilidade horizontal.

{
  "_id": ObjectId("..."),
  "titulo": "Título da tarefa",
  "concluida": false,
  "data_criacao": ISODate("...")
}
Enter fullscreen mode Exit fullscreen mode

Redis - O Poder da Memória

Implementamos três estratégias clássicas de cache para observar os trade-offs de cada uma:

  • Cache-Aside (Lazy Loading): O dado é carregado no cache apenas sob demanda.
  • Write-Through: Escrita simultânea no banco e no cache.
  • Write-Behind: Foco total em performance; escreve no cache primeiro e no banco de forma assíncrona.

Resultados e Benchmarks

Testes realizados em ambiente local.

1. Inserção de Dados (Bulk Insert)

Volume MySQL MongoDB MySQL + Redis MongoDB + Redis
10k 34.247 51.370 125.800 128.400
100k 41.025 61.537 155.900 158.700

Análise: O MongoDB superou o MySQL em 58% na escrita nativa devido ao modelo de documentos desnormalizados. Com Redis, o throughput saltou para 150k reg/s, provando que a RAM elimina o gargalo de I/O de disco.

2. Operações de Leitura (GET)

Métrica MySQL MongoDB Redis (Híbrido)
Tempo Médio 2550.1ms 185.4ms 1.1ms
Throughput 3.91 req/s 5.39 req/s 925.9 req/s

Análise: O Redis reduziu a latência em mais de 2000 vezes comparado ao MySQL sob carga. O teste confirma que, para leituras repetitivas, a persistência em disco não consegue competir com a velocidade sub-milissegundo da memória.

3. Operações de Escrita (POST)

Métrica MySQL MongoDB Redis (Híbrido)
Tempo Médio 2385.8ms 412.3ms 15.2ms
Throughput 4.18 req/s 24.2 req/s 657.8 req/s

Análise: O MongoDB foi 6x mais rápido que o MySQL em escritas puras, mas a arquitetura híbrida com Redis dominou com 657 req/s. Delegar a confirmação de escrita para o cache desafoga o banco principal e escala a aplicação.

4. Atualização (PUT)

Métrica MySQL MongoDB Redis (Híbrido)
Tempo Médio 2476.2ms 435.1ms 16.4ms
Throughput 4.04 req/s 22.9 req/s 607.9 req/s

Análise: O combo MongoDB + Redis manteve a liderança com 16ms de resposta média. O desafio aqui reside na coerência: o cache garante velocidade, mas exige estratégias como Write-Through para sincronizar o dado no banco persistente.

5. Deleção (DELETE)

Métrica MySQL MongoDB Redis (Híbrido)
Tempo Médio 2514.7ms 398.1ms 13.8ms
Throughput 3.97 req/s 2.51 req/s 72.4 req/s

Análise: O MySQL mostrou-se ligeiramente mais estável que o MongoDB puro em deleções massivas. No entanto, o Redis padronizou a performance para 13ms, garantindo que o usuário perceba a remoção de forma instantânea.

Análise Comparativa

MySQL: O Porto Seguro

  • Vantagem: Consistência ACID e integridade referencial absoluta.
  • Gargalo: O custo do disco e os locks de linha tornam a latência alta sob estresse.

MongoDB: O Atleta de Performance

  • Vantagem: Escrita até 6x mais rápida que o SQL e esquema flexível.
  • Gargalo: Consumo de RAM elevado para manter índices e working set.

Redis: O Motor de Fórmula 1

  • Vantagem: Reduziu a latência em 2000x. Essencial para evitar que o banco principal sofra com picos de tráfego.

Principais Aprendizados

  1. Latência é o Gargalo Silencioso: O I/O de disco é o maior inimigo da escala. O Redis provou que a RAM é o divisor de águas.
  2. Trade-off de Rigidez: O MySQL garante dados limpos, mas o MongoDB entrega agilidade. A escolha depende da prioridade do projeto.
  3. Cache exige Estratégia: Não basta "instalar". Escolher entre Cache-Aside ou Write-Through define se seu usuário verá dados obsoletos ou não.

Recomendação Final

Se você está construindo uma aplicação que pretende crescer, minha recomendação baseada nos dados é: não escolha apenas um. Este conceito de combinar diferentes tecnologias é o que a literatura técnica chama de Persistência Poliglota. Segundo Martins et al. (2024), essa abordagem é fundamental para superar as limitações de modelos únicos em cenários de alta demanda.

Para um sistema de tarefas ou similar:

Use MongoDB ou MySQL como sua "Fonte da Verdade" (Single Source of Truth), onde os dados residem com segurança.

Implemente Redis obrigatoriamente para as rotas de GET, utilizando a estratégia de Cache-Aside com um TTL (Time to Live) curto (ex: 5 a 10 minutos). Isso reduzirá a carga no seu banco principal em até 90%, permitindo que você rode em servidores mais baratos e ofereça uma interface instantânea para o usuário final.

Recursos e Referências

Top comments (1)

Collapse
 
paulojr_r profile image
Paulo Junior •

Ficou massa 👏🏾