Executando verificação de segurança...
2
valterpatrick
2 min de leitura ·

Salvar XML no banco de dados ou no storage

Estou desenvolvendo uma api para emissão de notas fiscais do meu sistema, nisto são gerados arquivos XML dos quais eu tenho de armazenar por um determinado período (até 5 anos) e retornar para o meu cliente também (tanto na requisição de emissão, quanto em outras requições especificas para retornar este arquivo).

Estou na dúvida:

  1. Salvar no banco de dados postgre onde eu armazeno os dados da aplicação, mas isto deixaria o banco de dados maior já que tem arquivos XML que podem variar de 1KB até centenas de KB, mas ficaria mais rápido para retornar os dados já que estão todos disponiveis no mesmo banco/tabela;
  2. Salvar no banco de dados mongodb (nosql) onde só teria arquivos XML. Nisto não aumentaria muito o banco de dados da aplicação, não atrapalharia o desempenho, eu poderia deixar o banco de dados mongodb em outra hospedagem;
  3. Salvar no storage, no caso salvar no AWS S3. Nisto não gastaria espaço da VPS, ou banco de dados, mas com o tempo ficaria mais caro, mesmo utilizando alguns recursos inteligentes da AWS para diminuir os custos;

Durante o processo de emissão de notas eu preciso gerar um arquivo XML assinado e salvar ele antes de enviar para a receita federal, no retorno eu recebo um XML que este sim devo salvar e o anterior posso excluir.
Tenho empresas que emitem 1 nota por mês, assim como tenho outras que emitem 30 mil notas no mês.
Tenho de pensar tanto no desempenho, quanto no custo.

O que me recomendam?

Carregando publicação patrocinada...
3
condEduardo

Eu salvaria em um Storage, pelo Workload que você falou dessa API, devo chutar que são emitidas entre 80.000 a 200.000 notas fiscais por mês no total, certo? começaria a pensar seriamente em Storages como S3, afinal você é um profissional desenvolvendo um produto sério, e se esse workload escalar para digamos 1, 2, 3 milhões de notas por mês como fica seu banco com esse amontoado de XML? eu ainda tentaria técnicas de Compressão.

1
valterpatrick
Autor
Autor

Tem razão.
Tem clientes pequenos que emitem 1 nota a cada 2, 3 meses, outros chegam a mais de 20mil em um mês.
Se for vê no geral, pode acontecer de chegar a 100 mil ou até 1 milhão de notas em um mês.
De fato será mais fácil escalar e pensar no processamento de forma geral trabalhando em um storage.
No próprio S3 tem algumas ferramentas automáticas para classificar os recursos e até mesmo posso colocar em uma classe que não é acessada com muita frequencia para diminuir o custo.

2
silvestrini

Não salve no banco, o melhor a se fazer é ter um storage que você possa cobrar do cliente o espaço, melhor ainda se você não precisar cobrar. Você poderia por exemplo fazer uma integração com s3, como citou, e salvar apenas algum token de acesso do cliente. Ele mesmo contrata e configura no sistema. Aí ele paga o quanto ele precisar. Já pensou se ele para de te pagar.. Vai ficar mantendo os dados dele lá na sua vps gastando espaço de graça?

1
1
dealmeida

boa noite, sr valter.

eu sugiro que o sr armazene em bucket/storage, configure uma forma de cobrar pelo bucket ou pela nota.
se pela nota, é pagamento único. se pelo bucket, vai ter prazo que vc pode negociar ou vai ter que obedecer ao mínimo imposto pela lei. leve isso em consideração.

execute técnica de compressão e não apresente isso na parte contratual pelo contratante/cliente do sr, pois eis que surge a margem de segurança para cados inesperados.
além disso, execute a compressão em client side. não execute em server side.
gzip, brotli, lzma, são boas libs que podem executar em client side. utilize web worker para manter paralelismo e não bloquear a thread principal.
para escolher a lib, vai ter elicitar teus requisitos: velocidade, streaming, capacidade de compressão, arquivos, grandes volumes, etc.
para texto, brotli (compressão máx 90%). para literalmente arquivos, lzma (máx 95%, com algumas ressalvas). para velocidade, gzip (máx 90%).
coloque uma assinatura e um salt, até mesmo encriptar com senha, talvez. fluxo: compress -> signature -> salt -> encrypt password.

se compartilhar os requisitos do sistema para a gente, poderei conversar melhor sobre o assunto.

0
-2
Multi

Minha sugestão é escolher o caminho que mais rápido para desenvolver. Põe no ar e começa a gerer receita para seu negócio.

Armazenar no banco é mais rápido para desenvolver, menos código. Mais fácil de gerenciar também a segurança dos dados. Porém gasta um pouco mais de processamento, mas nada de mais.

Dica importante, esquece cobrar por espaço em disco. Escolha cobrança por nota fiscal gerada.

1