PostgreSQL tarjoaa mukavan BLOB-käyttöliittymän, jota käytetään laajalti. Viime aikoina törmäsimme kuitenkin eri asiakkaiden kohtaamiin ongelmiin, ja on järkevää pohtia hieman ja selvittää, miten PostgreSQL käsittelee Blobeja – ja erityisesti BLOB cleanupia.

käyttämällä PostgreSQL-BLOB-rajapintaa

PostgreSQL: ssä binääritietojen tallentamiseen voi käyttää erilaisia keinoja. Yksinkertaisin muoto on ehdottomasti hyödyntää” bytea ” (=tavu array) tietotyyppiä. Tällöin binäärikenttä nähdään periaatteessa rivin osana.
näin se toimii:

kuten näette, tämä on normaali sarake ja sitä voidaan käyttää aivan kuten tavallista saraketta. Ainoa mainitsemisen arvoinen asia on koodaus, jota on käytettävä SQL-tasolla. PostgreSQL käyttää muuttujaa tämän käyttäytymisen määrittämiseen:

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

bytea_output-muuttuja hyväksyy kaksi arvoa:” hex ” kertoo PostgreSQL: n lähettävän tiedot hex-muodossa. ”pako” tarkoittaa, että data on syötettävä oktaalijonona. Ei ole paljon sovelluksen tarvitse huolehtia täällä, lukuun ottamatta maksimikoko 1 GB per kenttä.
PostgreSQL: llä on kuitenkin toinen käyttöliittymä binääridatan käsittelyyn: BLOB-käyttöliittymä. Haluan näyttää esimerkin tästä tehokkaasta työkalusta toiminnassa:

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

tässä tapauksessa, sisältö /etc/hosts on tuotu tietokantaan. Huomaa, että PostgreSQL: llä on kopio tiedoista – se ei ole linkki tiedostojärjestelmään. Huomionarvoista tässä on, että tietokanta palauttaa OID (object ID) uuden merkinnän. Seurata näitä OIDs, jotkut kehittäjät tekevät seuraavat:

INSERT 0 1

tämä on ihan ok, ellet tee jotain alle:

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

ongelmana on, että kohteen tunnus on unohtunut. Esine on kuitenkin yhä siellä. pg_largeobject on järjestelmätaulukko, joka vastaa binääridatan säilyttämisestä PostgreSQL: n sisällä. Kaikki lo_functions yksinkertaisesti puhua tähän järjestelmätaulukkoon, jotta voidaan käsitellä thesethings:

miksi se on ongelma? Syy on yksinkertainen: tietokanta kasvaa ja määrä ”kuolleita esineitä” kertyy. Siksi oikea tapa tappaa möykky merkintä on seuraava:

jos unohdat avata kohteen, kärsit pitkällä tähtäimellä-ja näin on usein käynyt. Se on suuri ongelma, jos käytät BLOB käyttöliittymä.

Imurointi: kuolleiden suurten esineiden siivoaminen

miten ongelman voi korjata, kun on kerännyt tuhansia tai ehkä miljoonia kuolleita möykkyjä? Vastaus on komentorivityökalu nimeltä ”vacuumlo”.
Let us first create a dead entry:

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

sitten voimme suorittaa imuroinnin keneltä tahansa asiakkaalta:

kuten näette, kaksi kuollutta esinettä on tapettu työkalulla. imurointi on helpoin tapa puhdistaa pois orpoja esineitä.

lisätoimintoja

on kuitenkin olemassa muutakin kuin vain lo_import ja lo_unlink. PostgreSQL tarjoaa erilaisia funktioita käsittelemään suuria kohteita mukavalla tavalla:

on vielä kaksi funktiota, jotka eivät historiallisista syistä noudata nimeämiskäytäntöä: loread ja lowrite:

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

ne ovat funktioita, joiden nimiä ei voi enää helposti muuttaa. On kuitenkin syytä huomata, että ne ovat olemassa.

vihdoin …

PostgreSQL-BLOB-käyttöliittymä on todella hyödyllinen ja sitä voi käyttää moneen asiaan. Kauneus on, että se on täysin transactional ja siksi binary sisältö ja metadata ei voi mennä pois synkronointi enää.

jos haluat tietää lisää PostgreSQL: n pakotteiden laukaisijoista, suosittelemme tutustumaan Laurenz Alben kirjoittamaan blogikirjoitukseen. Se valottaa tätä tärkeää aihetta.

Vastaa

Sähköpostiosoitettasi ei julkaista.