Zobrazení zdroje stránky Slovník

== ACID ==
''Atomic, Consistent, Isolated, Durable''

ACID je obecně uznávaný seznam požadavků na bezpečný transakční systém:
* Atomičnost - v rámci transakce se provedou všechny změny nebo žádná.
* Konzistence - transakce zajišťují převedení dat z jednoho konzistentního stavu do druhého. Tato podmínka nemusí platit uvnitř transakce.
* Izolace - transakce není ovlivněna souběžnými transakcemi.
* Trvanlivost - pokud je transakce potvrzená, pak jsou změny dat trvalé a to i pokud nastane havárie systému.

== MVCC ==
''Multi Version Concurency control''

Úkolem databázového systému je zajištění konzistence dat při současném zpracování požadavků více uživatelů. Snahou je vzájemně izolovat jednotlivé transakce - chceme, aby nepotvrzené změny dat způsobené ostatními transakcemi byly v transakci neviditelné. Nevýhodou řešení založeném na zamykání (tabulek, stránek, řádků) jsou možné výkonnostní problémy. Řešením je MVCC architektura, kdy namísto zamknutí modifikovaného řádku (ať operací Update nebo Delete) se provede kopie řádku - vytvoří se nová verze. Český se MVCC architektura také označuje jako multigenerační. 
 
Nepotvrzené verze a přepsané verze se odstraňují až ve chvíli, kdy nejsou viditelné z žádné transakce. Neodstraňují se automaticky, je třeba spouštět příkaz VACUUM. Kromě odstranění nedostupných záznamů má příkaz VACUUM ANALYZE na starosti také aktualizaci statistik používaných plánovačem dotazů, a ochranu před přetečením identifikačních čísel transakcí (stabilní záznamy obdrží id 2, tj. FrozenXID).

Princip multigenerační architektury je jednoduchý. Každý řádek tabulky může v jednom okamžiku existovat v několika verzích (tuple), přičemž každá transakce vidí pouze jednu relevantní verzi každého řádku (tuple visibility). PostgreSQL implementuje tzv. nepřepisující systém ukládání (non-overwriting storage management), tj. nové verze řádků se zapisují na konec tabulky. Rušení starších, neplatných verzí je odloženo. Aktuálně se staré verze odstraňují příkazem VACUUM.

Každá verze řádku obsahuje několik stavových hodnot. Z nich nejdůležitější jsou xmin a xmax. xmin je číslo transakce, která je zodpovědná za vytvoření této verze řádku. xmax je číslo transakce zodpovědné za zrušení verze (UPDATE/DELETE). Platí, že verze je viditelná, tehdy pokud xmin je platné a xmax nikoliv. Platné, v tomto případě, znamená, že transakce daného čísla byla potvrzena nebo se jedná o aktuální transakci. Čísla potvrzených transakcí se ukládají do souboru pg_log. Při transakci typu SERIAL se navíc jako platné považují pouze ty transakce, které byly potvzeny před startem aktuální transakce (každá transakce si udržuje v paměti seznam potvrzených transakcí ostatních procesů, a  ty považuje za neplatné). Při tomto typu transakce se jako neplatná transakce považuje jakákoliv transakce s vyšším číslem transakce než aktuální transakce (jde o transakci, která zákonitě začala později).

== WAL ==
''Write Ahead logging''

Jedná se o obvyklý mechanismus zajištění transakcí, tj. datové soubory (tabulky a indexy) jsou modifikovány až poté, co byl pořízen záznam do logu. Díky tomu, že lze obsah databáze zrestaurovat z transakčního logu, není nutné vynucovat zápis na disk (fsync) datových souborů modifikovaných v transakci ve chvíli potvrzení transakce. Stačí fsync logu. Přínosem je:
* vyšší výkon - redukce fsynců, navíc možnost sdílení fsynců v konkurenčním prostředí, tj.  důsledkem potvrzení (COMMIT) více transakcí je jeden požadavek na fsync logu,
* skutečná konzistence datových stránek, před zavedením WAL mohlo dojít k poškození indexů případně tabulek bez možnosti rekonstrukce. Nyní se po restartu provádí automatická obnova datových stránek na základě jejich obsahu v logu,
* možnost online zálohování a obnovy k námi určenému okamžiku (PITR). Systém udržuje pouze několik posledních bloků (souborů) transakčního logu. Pokud je ale zálohujeme (provedeme jejich kopii), můžeme následně z těchto kopii rekonstruovat databázi (obdoba obnovy po pádu). Prvotní záloha nemusí být absolutně konzistentní (postačí kopie souborů svazku provedená za chodu).  Přehrávání logu (při obnově) můžeme zastavit v libovolném okamžiku před koncem logu (každá operace zapsaná v logu obsahuje časovou značku), např. těsně před okamžik, kdy byly odstraněny důležité tabulky nebo data (PITR).

== TOAST ==
''The Oversized Attribute Storage Technique''

PostgreSQL používá pro uložení dat stránky pevné velikosti (obvykle 8KB) a nepovoluje uložení záznamu do více tabulek. TOAST umožňuje větší položky komprimovat a rozdělit do více fyzických řádků, a to naprosto transparentně pro uživatele. TOAST se používá pouze pro tzv. varlena typy - první 4 byte obsahuje velikost včetně těchto 4 byte. Maximální velikost položky je omezena na 1 GB. TOAST určuje, zda-li bude hodnota uložena komprimovaně a zda-li bude uložena v tabulce, nebo mimo tabulku, resp. její soubor. Pokud je ukládána mimo tabulku, pak po případné komprimaci se rozdělí do přibližně 2KB bloků, které se každý uloží jako samostatný řádek v tabulce TOAST. Do původní tabulky se uloží pouze ukazatel. TOAST se aktivuje pouze v těch případech, kdy je skutečná šířka řádku větší než 2KB (při std. konfiguraci).

Limity
{|{{prettytable}}
|-
|Max. velikost tabulky || 32TB
|-
|Max. velikost řádku || 400GB
|-
|Max. velikost položky || 1GB
|-
|Max. počet sloupců || (250-1600)<br>v závislosti na typu
|}

K dispozici jsou čtyři základní strategie, jak PostgreSQL přistupuje k ukládání delších hodnot:

* PLAIN - hodnoty jsou uloženy vždy lokálně nekomprimovaně,
* EXTENDED - hodnota se nejdříve zkomprimuje, a pokud je řádek stále příliš dlouhý (nad 2KB), tak se uloží externě,
* EXTERNAL - v případě potřeby (délka řádku nad nad 2KB) se hodnota uloží externě nekomprimovaně,
* MAIN - hodnota se zkomprimuje, a pouze v případě, že řádek nelze uložit na jednu stránku (8KB) se uloží externě.

Pro většinu datových typů s pevnou délkou je výchozí strategie PLAIN, pro typy s variabilní délkou pak strategie EXTENDED.