a PostgreSQL egy szép BLOB felületet kínál, amelyet széles körben használnak. Azonban a közelmúltban találkoztunk a különböző ügyfelek problémáival, és érdemes egy kicsit tükrözni, és kitalálni, hogy a PostgreSQL hogyan kezeli a blobokat – és különösen a BLOB tisztítást.

a PostgreSQL BLOB interfész használata

a PostgreSQL-ben különféle eszközöket használhat bináris adatok tárolására. A legegyszerűbb forma határozottan a “bytea” (= byte array) adattípus használata. Ebben az esetben a bináris mezőt alapvetően egy sor részének tekintik.
így működik:

mint látható, ez egy normál oszlop, és ugyanúgy használható, mint egy normál oszlop. Az egyetlen dolog, amit érdemes megemlíteni, az a kódolás, amelyet SQL szinten kell használni. A PostgreSQL egy változót használ a viselkedés konfigurálásához:

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

a bytea_output változó két értéket fogad el: a” hex ” azt mondja a PostgreSQL-nek, hogy küldje el az adatokat hex formátumban. az “escape” azt jelenti, hogy az adatokat oktális karakterláncként kell betáplálni. Az alkalmazásnak itt nem kell sokat aggódnia, eltekintve a mezőnkénti maximális 1 GB-os mérettől.
a PostgreSQL-nek azonban van egy második interfésze a bináris adatok kezelésére: a BLOB interfész. Hadd mutassak egy példát erre a hatékony eszközre:

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

ebben az esetben az /etc/hosts tartalmát importáltuk az adatbázisba. Vegye figyelembe, hogy a PostgreSQL rendelkezik az adatok másolatával-ez nem a fájlrendszerre mutató link. Itt figyelemre méltó, hogy az adatbázis visszaadja az új bejegyzés OID-jét (object ID). Ezen OID-k nyomon követése érdekében egyes fejlesztők a következőket teszik:

INSERT 0 1

ez teljesen rendben van, hacsak nem csinálsz valamit, mint az alábbiakban:

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

a probléma az, hogy az objektumazonosítót elfelejtették. Az objektum azonban még mindig ott van. a pg_largeobject a bináris adatok PostgreSQL-ben történő tárolásáért felelős rendszertábla. Az összes lo_functions egyszerűen ehhez a rendszertáblához beszél, hogy kezelje ezeket a dolgokat:

miért probléma ez? Az ok egyszerű: az adatbázis növekedni fog, és a “halott objektumok” száma felhalmozódik. Ezért a BLOB bejegyzés megölésének helyes módja a következő:

ha elfelejted leválasztani a tárgyat, hosszú távon szenvedni fogsz – és ezt gyakran láttuk. Fontos kérdés, ha a BLOB felületet használja.

vacuumlo: halott nagy tárgyak megtisztítása

azonban hogyan lehet megoldani a problémát, ha több ezer vagy talán millió halott foltot halmozott fel? A válasz egy “vacuumlo”nevű parancssori eszköz.
először hozzunk létre egy halott bejegyzést:

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

ezután bármelyik kliensből futtathatjuk a vacuumlo – t:

mint látható, két halott tárgyat ölt meg az eszköz. a vacuumlo a legegyszerűbb módja az árva tárgyak tisztításának.

további funkciók

azonban van több, mint lo_import és lo_unlink. A PostgreSQL számos funkciót kínál a nagy objektumok szép módon történő kezeléséhez:

két további funkció van, amelyek történelmi okokból nem követik az elnevezési konvenciót: loread és lowrite:

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

ezek olyan funkciók, amelyek nevét már nem lehet könnyen megváltoztatni. Érdemes azonban megjegyezni, hogy léteznek.

végül …

a PostgreSQL BLOB interfész nagyon hasznos és sok mindenre használható. A szépség az, hogy teljesen tranzakciós, ezért a bináris tartalom és a metaadatok már nem mennek ki a szinkronból.

ha többet szeretne megtudni a PostgreSQL korlátozásainak érvényesítésére szolgáló triggerekről, javasoljuk, hogy nézze meg Laurenz Albe által írt blogbejegyzésünket. Ez rávilágít erre a fontos témára.

Vélemény, hozzászólás?

Az e-mail-címet nem tesszük közzé.