Vocês estão salvando o que em json para ter 120m de caracteres kkk e quando tempo leva para essa API responder com um retorno de 30MB.

E sim é recomedado guardar dados binarios em um cloud e não diretamente na consulta. Depois que guardar em um cloud, ai sim usar o arquivo, retornando do banco de dados a URL onde está hospedado o arquivo

blankhá 2 anos

Amigo... nem eu sei.. essa porra não abre... kkkkkkkkkkkkkkkkkkkkkkkk.. se da um select pelo dbeaver o java crasha com estouro de buffer do java. Se o usuário do sistema tenta vizualizar na web, o navegador trava... kkk... pra eu ver isso tive que abrir no python pra ver um trecho do arquivo.

Sobre o tempo da API... começa com no minimo 15 segundos.

pela sua resposta sobre a recomendação de se armazenar os binários fora da consulta, consegue pensar em um exemplo onde armazenar o binário no bd seria uma vantagem?

Obrigado pela sua resposta.

klawdyohá 2 anos
Nunca ouvi falar em nenhuma vantagem em colocar binário no banco. Salvar dados em json já é outra coisa. O PostgreSQl tem suporte a isso. Eu uso para, por exemplo, gerar o histórico de um pedido. O endereço do cliente existe lá na tabela de endereços mas eu coloco um json com a mesma informação na tabela de pedido pra manter o dado intacto mesmo que o usuário altere o endereço. Só para informações que não serão usadas para buscar, apenas para manter a informação já processada.
saulobborgeshá 2 anos

Json não é necessariamente um dado binário, é uma string, padronizada para organização de dados de maneira estruturada.

Acho que a discussão aqui não chegará a lugar algum, pois o que temos é um cenário onde nem mesmo ler os dados o amigo acima conseguiu, sem sabermos o que é armazenado dessa não podemos sugerir solução A ou B.

Talvez o foco seja encontrar uma forma de ler o conteúdo, uma delas seria, aí sim, gerar um arquivo por meio de um dump apenas da tabela onde esse json's são aramzenados.

pg_dump -U <usuario> –inserts -t <tabela> <banco> > dump.sql