PostgreSQL-obiecte mari binare

Introducere

în PostgreSQL există mai multe moduri de a gestiona obiecte mari binare (LOB, BLOB):

  1. Basic binar tip de date BYTEA
  2. Basic caracter tip de date TEXT
  3. obiect mare (LO) facilitatea ‘pg_largeobject’
  4. tipul de date DATALINK (care este doar spec., fără implementare)

PostgreSQL acceptă, de asemenea, un sistem de stocare numit „TOAST” (tehnica de stocare a atributelor supradimensionate) care stochează automat valori mai mari decât o singură pagină a bazei de date (de obicei 8 KB) într-o zonă de stocare secundară pe tabel. Aceasta definește limita de dimensiune a oricărei coloane / câmp la 1 GB.

iată câteva întrebări de proiectare și implementare cu privire la obiecte mari:

  • este LO (conceptual) parte a obiectului/entității – sau doar asociată cu acesta?
  • cum este accesat LO: ca șir codificat, ca fișier sau bazat pe flux?
  • dacă nu este stocat în tabel, cine menține integritatea LO?

importul/exportul de fișiere binare externe

atunci când se utilizează BYTEA și TEXT (și XML) modul comun de a importa/exporta fișiere externe este în interiorul client (de exemplu, Java/Python) sau programe serverside (de exemplu, PL/Python). Este dificil să se ocupe de fișiere externe cu psql.

A Se Vedea Stackexchange: .

BYTEA

tipul de date BYTEA permite stocarea șirurilor binare.

  • stochează un LOB în tabel, respectiv folosind pâine prăjită.
  • este astfel limitat la 1 GB
  • stocarea este octală și permite caractere neimprimabile (spre deosebire de șiruri de caractere care nu).
  • formatul de intrare/ieșire este HEX (începând cu PostgreSQL 9.0).

Note:

  • BYTEA se apropie de SQL standard binar șir de tip ‘BLOB’. Funcțiile și operatorii furnizate de BYTEA sunt în mare parte aceleași, în timp ce formatul de intrare HEX al BYTEA este diferit.
  • BYTEA este mai lent pentru lungimi > 20 MB decât facilitatea LO (nu are accees aleatoare).

a se vedea PostgreSQL doc tipuri de date binare.

TEXT

tip de date de bază text este aici doar pentru completitudine. Acesta este un tip de caracter variabil cu lungime nelimitată (până la 1 GB). tipurile de caractere permit setările locale.

nu este un șir de octeți, dar se poate folosi în continuare atunci când șirul binar este preprocesat și codificat în formă imprimabilă (de exemplu, base64 sau hex).

obiect mare (LO) facilitatea

obiecte mari (LO) pot fi, de asemenea, plasate într-un singur tabel de sistem numit ‘pg_largeobject’ care trebuie accesat prin identificatori de tip de date OID.

  • există un API de citire/scriere care oferă funcții client (= module scrise în C) și server-side (= SQL).
  • principalele funcții SQL conexe sunt: lo_creat(), lo_create(), lo_unlink(), lo_import () și lo_export(). lo_import () și lo_export () au nevoie de permisiuni ale utilizatorului proprietar al bazei de date (adică superuser).
  • LO sunt împărțite în „bucăți” și stocate în rânduri indexate btree.
  • LO permite valori de până la 2 GB, în timp ce câmpurile prăjite (cum ar fi BYTEA) pot fi de cel mult 1 GB.
  • intrările LO pot fi modificate aleatoriu folosind un API de citire/scriere care este mai eficient decât efectuarea unor astfel de operații folosind TOAST (și, de exemplu, BYTEA).

notă:

  • când PostgreSQL doc. menționează ‘ lo ‘ (lo = obiect mare) se referă de obicei la această facilitate.
  • spre deosebire de exemplu, BYTEA – LO nu este un tip de date pe cont propriu, ci un tabel, o ‘facilitate’.

notă importantă atunci când se utilizează JDBC BLOB (sau @ lob adnotare în hibernare):

  • deoarece PostgreSQL consideră o intrare LO ca un obiect pe cont propriu, ștergerea sau susating rânduri în tabelul de utilizator nu șterge sau șterge intrările în pg_largeobjects. prin urmare, pg_largeobjects crește infinit, cu excepția cazului în care se face o curățare separată (consultați acest raport de eroare în Forumul Hibernate).
  • pentru a preveni acest lucru, de obicei trebuie adăugat un declanșator care șterge intrările din pg_largeobject ca descriptiebd în modulul ‘lo’.
  • vedeți modulele PostgreSQL suplimentare ‘lo’ și ‘vaccinlo’ în documentele PostgreSQL.

a se vedea PostgreSQL doc ‘obiecte mari’ și JDBC tip de date BLOB: .

exemplu: utilizare tipică în SQL (bazată pe documente Postgres):

 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

notă: în prezent nu există nicio implementare în PostgreSQL pentru asta. Este doar o specificație definită în SQL standard ‘SQL / MED’.

tipul de legătură de date stochează adresele URL ale fișierelor în coloanele bazei de date și aplică constrângeri asupra acesteia.

  • menține un link către un anumit fișier în spațiul de stocare extern.
  • sistemul de baze de date preia controlul asupra fișierelor externe (redenumiți, ștergeți, permisiunile se fac cu SQL) dacă sunt definite astfel.
  • Dimensiunea fișierului este nelimitată, respectiv limitată de stocarea externă. Nu este nevoie pentru a stoca conținutul fișierului în sistemul de baze de date.

parametrii legăturii de date:

  • nici un link de control Datalink valoare nu trebuie referință un fișier/URL existent.
  • FILE LINK control Datalink valoare trebuie să referință un fișier existent/URL.
  • integritate toate fișierele de referință pot fi redenumite sau șterse numai prin SQL.
  • fișierele de referință selective de integritate pot fi redenumite sau șterse prin SQL sau direct.
  • integritate nici unul (implicit pentru nici un control LINK)
  • pe Deconectare șterge fișierul este șters din sistemul de fișiere atunci când este șters din Baza de date.
  • la deconectare permisiunile originale ale fișierului RESTORE sunt restaurate atunci când sunt șterse din Baza de date.
  • pe Deconectare niciunul nicio modificare a permisiunilor de fișiere atunci când referința fișierului este ștearsă din Baza de date.
  • recuperare da PITR se aplică fișierelor de referință.
  • recuperare nu PITR nu se aplică fișierelor de referință.

stare și instalare:

  • neclar.

exemplu:

 CREATE TABLE image ( id integer, name text, picture DATALINK ); INSERT INTO persons VALUES ( 1, 'Jon Doe', DLVALUE('file://some/where/1.jpg') );

link-uri web:

  • pagina DATALINK wiki
  • prezentarea lui Peter Eisentraut, PGCon 2009:
  • teza MSE-Seminar (2011) de la Florian Schwendener despre „SQL / MED și multe altele-gestionarea datelor externe în PostgreSQL și Microsoft SQL Server”:

Lasă un răspuns

Adresa ta de email nu va fi publicată.