Úvod
v PostgreSQL existuje několik způsobů, jak spravovat binární velké objekty (LOB, BLOB):
- základní binární datový typ BYTEA
- základní znakový datový typ TEXT
- velký objekt (LO) zařízení ‚pg_largeobject‘
- 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“: