Executando verificação de segurança...
Respondendo a "muito interessante o teste. confirmou oque eu s..." dentro da publicação DB em container degrada o desempenho?
2
Oletros

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.

Carregando publicação patrocinada...
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.