A utilização de gzip consome*muita* CPU e, num servidor ocupado, pode
>manter um dos núcleos a 100% o tempo todo.
>Em caso de restauração de urgência, descompactar os arquivos é também um
>custo a considerar, o que pode tornar a restauração mais lenta.
>
O tempo todo? Que tipo de ambiente está considerando? Em ambientes de
alta performance é bastante comum ter máquinas com +100 cores; utilizar
apenas um desses para arquivar não é algo que vá custar tanto assim.
Como eu disse, cada um com seus casos de uso.
É tão comum ter máquinas de 100+ núcleos em produção como é comum também
ter uma dessas máquinas virtualizando uma centena e cada uma dessas com
dois ou quatro "núcleos virtuais". Não é legal ter um desses núcleos a
100% na hora de uma operação em massa que não acontece o tempo todo, mas
na hora que acontece, prejudica outras consultas não custosas.
Enfim, a moda da virtualização tem seus prós e contras. Eu vejo um
milhão de contras e alguns poucos prós. Infelizmente, não dá pra remar
contra a maré (o tempo todo), principalmente em épocas de buzz words
ferozes e essa tal de nuvem (negra) que chegou para ficar.
Quanto a restauração, o gzip tem uma descompactação rápida além de um
baixo uso de memória para operação. Além disso, na maior parte do tempo,
o postgres ficará escrevendo randomicamente nos datafiles do que
descompactando arquivos de log de transação.
Os parágrafos que escrevi acima se aplicam aqui.
Se mesmo assim você estiver preocupado com velocidade da operação de
compactação/descompactação utilize o pigz ou as novas tendências (lz4 e
snappy).
Reafirmo que disco sata é barato pra fazer arquivamento de log de
transação. Comprimir depois, pra jogar em fita, na minha visão, é uma
boa estratégia em ambiente de produção.
[]s
Flavio Gurgel
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
