wprowadzenie
w PostgreSQL istnieje kilka sposobów zarządzania binarnymi dużymi obiektami (LOB, BLOB):
- podstawowy binarny typ danych BYTEA
- podstawowy znak typ danych TEXT
- obiekt dużego obiektu (LO) 'pg_largeobject’
- typ danych DATALINK (to tylko spec., brak wdrożenia)
PostgreSQL obsługuje również system pamięci masowej o nazwie „TOAST” (Technika przechowywania atrybutów ponadwymiarowych), który automatycznie przechowuje wartości większe niż pojedyncza strona bazy danych (zazwyczaj 8 KB) w dodatkowym obszarze pamięci na tabelę. Określa limit rozmiaru dowolnej kolumny / pola do 1 GB.
oto kilka pytań dotyczących projektowania i realizacji dużych obiektów:
- czy LO (koncepcyjnie) jest częścią obiektu/bytu – czy tylko jest z nim związane?
- jak jest dostępny LO: jako kodowany ciąg, jako plik lub strumień oparty?
- jeśli nie jest przechowywany w tabeli, kto zachowuje integralność LO?
Importowanie/Eksportowanie zewnętrznych plików binarnych
przy użyciu BAJTEA i TEXT (oraz XML) powszechnym sposobem importowania/eksportowania zewnętrznych plików jest wewnątrz klienta (np. Java/Python) lub programów serwerowych (np. PL/Python). Z psql trudno jest obsługiwać pliki zewnętrzne.
Zobacz Stackexchange: .
BYTEA
typ danych BYTEA umożliwia przechowywanie łańcuchów binarnych.
- przechowuje LOB w tabeli, odpowiednio za pomocą tosta.
- jest więc ograniczony do 1 GB
- pamięć jest ośmiokątna i pozwala na drukowanie znaków (w przeciwieństwie do ciągów znaków, które nie).
- format wejścia/wyjścia To HEX (od PostgreSQL 9.0).
uwagi:
- BYTEA zbliża się do standardowego ciągu binarnego SQL typu 'BLOB’. Funkcje i operatory dostarczane przez BYTEA są w większości takie same, podczas gdy format wejściowy BYTEA jest inny.
- BAJTEA jest wolniejsza dla długości >20 MB niż lo (nie ma losowego dostępu).
Zobacz binarne typy danych PostgreSQL doc.
tekst
podstawowy typ danych tekst jest tu tylko dla kompletności. Jest to typ znaków zmiennych o nieograniczonej długości (do 1 GB). typy znaków pozwalają na ustawienia regionalne.
nie jest to łańcuch bajtowy, ale nadal można go używać, gdy łańcuch binarny jest wstępnie przetworzony i zakodowany do postaci drukowanej (np.
obiekt Large object (LO)
duże obiekty (LO) mogą być również umieszczone w pojedynczej tabeli systemowej o nazwie 'pg_largeobject’, do której należy uzyskać dostęp za pomocą identyfikatorów typu danych OID.
- istnieje API do odczytu/zapisu, które oferuje funkcje klienckie (= Moduły napisane w C) i po stronie serwera (= SQL).
- główne powiązane funkcje SQL to: lo_creat(), lo_create(), lo_unlink(), lo_import () i lo_export(). lo_import() i lo_export () potrzebują uprawnień użytkownika posiadającego bazę danych (tzn. superużytkownika).
- LO są podzielone na” kawałki ” i przechowywane w wierszach indeksowanych btree.
- LO pozwala na wartości o rozmiarze do 2 GB, podczas gdy Toastowane pola (takie jak BYTEA) mogą mieć co najwyżej 1 GB.
- wpisy LO mogą być losowo modyfikowane przy użyciu interfejsu API odczytu/zapisu, który jest bardziej wydajny niż wykonywanie takich operacji przy użyciu TOAST (i np. BYTEA).
Uwaga:
- kiedy PostgreSQL doc. wspomina o ’ lo ’ (LO = duży obiekt) zazwyczaj odnosi się do tej placówki.
- w przeciwieństwie do np. BYTEA – LO nie jest typem danych sam w sobie, ale tabelą, 'facility’.
WAŻNA UWAGA podczas używania JDBC BLOB (lub adnotacji @Lob w hibernacji):
- ponieważ PostgreSQL uważa wpis LO za własny obiekt, usuwanie lub dodawanie wierszy w tabeli użytkownika nie usuwa ani nie usuwa wpisów w pg_largeobjects. dlatego pg_largeobjects rośnie w nieskończoność, chyba że zostanie wykonane oddzielne czyszczenie (zobacz ten raport o błędzie w Hibernate forum).
- aby temu zapobiec, zazwyczaj należy dodać wyzwalacz, który usuwa wpisy w pg_largeobject jako descriebd w module 'lo’.
- Zobacz dodatkowe moduły PostgreSQL ’ lo ’ i 'vaccumlo’ w dokumentach PostgreSQL.
Patrz PostgreSQL doc 'Large Objects’ oraz typ danych JDBC BLOB: .
przykład: typowe użycie w SQL (na podstawie Postgres docs):
CREATE TABLE image ( id integer, name text, picture oid ); SELECT lo_creat(-1); -- returns OID of new, empty large object. SELECT lo_create(43213); -- attempts to create large object with OID 43213. SELECT lo_unlink(173454); -- deletes large object with OID 173454. INSERT INTO image (id, name, picture) VALUES (1, 'beautiful image', lo_import('/etc/motd')); INSERT INTO image (id, name, picture) -- same as above, but specify OID to use. VALUES (1, 'beautiful image', lo_import('/etc/motd', 68583)); SELECT lo_export(image.raster, '/tmp/motd') FROM image -- need superuser permission. WHERE name = 'beautiful image';
DATALINK
uwaga: w PostgreSQL nie ma obecnie żadnej implementacji. To tylko Specyfikacja zdefiniowana w standardowym SQL 'SQL / MED’.
Typ DATALINK przechowuje adresy URL plików w kolumnach bazy danych i stosuje na nich ograniczenia.
- utrzymuje łącze do określonego pliku w pamięci zewnętrznej.
- system bazodanowy przejmuje kontrolę nad plikami zewnętrznymi (zmiana nazwy, usuwanie, uprawnienia wykonywane są za pomocą SQL), jeśli tak zdefiniowano.
- Rozmiar pliku jest nieograniczony, odpowiednio ograniczony przez pamięć zewnętrzną. Nie ma potrzeby przechowywania zawartości plików w systemie bazodanowym.
parametry łącza danych:
- brak wartości łącza kontrolnego nie musi odwoływać się do istniejącego pliku / adresu URL.
- FILE LINK control DataLink wartość musi odnosić się do istniejącego pliku / URL.
- integralność wszystkie powiązane pliki mogą być zmieniane lub usuwane tylko za pomocą SQL.
- integralność selektywne pliki odniesienia można zmienić lub usunąć za pomocą SQL lub bezpośrednio.
- integralność brak (implikowane dla braku kontroli łącza)
- po odłączeniu usuń plik jest usuwany z systemu plików po usunięciu z bazy danych.
- po usunięciu z bazy danych oryginalne uprawnienia pliku przywracania są przywracane.
- przy rozłączeniu brak brak zmiany uprawnień do plików, gdy odwołanie do pliku jest usuwane z bazy danych.
- odzyskiwanie tak PITR dotyczy odwołujących się Plików.
- odzyskiwanie brak PITR nie ma zastosowania do odwołujących się Plików.
Status i instalacja:
- niejasne.
przykład:
CREATE TABLE image ( id integer, name text, picture DATALINK ); INSERT INTO persons VALUES ( 1, 'Jon Doe', DLVALUE('file://some/where/1.jpg') );
Weblinki:
- strona wiki DATALINK
- Prezentacja Petera Eisentrauta, PGCon 2009:
- MSE-Seminar Thesis (2011) from Florian Schwendener about „SQL / MED and More-Management of External Data in PostgreSQL and Microsoft SQL Server”: