PostgreSQL erbjuder ett trevligt BLOB-gränssnitt som används allmänt. Men nyligen kom vi över problem som olika kunder står inför, och det är vettigt att reflektera lite och ta reda på hur PostgreSQL hanterar blobbar – och särskilt BLOB cleanup.

använda PostgreSQL BLOB-gränssnittet

i PostgreSQL kan du använda olika sätt att lagra binär data. Den enklaste formen är definitivt att använda datatypen” bytea ” (=byte array). I detta fall ses ett binärt fält i princip som en del av en rad.
så här fungerar det:

som du kan se är detta en vanlig kolumn och den kan användas precis som en vanlig kolumn. Det enda som är värt att nämna är kodningen man måste använda på SQL-nivå. PostgreSQL använder en variabel för att konfigurera detta beteende:

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

bytea_output-variabeln accepterar två värden:” hex ” ber PostgreSQL att skicka data i hex-format. ”escape” betyder att data måste matas in som en oktal sträng. Det finns inte mycket applikationen behöver oroa sig för här, förutom den maximala storleken på 1 GB per fält.
PostgreSQL har dock ett andra gränssnitt för att hantera binär data: BLOB-gränssnittet. Låt mig visa ett exempel på detta kraftfulla verktyg i aktion:

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

i det här fallet har innehållet i /etc/hosts importerats till databasen. Observera att PostgreSQL har en kopia av data – Det är inte en länk till filsystemet. Det som är anmärkningsvärt här är att databasen kommer att returnera OID (object ID) för den nya posten. För att hålla reda på dessa oid: er gör vissa utvecklare följande:

INSERT 0 1

det här är helt bra, om du inte gör något som nedan:

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

problemet är att objektets id har glömts bort. Objektet är dock fortfarande kvar. pg_largeobject är systemtabellen som ansvarar för lagring av binära data i PostgreSQL. Alla lo_functions kommer helt enkelt att prata med denna systemtabell för att hantera dessa saker:

Varför är det ett problem? Anledningen är enkel: din databas kommer att växa och antalet ”döda objekt” kommer att ackumuleras. Därför är det rätta sättet att döda en BLOB-Post följande:

om du glömmer att koppla bort objektet kommer du att lida på lång sikt – och vi har ofta sett det hända. Det är en viktig fråga om du använder BLOB-gränssnittet.

vacuumlo: rengöring av döda stora föremål

hur kan man dock lösa problemet när du har samlat tusentals, eller kanske miljoner, döda blobbar? Svaret är ett kommandoradsverktyg som heter”vacuumlo”.
Låt oss först skapa en död post:

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

då kan vi köra vacuumlo från vilken klient som helst:

som du kan se har två döda föremål dödats av verktyget. vacuumlo är det enklaste sättet att rengöra föräldralösa föremål.

ytterligare funktionalitet

det finns dock mer än bara lo_import och lo_unlink. PostgreSQL erbjuder en mängd olika funktioner för att hantera stora objekt på ett trevligt sätt:

det finns ytterligare två funktioner som inte följer namnkonventionen av historiska skäl: loread och lowrite:

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

de är funktioner vars namn inte lätt kan ändras längre. Det är dock värt att notera att de existerar.

slutligen …

PostgreSQL BLOB-gränssnittet är verkligen användbart och kan användas för många saker. Skönheten är att den är helt transaktionell och därför kan binärt innehåll och metadata inte synkroniseras längre.

om du vill lära dig mer om triggers för att genomdriva begränsningar i PostgreSQL rekommenderar vi att du kolla in vårt blogginlägg skrivet av Laurenz Albe. Det kommer att belysa detta viktiga ämne.

Lämna ett svar

Din e-postadress kommer inte publiceras.