DB em container degrada o desempenho?

Saudações galera.

indo direto ao assunto:

Rodar a engine do DB dentro de um container docker causaria alguma degradação de desempenho (por menor que seja) em comparação a executar o DB direto no sistema host?

me veio essa dúvida após pesquisar sobre formas de tuning de DB (especificamente pro PostgreSQL)

estou fazendo uma migração de banco e o PostgreSQL foi selecionado pra isso.

Eu sou fã do docker e toda a aplicação que estou trabalhando esta rodando em containers e services docker, então, nada mais lógico do que rodar o DB também em docker (obviamente fazendo os binds dos dados pra um diretório no sistema host)

o caso de uso em questão não é pra uma aplicação pequena.

o foco aqui é ter um banco que vai suportar milhões de inserções por dia (e armazenar algumas dezenas de bilhões de registros) já que a aplicação em questão tem milhares de usuários e gera milhões de dados diariamente.

então qualquer degradação minima de desempenho pode ser problemática.

pesquisei a respeito disso e as respostas foram bem mistas quanto ao grau de perda de desempenho por se rodar a engine do DB em um container.

a ideia principal de quem critica containers pra DB é que o orquestrador de containers é uma camada de software extra entre o host e o DB, então teoricamente poderia ser um gargalo em altas cargas.

fico pensando se é muita neura minha ou se tem algum fundo de verdade.

algum expert em docker e DBs poderia sanar essa minha dúvida? 😅

ps: fiz toda a implementação do PostgreSQL com replicação Master-slave usando docker swarm, mas acabei nem colocando em produção por conta dessa dívida. Refiz no método tradicional kkkk

Oletroshá 2 meses

Meus 2 cents:

Sobre o artivo comparando PostgreSQL em docker e nativo (bypass paywall):

https://freedium.cfd/https://itnext.io/benchmark-postgresql-docker-versus-native-2dde6b5a8552

https://freedium.cfd/https://itnext.io/benchmark-databases-in-docker-mysql-postgresql-sql-server-7b129368eed7

So comentando, o que mais afeta entre nativo vs docker eh a parte de escrita - e depende muito da driver (metodo/vfs) de storage do docker.

Um docker nada mais eh que uma VM (no formato container) - e grosso modo roda na mesma velocidade da maquina host (ok, a limitacao aqui eh a quantidade de containers rodando simultaneamente).

Em Windows (WSL) e Mac esta diferenca eh maior - mas nativamente em Linux, de um modo geral pode rodar sem medo - se notar algum problema verifique especificamente a questao do vfs do docker (se overlay ou outro).

ethihá 2 meses
muito interessante o teste. confirmou oque eu suspeitava. o banco que tô modelando precisa "tankar" entre 300 a 400 milhões de inserts por dia (durante a semana) então usar em docker pode afetar um pouco esse desempenho de escrita. uma pena kkkk gosto muito de docker e fazer a implementação de replicação com compose foi muito mais fácil do que nativo. vlw pela resposta 🤝
Oletroshá 2 meses
Meus 2 cents extendidos: So comentando, tive um associado que teve uma necessidade semelhante (cerca de 25 milhoes de inserts/hora - uns 7k por segundo) em uma PoC de IoT - entao nao tinha grana para muito investimento em infra. A saida foi usar REDIS para a recepcao dos dados (chegando em multiplas filas MQTT e REST) com o load balance escalavel na horizontal (multiplas instancias REDIS) - liberava a conexao TCP do IoT, permitindo o fluxo continuo da telemetria. Os dados do REDIS eram persistidos em um PostgreSQL - como a conexao IoT ja tinha sido liberada (que afinal era a grande preocupacao - nao causar gargalo na recepcao dos dados e ao mesmo tempo otimizar o uso de banda/link), nao tinha problema certa latencia na escrita. Existia certo nivel de risco de perda de dados caso uma das instancias REDIS congelasse antes da escrita no banco final - mas dentro do esperado para a PoC, era aceitavel. No final das contas ficou absurdamente barato pela quantidade de dados tratados.
ethihá 2 meses
fiz algo semelhante aqui na empresa onde estou. a ingestão de dados é alta e o db não tava dando conta. então implementei o apache kafka pra receber todo esse volume de dados e depois alguns consumidores irem lendo do kafka e inserindo no db. tentei usar o bullmq pra isso, mas o redis não deu conta kkkk mas o kafka tirou de letra sem dor de cabeça.
Oletroshá 2 meses
Meus 2 cents extendidos: Pois eh, as vezes o BD por mais tunning que se faca nao rola - no caso o BD ficava numa storage com HA e via fiber channel, nao tinha jeito (ok, talvez tivesse, mas estava ficando caro brincar com as configuracoes). No final o load balance abrindo novas instancias de REDIS conforme a necessidade foi mais simples e barato. Nao chegamos a tentar o KAFKA - mas fica o registro para uma necessidade posterior.
digodkhá 2 meses

"nada mais lógico do que rodar o DB também em docker" Discordo desse ponto. Banco não é aplicação e as considerações de engenharia para os critérios de um banco são diferentes de uma aplicação comum, como um serviço de api. você está adicionando camadas de abstração de um componente crítico, latência de I/O e tornando o processo de backup mais complexo e menos alinhado com as práticas de mercado. em ambientes de dev/homolog ou um banco de baixa criticidade/volume, tudo certo, mas eu não confiaria na filosofia stateless do docker para rodar um componente stateful crítico para a minha operação.

kalibrado94há 2 meses
PostgreSQL em contêiner: é uma boa ideia? Impacto do Docker: A sobrecarga é mínima, mas sob alta carga pode ser um problema. Armazenamento (I/O): Sempre use um volume local (-v), senão o desempenho pode cair, especialmente com armazenamento em rede. Recursos: É essencial configurar limites de CPU/RAM (--memory, --cpus, ulimit), senão o PostgreSQL pode sofrer. Latência de rede: Se estiver em um cluster (Swarm/K8s), a rede overlay pode atrasar as consultas. Alta carga: Para milhões de inserções por dia, é melhor instalar o PostgreSQL diretamente no host. Alternativas: Se quiser escalar facilmente, considere bancos de dados gerenciados (RDS, Cloud SQL) ou Vitess. Para uso comum, PostgreSQL em contêiner funciona bem. Mas sob carga extrema, o melhor é rodar de forma nativa.
clacerdahá 2 meses

Tem um fundo de verdade. Sim existe um overhead, mas na maioria dos casos a diferença é insignificante. É fácil medir...

eliaseashá 2 meses

Dá uma olhada nesse artigo:

https://itnext.io/benchmark-postgresql-docker-versus-native-2dde6b5a8552

DevLucasMoraeshá 2 meses

Cara, aconselho ver a saga da rinha de backend do fabio akita, https://www.youtube.com/watch?v=-yGHG3pnHLg, tem uma parte que ele fala que o driver escolhido no docker pode afetar muito a perfomance

littleoakhá 2 meses

Deixe-me fazer um comentário com base no sre que levou todo exército brasileiro à cloud, NUNCA (ainda que em pods stateful em k8s) use db em container para produção, NUNCA!!! Para estudos, dev e etc, nice!