Executando verificação de segurança...
Em resposta a DB em container degrada o desempenho?
5
Oletros

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).

Carregando publicação patrocinada...
1
ethi

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 🤝

2
Oletros
Autor
Autor

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.

1
ethi

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.

2
Oletros
Autor
Autor

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.