PostgreSQL-binární velké objekty

Úvod

v PostgreSQL existuje několik způsobů, jak spravovat binární velké objekty (LOB, BLOB):

  1. základní binární datový typ BYTEA
  2. základní znakový datový typ TEXT
  3. velký objekt (LO) zařízení ‚pg_largeobject‘
  4. datový typ DATALINK (to je jen spec., žádná implementace)

PostgreSQL také podporuje úložný systém nazvaný „TOAST“ (technika ukládání nadměrných atributů), který automaticky ukládá hodnoty větší než jedna stránka databáze (obvykle 8 KB) do sekundární úložné oblasti na tabulku. To definuje limit velikosti libovolného sloupce / pole na 1 GB.

zde jsou některé konstrukční a implementační otázky týkající se velkých objektů:

  • je LO (koncepčně) součástí objektu / entity-nebo s ním jen spojena?
  • jak je přístup k LO: jako kódovaný řetězec, jako soubor nebo stream?
  • pokud není uložen v tabulce, kdo udržuje integritu LO?

Import / Export externích binárních souborů

při použití BYTEA a textu (a XML) je běžný způsob importu/exportu externích souborů uvnitř klienta (např. Java/Python) nebo serverside programms (např. PL / Python). Je obtížné zpracovat externí soubory s psql.

Viz Stackexchange: .

BYTEA

datový typ BYTEA umožňuje ukládání binárních řetězců.

  • ukládá LOB v tabulce, respektive pomocí toastu.
  • je tedy omezena na 1 GB
  • úložiště je osmičkové a umožňuje netisknutelné znaky (na rozdíl od řetězců znaků, které ne).
  • vstupní / výstupní formát je HEX (od PostgreSQL 9.0).

poznámky:

  • BYTEA se blíží standardnímu binárnímu řetězci typu SQL „BLOB“. Funkce a operátory poskytované BYTEA jsou většinou stejné, zatímco hex vstupní formát BYTEA je jiný.
  • BYTEA je pomalejší pro délky >20 MB než zařízení LO (nemá žádné náhodné přístupy).

viz PostgreSQL Doc binární datové typy.

TEXT

základní datový typ text je to jen tady pro úplnost. Jedná se o variabilní typ znaku s neomezenou délkou (až 1 GB). typy znaků umožňují nastavení národního prostředí.

není to bajtový řetězec, ale dalo by se ho použít i v případě, že je binární řetězec předzpracován a zakódován do tisknutelné podoby (např. base64 nebo hex).

velké objekty (LO) zařízení

velké objekty (LO) lze také umístit do jediné systémové tabulky s názvem „pg_largeobject“, ke které je třeba přistupovat pomocí identifikátorů datového typu OID.

  • existuje read/write API, které nabízí klientské (= moduly napsané v C) a serverové (=SQL) Funkce.
  • hlavní související SQL funkce jsou: lo_creat (), lo_create (), lo_unlink (), lo_import () a lo_export(). lo_import() a lo_export () potřebují oprávnění uživatele, který vlastní databázi (tj.
  • LO jsou rozděleny na „kusy“ a uloženy v řádcích indexovaných btree.
  • LO umožňuje hodnoty až do velikosti 2 GB, zatímco opečená pole (jako BYTEA) mohou být maximálně 1 GB.
  • lo záznamy mohou být náhodně modifikovány pomocí rozhraní API pro čtení/zápis, které je efektivnější než provádění takových operací pomocí TOAST (a např. BYTEA).

Poznámka:

  • když PostgreSQL doc. zmiňuje ‚lo‘ (LO = velký objekt) obvykle odkazuje na toto zařízení.
  • na rozdíl od např. BYTEA-LO není datový typ sám o sobě, ale tabulka, „zařízení“.

důležitá poznámka Při použití JDBC BLOB (nebo anotace @Lob v režimu spánku):

  • vzhledem k tomu, že PostgreSQL považuje položku LO za objekt sám o sobě, mazání nebo upating řádků v uživatelské tabulce does ‚ nt odstranit nebo odstranit položky v pg_largeobjects. pg_largeobjects tedy roste nekonečně, pokud není provedeno samostatné čištění (viz tato chybová zpráva ve fóru hibernace).
  • aby se tomu zabránilo, obvykle je třeba přidat spoušť, která odstraní položky v pg_largeobject jako descriebd v modulu ‚lo‘.
  • Viz další moduly PostgreSQL ‚lo‘ a ‚vaccumlo‘ v dokumentech PostgreSQL.

viz PostgreSQL doc ‚velké objekty‘ a JDBC datový typ BLOB: .

příklad: typické použití v SQL (na základě dokumentů 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

poznámka: v PostgreSQL pro to momentálně neexistuje žádná implementace. Je to jen SPECIFIKACE definovaná ve standardním SQL ‚SQL / MED‘.

Typ DATALINK ukládá adresy URL souborů do sloupců databáze a aplikuje na ně omezení.

  • udržuje odkaz na konkrétní soubor v externím úložišti.
  • databázový systém přebírá kontrolu nad externími soubory (přejmenování, mazání, oprávnění se provádí pomocí SQL), pokud je tak definováno.
  • Velikost souboru je neomezená, respektive omezena externím úložištěm. Není třeba ukládat obsah souborů v databázovém systému.

parametry datového spojení:

  • hodnota Datalink bez kontroly odkazů nemusí odkazovat na existující soubor / adresu URL.
  • soubor LINK CONTROL Datalink hodnota musí odkazovat na existující soubor / URL.
  • integrita všechny odkazované soubory lze přejmenovat nebo odstranit pouze pomocí SQL.
  • INTEGRITY selektivní odkazované soubory mohou být přejmenovány nebo odstraněny pomocí SQL nebo přímo.
  • integrita NONE (implikované pro kontrolu bez odkazu)
  • na UNLINK DELETE soubor je odstraněn ze systému souborů při odstranění z databáze.
  • na UNLINK obnovit původní oprávnění souboru jsou obnoveny při odstranění z databáze.
  • na UNLINK NONE žádná změna oprávnění souboru, když je odkaz na soubor odstraněn z databáze.
  • obnova Ano PITR se vztahuje na odkazované soubory.
  • RECOVERY no PITR se nevztahuje na odkazované soubory.

stav a instalace:

  • nejasné.

příklad:

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

Weblinks:

  • DATALINK wiki page
  • prezentace Petera Eisentrauta, PGCon 2009:
  • MSE-seminární práce (2011) Floriana Schwendenera o „SQL/MED a další – Správa externích dat v PostgreSQL a Microsoft SQL Server“:

Napsat komentář

Vaše e-mailová adresa nebude zveřejněna.