PostgreSQL-Binary Large Objects

Bevezetés

a PostgreSQL-ben számos módszer létezik a bináris nagy objektumok (LOB, BLOB) kezelésére):

  1. alapvető bináris adattípus BYTEA
  2. alapvető karakter adattípus szöveg
  3. nagy objektum (LO) létesítmény ‘pg_largeobject’
  4. adattípus DATALINK (ez csak spec., nincs megvalósítás)

a PostgreSQL támogatja a “TOAST” (a túlméretezett attribútumú tárolási technika) nevű tárolórendszert is, amely automatikusan egyetlen adatbázisoldalnál (általában 8 KB) nagyobb értékeket tárol táblázatonként egy másodlagos tárolóterületre. Ez meghatározza bármely oszlop/mező méretkorlátját 1 GB-ra.

íme néhány tervezési és megvalósítási kérdés a nagy tárgyakkal kapcsolatban:

  • a lo (fogalmilag) része az objektumnak/entitásnak – vagy csak társul hozzá?
  • hogyan érhető el a LO: kódolt karakterláncként, fájlként vagy adatfolyam-alapúként?
  • ha nem tárolja a táblázatban, ki tartja fenn az LO integritását?

külső bináris fájlok importálása/exportálása

a BYTEA és a TEXT (és XML) használatakor a külső fájlok importálásának/exportálásának általános módja a kliens (pl. Java/Python) vagy a szerveroldali programok (PL/Python). Nehéz kezelni a külső fájlokat a psql segítségével.

Lásd Stackexchange: .

BYTEA

a BYTEA adattípus lehetővé teszi a bináris karakterláncok tárolását.

  • ez tárolja a LOB az asztalon belül, illetve a TOAST.
  • így 1 GB-ra korlátozódik
  • a tárhely oktális, és lehetővé teszi a nem nyomtatható karaktereket (ellentétben a karakterláncokkal, amelyek nem).
  • a bemeneti/kimeneti formátum HEX (a PostgreSQL 9.0 szerint).

Megjegyzések:

  • a BYTEA közel áll az SQL standard bináris karakterlánc típusához ‘BLOB’. A bytea által biztosított funkciók és operátorok többnyire azonosak, míg a BYTEA hexadecimális bemeneti formátuma eltérő.
  • a BYTEA lassabb a > 20 MB hosszúságnál, mint az LO létesítmény (nincs véletlenszerű hozzáférése).

lásd PostgreSQL Doc bináris adattípusok.

szöveg

alapvető adattípus szöveg csak a teljesség kedvéért van itt. Ez egy változó karaktertípus, korlátlan hosszúságú (legfeljebb 1 GB). a karaktertípusok lehetővé teszik a területi beállításokat.

ez nem egy bájt karakterlánc, de még mindig használható, ha a bináris karakterláncot előre feldolgozzák és nyomtatható formába kódolják (pl. base64 vagy hex).

Large object (lo) facility

a Large object (Lo) is elhelyezhető egy ‘pg_largeobject’ nevű rendszertáblában, amelyhez az OID típusú azonosítókon keresztül kell hozzáférni.

  • van egy írás/olvasás API, amely kliens (= C-ben írt modulok) és szerver oldali (= SQL) funkciókat kínál.
  • a főbb kapcsolódó SQL függvények: lo_creat(), lo_create(), lo_unlink(), lo_import () és lo_export(). a lo_import () és a lo_export() az adatbázist birtokló felhasználó (azaz superuser) engedélyeit igényli.
  • az LO-t “darabokra” bontják, és btree-indexelt sorokban tárolják.
  • a LO legfeljebb 2 GB méretű értékeket engedélyez, míg a pirított mezők (például a BYTEA) legfeljebb 1 GB lehetnek.
  • a lo bejegyzések véletlenszerűen módosíthatók egy olyan írás/olvasás API használatával, amely hatékonyabb, mint az ilyen műveletek végrehajtása a TOAST (és például a BYTEA) használatával.

Megjegyzés:

  • amikor PostgreSQL doc. megemlíti a ‘lo’ – t (LO = nagy objektum) általában erre a létesítményre utal.
  • ellentétben pl. a BYTEA-LO önmagában nem adattípus, hanem egy tábla, egy ‘létesítmény’.

fontos megjegyzés JDBC BLOB használatakor (vagy @Lob annotáció hibernált állapotban):

  • mivel a PostgreSQL egy LO bejegyzést saját objektumnak tekint, a felhasználói táblázat sorainak törlése vagy felemelése nem törli vagy törli a bejegyzéseket a pg_largeobjects alkalmazásban. a pg_largeobjects tehát végtelenül növekszik, hacsak nem történik külön Tisztítás (lásd ezt a hibajelentést a Hibernate fórumban).
  • ennek megakadályozása érdekében általában egy triggert kell hozzáadni, amely törli a bejegyzéseket a pg_largeobject-ben descriebd-ként a ‘lo’modulban.
  • további PostgreSQL modulok ‘lo’ és ‘vaccumlo’ a PostgreSQL dokumentumokban.

lásd PostgreSQL doc ‘nagy objektumok’ és JDBC adattípus BLOB: .

példa: tipikus használat az SQL – ben (Postgres dokumentumok alapján):

 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

megjegyzés: Jelenleg nincs implementáció a PostgreSQL-ben. Ez csak egy szabványos SQL ‘SQL/MED’specifikáció.

a DATALINK típus a fájl URL-címeit adatbázis oszlopokban tárolja, és korlátozásokat alkalmaz rá.

  • egy adott fájlra mutató hivatkozást tart fenn a külső tárolóban.
  • adatbázis rendszer átveszi az irányítást a külső fájlok (átnevezés, törlés, engedélyek történik SQL), ha úgy definiáljuk.
  • a fájlméret korlátlan, illetve a külső tárhely korlátozza. Nem kell tárolni a fájl tartalmát adatbázis-rendszer.

adatkapcsolati paraméterek:

  • no LINK CONTROL Datalink érték nem kell hivatkozni egy meglévő fájl / URL.
  • FILE LINK CONTROL az adatkapcsolat értékének egy meglévő fájlra/URL-re kell hivatkoznia.
  • integritás az összes hivatkozott fájlt csak SQL-en keresztül lehet átnevezni vagy törölni.
  • integritás szelektív hivatkozott fájlok átnevezhetők vagy törölhetők SQL vagy közvetlenül.
  • integritás nincs (a hivatkozás nélküli vezérlésre utal)
  • a kapcsolat leválasztásakor a fájl törlése törlődik a fájlrendszerből, amikor az adatbázisból törlődik.
  • ON UNLINK visszaállítás a fájl eredeti jogosultságai visszaállnak, ha törlik az adatbázisból.
  • on UNLINK NONE nincs változás a fájlengedélyekben, ha a fájlhivatkozás törlődik az adatbázisból.
  • helyreállítás igen a PITR a hivatkozott fájlokra vonatkozik.
  • helyreállítás a PITR nem vonatkozik a hivatkozott fájlokra.

állapot és telepítés:

  • nem világos.

példa:

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

weblinkek:

  • DATALINK wiki oldal
  • Peter Eisentraut bemutatása, PGCon 2009:
  • MSE-Florian Schwendener szemináriumi tézise (2011) az “SQL/MED and More – külső adatok kezelése a PostgreSQL-ben és a Microsoft SQL Server-ben”:

Vélemény, hozzászólás?

Az e-mail-címet nem tesszük közzé.