Postgraduate tilbyder en dejlig BLOB interface, som er meget udbredt. Men for nylig stødte vi på problemer, som forskellige kunder står overfor, og det giver mening at reflektere lidt og finde ud af, hvordan Postgraduate håndterer BLOBs – og især BLOB cleanup.

ved hjælp af grænsefladen postgraduate BLOB

i postgraduate kan du bruge forskellige midler til at gemme binære data. Den enkleste form er bestemt at gøre brug af datatypen “bytea” (= byte array). I dette tilfælde ses et binært felt dybest set som en del af en række.
sådan fungerer det:

som du kan se, er dette en normal kolonne, og den kan bruges ligesom en normal kolonne. Det eneste, der er værd at nævne, er den kodning, man skal bruge på kvm-niveau. Bruger en variabel til at konfigurere denne adfærd:

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

bytea_output-variablen accepterer to værdier: “sekskant” fortæller Postgraduate at sende dataene i sekskantformat. “escape” betyder, at data skal tilføres som en oktal streng. Der er ikke meget, applikationen skal bekymre sig om her, bortset fra den maksimale størrelse på 1 GB pr.
dog har Postgraduate en anden grænseflade til at håndtere binære data: BLOB-grænsefladen. Lad mig vise et eksempel på dette kraftfulde værktøj i aktion:

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

i dette tilfælde er indholdet af /etc/hosts blevet importeret til databasen. Bemærk, at har en kopi af dataene – det er ikke et link til filsystemet. Det, der er bemærkelsesværdigt her, er, at databasen returnerer OID (object ID) for den nye post. For at holde styr på disse OID ‘ er gør nogle udviklere følgende:

INSERT 0 1

dette er helt fint, medmindre du gør noget som nedenfor:

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

problemet er, at objekt-id ‘ et er blevet glemt. Objektet er dog stadig der. pg_largeobject er systemtabellen, der har ansvaret for lagring af de binære data inde i postgraduate. Alle lo_functions vil simpelthen tale med denne systemtabel for at håndtere disse ting:

Hvorfor er det et problem? Årsagen er enkel: din database vil vokse, og antallet af “døde objekter” akkumuleres. Derfor er den rigtige måde at dræbe en BLOB-post på som følger:

hvis du glemmer at fjerne linket fra objektet, vil du lide i det lange løb – og vi har ofte set det ske. Det er et stort problem, hvis du bruger BLOB-grænsefladen.

vacuumlo: oprydning af døde store genstande

men hvordan kan man løse problemet, når du har akkumuleret tusinder eller måske millioner af døde klatter? Svaret er et kommandolinjeværktøj kaldet”vacuumlo”.
lad os først oprette en død post:

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

så kan vi køre vacuumlo fra enhver klient:

som du kan se, er to døde objekter blevet dræbt af værktøjet. vacuumlo er den nemmeste måde at rense forældreløse genstande på.

yderligere funktionalitet

der er dog mere end bare lo_import og lo_unlink. Vi tilbyder en række funktioner til at håndtere store objekter på en god måde:

der er to funktioner, der ikke følger navngivningskonventionen af historiske grunde::

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

de er funktioner, hvis navne ikke let kan ændres længere. Det er dog værd at bemærke, at de eksisterer.

endelig …

postgraduate BLOB interface er virkelig nyttigt og kan bruges til mange ting. Skønheden er, at det er fuldt transaktionelt, og derfor kan binært indhold og metadata ikke længere gå ud af synkronisering.

hvis du vil lære mere om udløsere til at håndhæve begrænsninger i postgraduate, anbefaler vi, at du tjekker vores blogindlæg skrevet af Laurens Albe. Det vil kaste lys over dette vigtige emne.

Skriv et svar

Din e-mailadresse vil ikke blive publiceret.