PostgreSQL oferece uma interface BLOB agradável que é amplamente utilizado. No entanto, recentemente nos deparamos com problemas enfrentados por vários clientes, e faz sentido refletir um pouco e descobrir como o PostgreSQL lida com BLOBs – e especialmente com a limpeza de BLOB.

usando a interface Blob PostgreSQL

no PostgreSQL, você pode usar vários meios para armazenar dados binários. A forma mais simples é definitivamente fazer uso do tipo de dados” bytea ” (=byte array). Nesse caso, um campo binário é basicamente visto como parte de uma linha.
aqui está como funciona:

como você pode ver, esta é uma coluna normal e pode ser usada como uma coluna normal. A única coisa que vale a pena mencionar é a codificação que deve ser usada no nível SQL. O PostgreSQL usa uma variável para configurar esse comportamento:

test=# SHOW bytea_output;bytea_output--------------hex(1 row)

a variável bytea_output aceita dois valores: “hex” diz ao PostgreSQL para enviar os dados no formato hex. “escape” significa que os dados devem ser alimentados como uma string octal. Não há muito o aplicativo tem que se preocupar aqui, além do tamanho máximo de 1 GB por campo.
no entanto, o PostgreSQL tem uma segunda interface para lidar com dados binários: a interface BLOB. Deixe-me mostrar um exemplo dessa poderosa ferramenta em ação:

test=# SELECT lo_import('/etc/hosts');lo_import-----------80343(1 row)

nesse caso, o conteúdo de /etc/hosts foi importado para o banco de dados. Observe que o PostgreSQL tem uma cópia dos dados – não é um link para o sistema de arquivos. O que é digno de nota aqui é que o banco de dados retornará Oid (object ID) da nova entrada. Para acompanhar esses OIDs, alguns desenvolvedores fazem o seguinte:

INSERT 0 1

isso é absolutamente bom, a menos que você faça algo como abaixo:

test=# DELETE FROM t_file WHERE id = 1;DELETE 1

o problema é que o ID do objeto foi esquecido. No entanto, o objeto ainda está lá. pg_largeobject é a tabela do sistema responsável por armazenar os dados binários dentro do PostgreSQL. Todos os lo_functions simplesmente falarão com esta tabela do sistema para lidar com thesethings:

por que isso é um problema? O motivo é simples: seu banco de dados crescerá e o número de “objetos mortos” se acumulará. Portanto, a maneira correta de matar uma entrada BLOB é a seguinte:

se você esquecer de desvincular o objeto, sofrerá a longo prazo-e muitas vezes vimos isso acontecer. É um grande problema se você estiver usando a interface BLOB.

vacuumlo: limpando objetos grandes mortos

no entanto, como alguém pode corrigir o problema depois de acumular milhares, ou talvez milhões, de bolhas mortas? A resposta é uma ferramenta de linha de comando chamada “vacuumlo”.
Vamos primeiro criar uma mortos entrada:

test=# SELECT lo_import('/etc/hosts');lo_import-----------80351(1 row)

Então podemos executar vacuumlo a partir de qualquer cliente:

Como você pode ver, dois objetos mortos foram mortos pela ferramenta. vacuumlo é a maneira mais fácil de limpar objetos órfãos.

funcionalidade adicional

no entanto, há mais do que apenas lo_import e lo_unlink. O PostgreSQL oferece uma variedade de funções para manipular objetos grandes de uma maneira agradável:

Há mais duas funções que não seguem a convenção de nomenclatura por razões históricas: loread e lowrite:

pg_catalog | loread | bytea | integer, integer | funcpg_catalog | lowrite | integer | integer, bytea | func

Eles são funções cujos nomes não pode ser mais alterado. No entanto, vale a pena notar que eles existem.

finalmente …

a interface Blob do PostgreSQL é realmente útil e pode ser usada para muitas coisas. A beleza é que ele é totalmente transacional e, portanto, o conteúdo binário e os metadados não podem mais sair de sincronia.

se você quiser saber mais sobre gatilhos para impor restrições no PostgreSQL, recomendamos que você confira nossa postagem no blog escrita por Laurenz Albe. Ele vai lançar alguma luz sobre este tema importante.

Deixe uma resposta

O seu endereço de email não será publicado.