PostgreSQL oferuje ładny interfejs BLOB, który jest szeroko stosowany. Jednak ostatnio natknęliśmy się na problemy napotykane przez różnych klientów i warto zastanowić się trochę i dowiedzieć się, jak PostgreSQL radzi sobie z Blobami – a zwłaszcza z oczyszczaniem BLOB.

używając interfejsu BLOB PostgreSQL

w PostgreSQL możesz używać różnych środków do przechowywania danych binarnych. Najprostszą formą jest zdecydowanie użycie typu danych” bytea ” (=byte array). W tym przypadku pole binarne jest zasadniczo postrzegane jako część wiersza.
oto jak to działa:

jak widać, jest to normalna kolumna i może być używana tak jak zwykła kolumna. Jedyną rzeczą, o której warto wspomnieć, jest kodowanie, którego należy użyć na poziomie SQL. PostgreSQL używa zmiennej do skonfigurowania tego zachowania:

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

zmienna bytea_output przyjmuje dwie wartości: „hex” mówi PostgreSQL, aby wysłał dane w formacie hex. „escape” oznacza, że dane muszą być podawane jako łańcuch ósemkowy. Nie ma wiele aplikacja musi się martwić tutaj, oprócz maksymalnego rozmiaru 1 GB na pole.
jednak PostgreSQL ma drugi interfejs do obsługi danych binarnych: interfejs BLOB. Pozwólcie, że pokażę przykład tego potężnego narzędzia w działaniu:

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

w takim przypadku zawartość pliku/etc / hosts została zaimportowana do bazy danych. Zauważ, że PostgreSQL posiada kopię danych – nie jest to łącze do systemu plików. Warto zauważyć, że baza danych zwróci OID (object ID) nowego wpisu. Aby śledzić te OID, niektórzy programiści wykonują następujące czynności:

INSERT 0 1

to jest absolutnie w porządku, chyba że zrobisz coś takiego jak poniżej:

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

problem polega na tym, że id obiektu zostało zapomniane. Jednak obiekt nadal tam jest. pg_largeobject jest tabelą systemową odpowiedzialną za przechowywanie danych binarnych wewnątrz PostgreSQL. Wszystkie lo_functions będą po prostu rozmawiać z tą tabelą systemową, aby obsłużyć te rzeczy:

dlaczego to jest problem? Powód jest prosty: twoja baza danych będzie rosła, a liczba” martwych obiektów ” będzie się kumulować. Dlatego poprawny sposób zabicia wpisu BLOB jest następujący:

jeśli zapomnisz odłączyć obiekt, będziesz cierpieć na dłuższą metę – i często widzieliśmy, że tak się dzieje. Jest to poważny problem, jeśli używasz interfejsu BLOB.

vacuumlo: czyszczenie martwych dużych obiektów

jednak jak można rozwiązać problem, gdy zgromadzisz tysiące, a może miliony martwych plam? Odpowiedzią jest narzędzie wiersza poleceń o nazwie „vacuumlo”.
najpierw stwórzmy martwy wpis:

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

następnie możemy uruchomić vacuumlo z dowolnego klienta:

jak widać, narzędzie zabiło dwa martwe obiekty. vacuumlo jest najprostszym sposobem czyszczenia osieroconych obiektów.

dodatkowa funkcjonalność

jednak istnieje coś więcej niż tylko lo_import i lo_unlink. PostgreSQL oferuje wiele funkcji do obsługi dużych obiektów w przyjemny sposób:

istnieją jeszcze dwie funkcje, które nie są zgodne z konwencją nazewnictwa ze względów historycznych: loread i lowrite:

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

są to funkcje, których nazw nie da się już łatwo zmienić. Warto jednak zauważyć, że istnieją.

wreszcie …

interfejs BLOB PostgreSQL jest naprawdę przydatny i może być używany do wielu rzeczy. Piękno polega na tym, że jest w pełni transakcyjny, a zatem zawartość binarna i metadane nie mogą już zostać zsynchronizowane.

jeśli chcesz dowiedzieć się więcej o wyzwalaczach wymuszających ograniczenia w PostgreSQL, zalecamy zapoznanie się z naszym wpisem na blogu napisanym przez Laurenz Albe. Rzuci trochę światła na ten ważny temat.

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany.