PostgreSQL-binarne duże obiekty

wprowadzenie

w PostgreSQL istnieje kilka sposobów zarządzania binarnymi dużymi obiektami (LOB, BLOB):

  1. podstawowy binarny typ danych BYTEA
  2. podstawowy znak typ danych TEXT
  3. obiekt dużego obiektu (LO) 'pg_largeobject’
  4. 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”:

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany.