Arquivos no banco o que fazer?

Diogo Biazus <diogob em gmail.com>

Arquivos no banco o que fazer?

Arquivos podem fazer parte de um modelo de banco de dados. No entre em pnico. Temos opes:

Bytea LO Sistema de arquivos

As opes do PostgreSQL

Bytea:

Campo normal, array de bytes com tamanho varivel. Armazena na tabela apenas um OID. Usa a pg_largeobject para armazenar o arquivo em vrias linhas com bytea. Gravamos apenas o caminho no sistema de arquivos.

LO (Large Object):

Sistema de arquivos:

Critrios para seleo (ou: no deixe a sorte escolher)

Pense um pouco, o que voc quer?

Compatibilidade com cliente. Facilidade de gerenciamento. Segurana. Escala. Performance.

Compatibilidade com cliente

Bytea:

Total, um campo como qualquer um. S precisamos usar a codificao do bytea. INSERT INTO tabela VALUES ('arquivo com byte zero (\000) no conteudo');

Compatibilidade com cliente

LO:

Muitos: npgsql, PyGreS, JDBC, PDO, ... Mas nem todos: psycopg2. Usamos chamadas especiais:

lo_create lo_write lo_read

Compatibilidade com cliente

Sistema de arquivos

Nenhum (se virem programadores) NFS, SMB, HTTP existem para isso. + trabalhoso.

At agora ...

Bytea 2 x LO 1 x SA 0

Facilidade de gerenciamento

Bytea

Muito fcil. Na verdade exatamente igual a qualquer outro campo. Apenas cria um certo desconforto ao usar o SELECT * ..., cuidado com consultas desse tipo. Integridade e backup no precisam de nenhum cuidado extra.

Facilidade de gerenciamento

LO

Fcil. Backup e no precisa de cuidados extra. Integridade pode gerar orfos. Cuidados especiais:

DELETE e DROP podem criar LOs orfos. Use gatilhos com lo_unlink. Em ltimo caso DELETE FROM pg_largeobject ...

Facilidade de gerenciamento

Sistema de arquivos

Nem um pouco fcil. Backup precisa de rotina para buscar arquivos e salvar uma cpia. Integridade no existe, precisamos implementar gatilhos para tudo. DELETE e DROP no liberam espao sem um gatilho.

Bytea continua na frente

Bytea 4 x LO 2 x SA 0

Segurana

Bytea e LO

Aproveita todos os mecanismos do banco de restrio de acesso. Dificulta a implementao de restries de acesso, pois passa a ser responsabilidade do desenvolvedor cuidar das permisses no SA.

Sistema de arquivos

Escala

Muito bonito, mas ser que agenta o tranco?

Escala

Bytea

Limite de 1 GB por arquivo. Operaes s gravam ou lem arquivos inteiros. SELECT * um desastre. Consome bastante memria no cliente. No bom para arquivos muito grandes.

Escala

LO

Limite de 2 GB por arquivo. Operaes so orientadas a fluxo de dados. timo para arquivos muito grandes.

Escala

Sistema de arquivos

Limitao de tamanho depende do sistema de arquivos subjacente, mas muito superior aos outros. Operaes podem ser feitas diretamente sobre o arquivo. timo para arquivos muito grandes.

Os adversrios se recuperam

Bytea 4 x LO 3 x SA 2

Performance

Ambiente de testes

Cliente (Core 2 Duo, 1 GB RAM, SATA 2) Servidor (Pentium D, 1GB RAM, SATA 2) SO Ubuntu 7.10 Sistema de arquivos: ext3 Sistema de arquivos distribudo: NFS Rede 100 Mbps

Performance

postgresql.conf

shared_buffers = 300MB work_mem = 10MB max_fsm_pages = 204800 wal_buffers = 512kB checkpoint_segments = 13 checkpoint_timeout = 35min effective_cache_size = 400MB

Performance

Testes:

Insero Insero com INSERT de 1.1 GB em aprox. 2700 arquivos. Consulta 20 execues de SELECTs com ORDER BY random() e LIMIT 50 em 10 clientes concorrentes. Copiando um total de aprox. 700 MB do servidor. Excluso Excluso de todos arquivos do banco (considerando o unlink para LO e rm para o SA). Arquivos variando de poucos KB at 30 MB.

Performance
Insero Bytea LO Sistema de arquivos Consulta Excluso 00:01:56 00:02:17 00:00:34

00:24:10 00:31:50 00:05:16 00:03:38 00:02:29 00:05:24

Performance

Bytea

Muita carga na mquina do cliente. Load no cliente chegou a 24 na consulta. Uso de memria e CPU altos no cliente. Servidor ocioso durante todos os testes exceto o de excluso, mas com grande consumo de memria.

Performance

LO

Consumo de recursos muito inferior no cliente. Usa mais recursos de CPU no servidor. Mesmo assim o servidor continuou ocioso na insero. Carga do servidor chegou a 4 nas consultas.

Performance

Sistema de arquivos

Baixo consumo de recursos no cliente. Trabalho sujo feito pelo sistema NFS. Baixo uso de CPU. Servidor ocioso na insero. Carga chegou a 3 nas consultas.

E finalmente o vencedor ...

Considerando todos os aspectos, a resposta que todos aguardam ...

Temos um empate senhoras e senhores

Quase enganei vocs, como sempre a resposta certa em TI : depende.

Isso eu j sabia

Algum pode perguntar:

Se para ver essa concluso porque assistimos essa palestra? importante conhecer bem as opes e saber quando e onde cada uma pode ser a estratgia vencedora!

Eu responderia:

Consideraes finais

Voc quer armazenar a foto do cliente?

Considere usar o tipo bytea.

Ou talvez grandes conjuntos de udio compactado?

LO pode ser mais adequado. Sistema de arquivos o caminho.

Arquivos com mais de 2 GB?

The End

Muito Obrigado!