PostgreSQL offre une interface BLOB agréable largement utilisée. Cependant, récemment, nous avons rencontré des problèmes rencontrés par divers clients, et il est logique de réfléchir un peu et de comprendre comment PostgreSQL gère les BLOBs – et en particulier le nettoyage des BLOBS.

En utilisant l’interface BLOB PostgreSQL

Dans PostgreSQL, vous pouvez utiliser différents moyens pour stocker des données binaires. La forme la plus simple consiste certainement à utiliser le type de données « bytea » (= tableau d’octets). Dans ce cas, un champ binaire est essentiellement considéré comme faisant partie d’une ligne.
Voici comment cela fonctionne:

Comme vous pouvez le voir, il s’agit d’une colonne normale et elle peut être utilisée comme une colonne normale. La seule chose qui mérite d’être mentionnée est l’encodage que l’on doit utiliser au niveau SQL. PostgreSQL utilise une variable pour configurer ce comportement:

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

La variable bytea_output accepte deux valeurs : « hex » indique à PostgreSQL TM d’envoyer les données au format hex. « escape » signifie que les données doivent être introduites sous forme de chaîne octale. Il n’y a pas grand-chose à craindre pour l’application ici, à part la taille maximale de 1 Go par champ.
Cependant, PostgreSQL dispose d’une deuxième interface pour gérer les données binaires : l’interface BLOB. Permettez-moi de montrer un exemple de cet outil puissant en action:

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

Dans ce cas, le contenu de /etc/hosts a été importé dans la base de données. Notez que PostgreSQL a une copie des données – ce n’est pas un lien vers le système de fichiers. Ce qui est remarquable ici, c’est que la base de données retournera l’ID (ID d’objet) de la nouvelle entrée. Pour garder une trace de cesIDs, certains développeurs procèdent comme suit:

INSERT 0 1

C’est absolument bien, sauf si vous faites quelque chose comme ci-dessous:

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

Le problème est que l’id de l’objet a été oublié. Cependant, l’objet est toujours là. pg_largeobject est la table système chargée de stocker les données binaires dans PostgreSQL. Toutes les fonctions lo_functions parleront simplement à cette table système afin de gérer ces problèmes:

Pourquoi est-ce un problème? La raison est simple: votre base de données augmentera et le nombre d' »objets morts » s’accumulera. Par conséquent, la bonne façon de tuer une entrée BLOB est la suivante:

Si vous oubliez de dissocier l’objet, vous souffrirez à long terme – et nous l’avons souvent vu arriver. C’est un problème majeur si vous utilisez l’interface BLOB.

vacuumlo: Nettoyage des gros objets morts

Cependant, comment peut-on résoudre le problème une fois que vous avez accumulé des milliers, voire des millions, de BLOBs morts? La réponse est un outil de ligne de commande appelé « vacuumlo ».
Créons d’abord une entrée morte:

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

Ensuite, nous pouvons exécuter vacuumlo à partir de n’importe quel client:

Comme vous pouvez le voir, deux objets morts ont été tués par l’outil. vacuumlo est le moyen le plus simple de nettoyer les objets orphelins.

Fonctionnalités supplémentaires

Cependant, il n’y a pas que lo_import et lo_unlink. PostgreSQL offre une variété de fonctions pour gérer les objets volumineux de manière agréable :

Il existe deux autres fonctions qui ne suivent pas la convention de nommage pour des raisons historiques : loread et lowrite:

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

Ce sont des fonctions dont les noms ne peuvent plus être facilement modifiés. Cependant, il convient de noter qu’ils existent.

Enfin …

L’interface BLOB PostgreSQL est vraiment utile et peut être utilisée pour beaucoup de choses. La beauté est qu’il est entièrement transactionnel et que, par conséquent, le contenu binaire et les métadonnées ne peuvent plus se désynchroniser.

Si vous souhaitez en savoir plus sur les déclencheurs pour appliquer des contraintes dans PostgreSQL, nous vous recommandons de consulter notre article de blog écrit par Laurenz Albe. Il fera la lumière sur ce sujet important.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.