PostgreSQL-binära stora objekt

introduktion

i PostgreSQL finns det flera sätt att hantera binära stora objekt (LOB, BLOB):

  1. grundläggande binär datatyp BYTEA
  2. grundläggande teckendatatyp TEXT
  3. Large object (LO) facility ’pg_largeobject’
  4. datatyp DATALINK (det är bara spec., inget genomförande)

PostgreSQL stöder också ett lagringssystem som kallas” TOAST ” (den överdimensionerade Attributlagringstekniken) som automatiskt lagrar värden som är större än en enda databassida (vanligtvis 8 KB) i ett sekundärt lagringsutrymme per tabell. Detta definierar storleksgränsen för varje kolumn / fält till 1 GB.

här är några design-och implementeringsfrågor angående stora objekt:

  • är LO (konceptuellt) en del av objektet/enheten – eller bara associerad med det?
  • hur nås LO: som kodad sträng, som fil eller strömbaserad?
  • om inte lagras i tabellen, som upprätthåller integriteten hos LO?

Importera/Exportera externa binära filer

när du använder BYTEA och TEXT (och XML) är det vanliga sättet att importera/exportera externa filer inuti klienten (t.ex. Java/Python) eller serversideprogram (t. ex. PL/Python). Det är svårt att hantera externa filer med psql.

Se Stackexchange:.

BYTEA

datatypen BYTEA tillåter lagring av binära strängar.

  • den lagrar en LOB i tabellen respektive med rostat bröd.
  • det är således begränsat till 1 GB
  • lagringen är oktal och tillåter icke utskrivbara tecken (i motsats till teckensträngar som inte gör det).
  • input/output-formatet är HEX (från PostgreSQL 9.0).

anmärkningar:

  • BYTEA kommer nära SQL – standard binär strängtyp ’BLOB’. Funktionerna och operatörerna som tillhandahålls av BYTEA är oftast desamma, medan HEX-inmatningsformat för BYTEA är annorlunda.
  • BYTEA är långsammare för längder > 20 MB än lo-anläggningen (den har inga slumpmässiga anslutningar).

se PostgreSQL doc binära datatyper.

TEXT

grundläggande datatyp text Det är bara här för fullständighet. Detta är en variabel teckentyp med obegränsad längd (upp till 1 GB). teckentyper tillåter lokala inställningar.

det är inte en byte-sträng men man kan fortfarande använda den när binärsträngen är förbehandlad och kodad till utskrivbar form (t.ex. base64 eller hex).

Large object (LO) facility

Large objects (lo) kan också placeras i en enda systemtabell som heter ’pg_largeobject’ som måste nås via identifierare av datatyp OID.

  • det finns ett Läs/skriv API som erbjuder klient (= moduler skrivna i C) och serversidan (= SQL) funktioner.
  • de viktigaste relaterade SQL-funktionerna är: lo_creat(), lo_create(), lo_unlink(), lo_import () och lo_export(). lo_import() och lo_export () behöver behörigheter för databasens ägande användare (dvs. superanvändare).
  • LO är uppdelade i ”bitar” och lagras i btree-indexerade rader.
  • lo tillåter värden upp till 2 GB i storlek, medan rostade fält (som BYTEA) kan vara högst 1 GB.
  • lo-poster kan slumpmässigt modifieras med hjälp av ett Läs – /skriv-API som är effektivare än att utföra sådana operationer med TOAST (och t.ex.BYTEA).

notera:

  • när PostgreSQL doc. nämner ’ lo ’ (Lo = stort objekt) det hänvisar vanligtvis till denna anläggning.
  • i motsats till t.ex. BYTEA – LO är inte en datatyp i sig utan en tabell, en ’anläggning’.

viktig anmärkning När du använder JDBC BLOB (eller @ Lob annotation i viloläge):

  • eftersom PostgreSQL betraktar en lo-post som ett objekt på egen hand, raderar eller raderar rader i användartabellen inte eller raderar poster i pg_largeobjects. pg_largeobjects växer därför oändligt om inte en separat rengöring görs (se denna felrapport i Hibernate forum).
  • för att förhindra detta måste vanligtvis en utlösare läggas till som raderar poster i pg_largeobject som descriebd i modul ’lo’.
  • se ytterligare PostgreSQL-moduler ’lo’ och ’vaccumlo’ i PostgreSQL-dokumenten.

se PostgreSQL doc ’stora objekt’ och JDBC datatyp BLOB: .

exempel: typisk användning i SQL (baserat på 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

OBS: Det finns för närvarande ingen implementering i PostgreSQL för det. Det är bara en specifikation som definieras i Standard SQL ’SQL / med’.

DATALINK-typen lagrar filadresser i databaskolumner och tillämpar begränsningar på den.

  • upprätthåller en länk till en specifik fil i extern lagring.
  • databassystem tar över kontrollen över externa filer (Byt namn, ta bort, behörigheter görs med SQL) om det definieras så.
  • filstorleken är obegränsad, respektive begränsad av extern lagring. Inget behov av att lagra filinnehåll i databassystemet.

DATALÄNKSPARAMETRAR:

  • inget LÄNKKONTROLLDATALÄNKVÄRDE behöver inte referera till en befintlig fil / URL.
  • fillänk kontroll Datalink värde måste referera till en befintlig fil/URL.
  • integritet alla refererade filer kan bara döpas om eller raderas via SQL.
  • integritet selektiva refererade filer kan döpas eller raderas via SQL eller direkt.
  • integritet ingen (underförstådd för ingen länkkontroll)
  • på UNLINK raderas filen från filsystemet när den raderas från databasen.
  • på UNLINK återställa filens ursprungliga behörigheter återställs när de tas bort från databasen.
  • på UNLINK ingen ingen ändring i filbehörigheter när filreferens tas bort från databasen.
  • återställning ja PITR gäller för refererade filer.
  • återställning ingen PITR gäller inte för refererade filer.

Status och Installation:

  • oklart.

exempel:

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

webblänkar:

  • DATALINK wiki sida
  • Presentation av Peter Eisentraut, PGCon 2009:
  • MSE-Seminarieuppsats (2011) från Florian Schwendener om ”SQL/med och mer-hantering av externa Data i PostgreSQL och Microsoft SQL Server”:

Lämna ett svar

Din e-postadress kommer inte publiceras.