PostgreSQL tilbyr et fint BLOB-grensesnitt som er mye brukt. Men nylig kom vi over problemer som ulike kunder står overfor, og det er fornuftig å reflektere litt og finne ut hvordan PostgreSQL håndterer BLOBs – og spesielt BLOB cleanup.

Ved Hjelp Av PostgreSQL BLOB-grensesnittet

I PostgreSQL kan du bruke ulike metoder for å lagre binære data. Den enkleste formen er definitivt å gjøre bruk av datatypen» bytea » (=byte array). I dette tilfellet er et binært felt i utgangspunktet sett på som en del av en rad.
slik fungerer det:

som du kan se, er dette en vanlig kolonne, og den kan brukes akkurat som en vanlig kolonne. Det eneste som er verdt å nevne er kodingen man må bruke PÅ SQL-nivå. PostgreSQL bruker en variabel til å konfigurere denne virkemåten:

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

bytea_output-variabelen godtar to verdier:» hex » forteller PostgreSQL å sende dataene i hex-format. «escape» betyr at data må mates inn som en oktalstreng. Det er ikke mye programmet har å bekymre seg for her, bortsett fra maksimal størrelse på 1 GB per felt.
PostgreSQL har Imidlertid Et annet grensesnitt for å håndtere binære data: BLOB-grensesnittet. La meg vise et eksempel på dette kraftige verktøyet i aksjon:

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

i dette tilfellet er innholdet i /etc/hosts importert til databasen. Merk At PostgreSQL har en kopi av dataene-det er ikke en lenke til filsystemet. Det som er bemerkelsesverdig her er at databasen vil returnere oid (objekt-ID) til den nye oppføringen. For å holde oversikt over Disse Oidene, gjør noen utviklere følgende:

INSERT 0 1

Dette er helt greit, med mindre du gjør noe som nedenfor:

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

problemet er at objekt-iden har blitt glemt. Objektet er imidlertid fortsatt der. pg_largeobject er systemtabellen med ansvar for lagring av binære data inne PostgreSQL. Alle lo_functions vil bare snakke med dette systemtabellen for å håndtere disse tingene:

Hvorfor er Det et problem? Årsaken er enkel: databasen din vil vokse og antall «døde objekter» vil samle seg. Derfor er den riktige måten å drepe EN BLOB-oppføring som følger:

hvis du glemmer å koble fra objektet, vil du lide i det lange løp – og vi har ofte sett det skje. Det er et stort problem hvis DU bruker BLOB-grensesnittet.

vacuumlo: Rydde opp døde store objekter

men Hvordan kan man løse problemet når du har samlet tusenvis, eller kanskje millioner, av døde BLOBs? Svaret er et kommandolinjeverktøy kalt «vacuumlo».
La oss først lage en død oppføring:

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

da kan vi kjøre vacuumlo fra enhver klient:

som du kan se, har to døde gjenstander blitt drept av verktøyet. vacuumlo er den enkleste måten å rense ut foreldreløse gjenstander.

Tilleggsfunksjonalitet

det er imidlertid mer enn bare lo_import og lo_unlink. PostgreSQL tilbyr en rekke funksjoner for å håndtere store objekter på en fin måte:

det er to funksjoner som ikke følger navnekonvensjonen av historiske årsaker: loread og lowrite:

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

de er funksjoner hvis navn ikke lett kan endres lenger. Det er imidlertid verdt å merke seg at de eksisterer.

Endelig …

PostgreSQL BLOB-grensesnittet er veldig nyttig og kan brukes til mange ting. Det fine er at det er fullt transaksjons og derfor binært innhold og metadata kan ikke gå ut av sync lenger.

hvis du vil lære mer om utløsere for å håndheve begrensninger I PostgreSQL, anbefaler vi at du sjekker ut blogginnlegget vårt skrevet Av Laurenz Albe. Det vil kaste lys over dette viktige temaet.

Legg igjen en kommentar

Din e-postadresse vil ikke bli publisert.