PostgreSQL oferă o interfață BLOB frumos, care este utilizat pe scară largă. Cu toate acestea, recent am întâlnit probleme cu care se confruntă diverși clienți și este logic să reflectăm puțin și să ne dăm seama cum PostgreSQL gestionează bloburile – și mai ales curățarea BLOBURILOR.

folosind interfața PostgreSQL BLOB

în PostgreSQL, puteți utiliza diverse mijloace pentru a stoca date binare. Cea mai simplă formă este cu siguranță să folosiți tipul de date „bytea” (= byte array). În acest caz, un câmp binar este văzut practic ca parte a unui rând.
Iată cum funcționează:

după cum puteți vedea, aceasta este o coloană normală și poate fi utilizată la fel ca o coloană normală. Singurul lucru demn de menționat este codificarea pe care trebuie să o utilizați la nivel SQL. PostgreSQL utilizează o variabilă pentru a configura acest comportament:

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

variabila bytea_output acceptă două valori:” hex ” îi spune lui PostgreSQL să trimită datele în format hex. „escape” înseamnă că datele trebuie să fie alimentate ca un șir octal. Nu este prea mult aplicația trebuie să vă faceți griji aici, în afară de dimensiunea maximă de 1 GB pe câmp.
cu toate acestea, PostgreSQL are o a doua interfață pentru a gestiona datele binare: interfața BLOB. Permiteți – mi să arăt un exemplu al acestui instrument puternic în acțiune:

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

în acest caz, conținutul /etc/hosts a fost importat în baza de date. Rețineți că PostgreSQL are o copie a datelor – nu este un link către sistemul de fișiere. Ceea ce este demn de remarcat aici este că baza de date va returna OID (ID obiect) al noii intrări. Pentru a urmări aceste OID-uri, unii dezvoltatori fac următoarele:

INSERT 0 1

acest lucru este absolut bine, dacă nu faci ceva de genul de mai jos:

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

problema este că ID-ul obiectului a fost uitat. Cu toate acestea, obiectul este încă acolo. pg_largeobject este tabelul de sistem responsabil de stocarea datelor binare în interiorul PostgreSQL. Toate lo_functions va vorbi pur și simplu la acest tabel de sistem, în scopul de a gestiona thesethings:

de ce este că o problemă? Motivul este simplu: baza dvs. de date va crește și se va acumula numărul de „obiecte moarte”. Prin urmare, modul corect de a ucide o intrare BLOB este după cum urmează:

dacă uitați să deconectați obiectul, veți suferi pe termen lung – și am văzut adesea că se întâmplă. Este o problemă majoră dacă utilizați interfața BLOB.

vacuumlo: curățarea obiectelor mari moarte

cu toate acestea, cum se poate rezolva problema odată ce ați acumulat mii, sau poate milioane, de pete moarte? Răspunsul este un instrument de linie de comandă numit „vacuumlo”.
să creăm mai întâi o intrare moartă:

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

apoi putem rula vacuumlo de la orice client:

după cum puteți vedea, două obiecte moarte au fost ucise de instrument. vacuumlo este cel mai simplu mod de a curăța obiecte orfane.

funcționalitate suplimentară

cu toate acestea, există mai mult decât lo_import și lo_unlink. PostgreSQL oferă o varietate de funcții pentru a gestiona obiecte mari într-un mod frumos:

există încă două funcții care nu respectă Convenția de denumire din motive istorice: loread și lowrite:

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

sunt funcții ale căror nume nu mai pot fi schimbate cu ușurință. Cu toate acestea, este demn de remarcat faptul că există.

în sfârșit …

interfața PostgreSQL BLOB este foarte utilă și poate fi folosită pentru multe lucruri. Frumusețea este că este complet tranzacțional și, prin urmare, conținutul binar și metadatele nu mai pot ieși din sincronizare.

dacă doriți să aflați mai multe despre declanșatoarele pentru a impune constrângerile în PostgreSQL, vă recomandăm să consultați postarea noastră pe blog scrisă de Laurenz Albe. Va arunca o lumină asupra acestui subiect important.

Lasă un răspuns

Adresa ta de email nu va fi publicată.