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