Od děrných štítků k AI-nativním databázím

Od Hollerithových děrných štítků z roku 1890 po AI-nativní databáze počátku roku 2026 — jak se měnily modely ukládání dat a proč PostgreSQL ovládl trh za 150 miliard dolarů.

Databázové technologie prošly za více než století transformací od ručně děrovaných štítků k distribuovaným, AI-nativním systémům obsluhujícím miliardy uživatelů. Každý generační posun byl odpovědí na konkrétní technologické a obchodní limity předchozího modelu — od mechanických tabulátorů přes sekvenční zpracování na páskách, rigidní hierarchie, deklarativní SQL až po horizontálně škálovatelné NoSQL a zpět k distribuovanému SQL. V roce 2025 trh databází dosáhl hodnoty 150 miliard dolarů a směřuje k 329 miliardám do roku 2031, přičemž dominantními silami jsou konvergence SQL a NoSQL, vzestup vektorových databází pro AI a fenomenální růst PostgreSQL jako „univerzální databáze“.

Historie ukládání a zpracování dat začíná u problému amerického sčítání lidu. Sčítání 1880 trvalo osm let — při rostoucí populaci hrozilo, že výsledky sčítání 1890 nebudou hotové před dalším sčítáním v roce 1900. V roce 1888 vyhlásil Census Bureau soutěž o nejrychlejší metodu zpracování. Dva účastníci zpracovali testovací data za 144,5 a 100,5 hodiny. Třetí — Herman Hollerith (1860–1929), absolvent Columbia School of Mines a bývalý zaměstnanec Census Bureau — data zachytil za 72,5 hodiny a připravil je k tabulaci za pouhých 5,5 hodiny(oproti 44,5 a 55,5 hodiny konkurentů).

Hollerithův systém měl tři klíčové komponenty. Pantograf (děrovač) umožňoval operátorovi ručně přenášet data ze sčítacích archů na kartónové děrné štítky — každý otvor na přesně definované pozici reprezentoval konkrétní informaci (pohlaví, věk, rasa, stav, občanství). Tabulátor „četl“ štítky pomocí matice kovových jehel — když jehla prošla otvorem, kontaktovala rtuťovou vaničku pod kartou, čímž uzavřela elektrický obvod. Proud aktivoval elektromagnety na jednom ze 40 číselníků, každý s kapacitou 0–9 999. Zvonkem signalizované dokončení čtení karty upozornilo operátora k zápisu dat. Třídička(sorting box) automaticky otevřela správnou přihrádku pro zatřídění karty podle detekovaných kombinací otvorů.

Zkušený operátor zpracoval 80 karet za minutu. Celkem bylo pro sčítání 1890 vyděrováno přibližně 60 milionů karet. Výsledek: hrubý počet obyvatel pořízen za pouhých šest týdnů, kompletní populační tabulace dokončena za přibližně šest měsíců, detailní zpracování za dva roky (kompletní publikace cenzu trvala dalších několik let). Hollerithův systém ušetřil odhadem 5 milionů dolarů na mzdových nákladech oproti ručnímu zpracování (samotný census 1890 stál $11,5 milionu — téměř dvojnásobek cenzu 1880, ale při nesrovnatelně větším objemu zpracovaných dat). Hollerithova společnost Tabulating Machine Company (založena 1896) se v roce 1911 sloučila s dalšími firmami do Computing-Tabulating-Recording Company (CTR), přejmenované v roce 1924 na IBM.

Hollerithovy karty z roku 1890 měly formát 12 × 24 (12 řádků, 24 sloupců) s kulatými otvory. Postupně se formát rozrůstal — kolem roku 1910 na 45 sloupců. V roce 1928 IBM představilo revoluční 80-sloupcový formát s obdélníkovými otvory — karta měla rozměry přesně 7⅜ × 3¼ palce (187,325 × 82,55 mm), 80 sloupců a původně 10 číselných řádků (0–9); v roce 1930byly přidány dva „zónové“ řádky (11 a 12) pro kódování písmen a speciálních znaků, čímž vznikl definitivní formát 80 × 12. Jeden sloupec = jeden znak. Skupina po sobě jdoucích sloupců vyhrazená pro konkrétní účel (jméno, adresa, číslo zaměstnance) se nazývala pole (field). Karta s fixními identifikačními údaji pro skupinu karet byla master card, ostatní byly detail cards.

Tento formát dominoval průmyslu více než čtyři desetiletí. Ještě v polovině 50. let tvořily prodeje děrných štítků 20 % příjmů a 30 % zisku IBM. Dědictví přetrvalo dodnes — 80-znakový řádek v terminálech (IBM 3270) a programovacích konvencích (FORTRAN) je přímým pozůstatkem rozměru děrné karty.

Před érou elektronických počítačů existoval celý ekosystém elektromechanických strojů pro zpracování dat na děrných štítcích, souhrnně nazývaných unit record equipment(nebo tabelační stroje). Zásadní princip: jeden štítek = jeden záznam (unit record). Stroje zahrnovaly:

Zpracování bylo ryze dávkové a sekvenční: operátor připravil balíček karet (deck), vložil jej do stroje, ten je zpracoval jednu po druhé stanoveným pořadím. Pro složitější výpočty se výstupní balíček jednoho stroje stal vstupem dalšího — de facto pipeline zpracování, kde každá fáze odpovídala (v moderní analogii) SQL klauzuli: třídění = ORDER BY, výběr = WHERE, sumarizace = GROUP BY.

Čísla záznamů (sequence numbers) — typicky v posledních sloupcích karty (73–80) — sloužila k identifikaci pořadí v balíčku. Pokud operátor balíček upustil (což se stávalo), třídička jej setřídila zpět podle sekvenčních čísel. Tato konvence přežila v FORTRANu, kde sloupce 73–80 byly vyhrazeny pro sekvenční čísla a nebyly součástí programového kódu.

Veškeré ukládání a zpracování dat od 50. let dodnes probíhá v rámci von Neumannovy architektury — modelu popsaného v dokumentu „First Draft of a Report on the EDVAC“ (červen 1945), napsaném matematikem Johnem von Neumannem na základě diskusí s J. Presperem Eckertem a Johnem Mauchlym na University of Pennsylvania. Klíčový koncept: uložený program (stored program) — instrukce i data sdílejí stejnou paměť a jsou adresovatelné stejným mechanismem. Počítač se skládá z procesoru (aritmeticko-logická jednotka + řídící jednotka), paměti, vstupních a výstupních zařízení.

Tento model měl přímý dopad na vývoj datových médií, protože zavedl fundamentální rozlišení mezi:

Von Neumannovo úzké hrdlo (von Neumann bottleneck): protože instrukce i data sdílejí jedinou sběrnici mezi procesorem a pamětí, procesor je nucen čekat na data z paměti — a propast mezi rychlostí procesoru a rychlostí paměti se od 50. let neustále prohlubuje. Odpovědí se stala hierarchie pamětí — od nejrychlejších a nejdražších (registry CPU) přes stále pomalejší a levnější úrovně (cache → RAM → disk → páska → archiv). Každá technologie ukládání dat, o které tento dokument pojednává, je jednou vrstvou této hierarchie.

Magnetický buben (magnetic drum), vynalezený Rakušanem Gustavem Tauschkem v roce 1932, byl rotující kovový válec potažený feromagnetickým materiálem s řadou pevných čtecích/zápisových hlav — po jedné na každou stopu. Tauschkův prototyp uchovával 500 000 bitů (cca 62,5 KB). V 50. letech se magnetické bubny staly hlavní operační pamětířady počítačů — tyto stroje se příznačně nazývaly „drum computers“ nebo „drum machines“.

Nejznámějším příkladem je IBM 650 (1954) — první masově vyráběný počítač na světě (vyrobeno téměř 2 000 kusů). Jeho operační paměť tvořil magnetický buben s kapacitou 2 000 deseticiferných slov(cca 17,5 KB), později zdvojeno na 4 000 slov. Programátor musel při kódování zohledňovat rotační latenci bubnu — optimální umístění následující instrukce na tu pozici bubnu, která bude pod čtecí hlavou právě ve chvíli, kdy ji procesor potřebuje. Assembler SOAP (Symbolic Optimal Assembly Program) tuto optimalizaci prováděl automaticky. IBM 650 běžel na frekvenci 125 kHz a průměrná doba instrukce byla 27,6 ms (cca 40 instrukcí za sekundu).

Další drum computers zahrnovali ERA Atlas / UNIVAC 1101 (1950, vyvinutý pro kryptoanalýzu US Navy — ERA buben uchovával 16 384 slov), Manchester Mark 1, britský DEUCE (komerční verze Turingova návrhu ACE od English Electric) a japonský ETL Mark IV (1957).

Magnetické bubny jako hlavní paměť vytlačily v 60. letech feritové jádra (magnetic core memory, vyvíjená Jayem Forresterem na MIT v rámci projektu Whirlwind v letech 1949–1953) — první spolehlivá vysokorychlostní paměť s náhodným přístupem bez pohyblivých částí. Bubny pak přešly do role rychlé auxiliární paměti (swapping, paging) — dodnes existuje v BSD Unixu zařízení /dev/drumjako odkaz na tuto éru. Feritová jádra dominovala až do 70. let, kdy je nahradily polovodičové paměti DRAM (Intel 1103, 1970 — první komerční DRAM čip, 1 Kbit).

Vývoj datových médií přímo odráží vrstvy von Neumannovy hierarchie:

1940 — hlavní paměť: zpožďovací linky (rtuť); vnější paměť: žádná; archiv/vstup: děrné štítky, papírová páska.

1950 — hlavní: magnetické bubny; vnější: magnetické pásky; archiv: děrné štítky.

1960 — hlavní: feritová jádra; vnější: magnetické disky + pásky; archiv: děrné štítky (ústup).

1970— hlavní: DRAM (polovodiče); vnější: pevné disky; archiv: magnetické pásky.

1980–90 — hlavní: DRAM + cache (SRAM); vnější: HDD + SSD (nástup); archiv: pásky, optická média.

2000+ — hlavní: DRAM + L1/L2/L3 cache; vnější: SSD + HDD; archiv: pásky (LTO), cloud.

2020 — hlavní: DRAM + persistent memory; vnější: NVMe SSD + objektové úložiště; archiv: LTO-9/10, cold storage.

Klíčový vzorec: technologie, která v jedné éře slouží jako hlavní paměť, se v následující éře přesune na pozici vnější paměti nebo archivu. Magnetické bubny (50s hlavní → 60s auxiliární), feritová jádra (60s hlavní → 70s nahrazeny), magnetické disky (60s online storage → dnes stále secondary), magnetické pásky (50s primární storage → dnes archiv).

Databáze v každé éře optimalizují přístup k datům v kontextu aktuální vrstvy hierarchie. ISAM a B-stromy byly navrženy pro specifika rotujících disků (seek time + rotační latence), LSM-tree (RocksDB) pro SSD (náhodné zápisy → sekvenční), in-memory databáze (VoltDB, Redis) eliminují diskovou vrstvu úplně.

31. března 1951 přijal US Census Bureau první UNIVAC I (Universal Automatic Computer I) — první americký počítač navržený pro komerční zpracování dat, vyvinutý J. Presperem Eckertem a Johnem Mauchlym(tvůrci ENIACu).

Klíčovou inovací byl UNISERVO— první komerční páskový mechanismus. Médiem byl 0,5palcový pásek z niklovaného fosforového bronzu, dlouhý až 1 500 stop (457 m), s hustotou záznamu 128 znaků na palec na 8 stopách (6 datových + 1 paritní + 1 taktovací). Lineární rychlost 100 palců/s dávala nominální přenosovou rychlost 12 800 znaků/s (reálně cca 7 200 zn/s po započtení meziblokových mezer). Na jeden pásek se vešlo přibližně 1,44 milionu dekadických číslic. UNIVAC I mohl mít připojeno až 10 páskových jednotek a podporoval čtení i zápis v obou směrech — klíčová vlastnost pro efektivní třídění a slučování.

UNIVAC I se proslavil 4. listopadu 1952, kdy pro CBS správně předpověděl vítězství Eisenhowera v prezidentských volbách ze vzorku pouhých 5,5 % hlasů — miliony Američanů poprvé viděly elektronický počítač v akci (ve skutečnosti jen terminál v New Yorku, samotný stroj byl v Philadelphii).

V roce 1952 IBM následovalo s páskovou jednotkou 726pro počítač IBM 701 — ta již používala plastový pásek s feritoxidovým povlakem (vyvinutý firmou 3M podle specifikací IBM) a revoluční vakuový sloupec (vacuum column, patent Jamese Weidenhammera a Waltera Buslika) pro amortizaci rychlých rozběhů a zastavení pásky bez jejího přetržení. IBM 726 dosahovala hustoty 100 znaků/palec a rychlosti 75 palců/s. Plastový pásek a vakuový sloupec se staly průmyslovým standardem.

Data na pásce byla organizována do bloků (physical records) oddělených meziblokovou mezerou(inter-block gap, IBG) — typicky 0,6–0,75 palce prázdné pásky umožňující zastavení a rozběh mechanismu. Jeden blok obsahoval jeden nebo více logických záznamů (logical records). Počet logických záznamů v bloku se nazýval blokovací faktor(blocking factor) — vyšší faktor znamenal efektivnější využití pásky (méně mezer), ale vyžadoval větší vyrovnávací paměť (buffer).

Každý logický záznam měl pevnou délku (fixed-length record) definovanou v programu — například 80 bajtů (odpovídající jednomu děrnému štítku), 132 bajtů (šířka řádkové tiskárny) nebo jiná hodnota podle aplikace.

Záznamy v rámci souboru neměly jména, identifikovaly se pořadovým číslem (relative record number — pozice v sekvenci) nebo hodnotou klíčového pole (key field) — například číslem zaměstnance, číslem účtu nebo číslem dílu. Neexistovalo žádné schéma oddělené od programu — struktura záznamu (které bajty představují které pole) byla „zadrátována“ v COBOL DATA DIVISION, PL/I deklaraci struktury nebo v assemblerovém kódu každé aplikace. Změna formátu záznamu (přidání pole, změna délky) vyžadovala konverzi celé pásky a přepsání všech programů pracujících s daty.

Páskové soubory měly hlavičkový štítek (header label) na začátku obsahující identifikaci souboru, datum vytvoření, počet záznamů a další metadata, a koncový štítek (trailer label) s kontrolními součty. IBM standardizovalo formát štítků (Standard Labels) pro výměnu dat mezi instalacemi.

Magnetická páska je čistě sekvenční médium — pro přístup k záznamu uprostřed je nutné přetočit v průměru třetinu délky pásky, což trvá desítky sekund. Toto fundamentální omezení definovalo paradigma zpracování dat na celá dvě desetiletí:

Master file (hlavní soubor) obsahoval aktuální stav dat — například seznam všech zaměstnanců se mzdami, odpracovanými hodinami a srážkami. Byl seřazený podle klíčového pole (číslo zaměstnance). Transaction file (transakční soubor) obsahoval změny — nové záměstnance, výpovědi, úpravy adres, odpracované hodiny za období. Byl rovněž seřazený podle stejného klíčového pole.

Zpracování probíhalo sekvenčním sloučením(sequential merge/update): program četl synchronně oba soubory ze dvou páskových jednotek, porovnával klíče a vytvářel nový master file na třetí (výstupní) pásce:

Starý master file se uchovával jako záloha — vznikl tzv. generační princip (generation data groups, GDG): „děd“ (grandfather), „otec“ (father), „syn“ (son). Při selhání zpracování se výpočet zopakoval z předchozí generace master file. Celý master file se musel přepsat při každém zpracování, i když se měnil jen zlomek záznamů. Přímý přístup k jednomu záznamu neexistoval — pro zjištění stavu jednoho zaměstnance bylo nutné sekvenčně projít celou pásku. To bylo přijatelné pro dávkové zpracování (mzdy jednou týdně, fakturace jednou měsíčně), ale zcela nevhodné pro interaktivní dotazování.

Typická konfigurace vyžadovala minimálně 4 páskové jednotky: vstupní master, vstupní transakce, výstupní nový master a výstupní report/chybový protokol. Větší instalace měly 8–16 páskových jednotek pro paralelní zpracování a víceúrovňové třídění (merge sort na páskách vyžadoval minimálně 3 pásky pro dvoucestné slučování, optimálně 6+ pro vícecestné).

Přelom nastal v září 1956, kdy IBM představilo RAMAC 305 (Random Access Method of Accounting and Control) — první komerční pevný disk. Obsahoval 50 rotujících kotoučů o průměru 24 palců s kapacitou 5 milionů znaků (cca 5 MB). Přístupová doba byla 600 ms — pomalá z dnešního pohledu, ale revolučně rychlá oproti minutám přetáčení pásky. Poprvé bylo možné přímo přistoupit k jednomu záznamu bez sekvenčního procházení celého souboru.

To otevřelo cestu novým přístupovým metodám:

Existence disků umožnila přechod od čistě dávkového zpracování k online zpracování (OLTP) — koncový uživatel u terminálu mohl zadat dotaz a dostat odpověď v sekundách, nikoli čekat na noční dávku. Tato potřeba přímého přístupu k datům a jejich sdílení mezi aplikacemi vytvořila poptávku po systémech řízení báze dat (DBMS).

Pojem „data-base“ se poprvé objevil v technickém smyslu v roce 1962 ve zprávě System Development Corporation v Kalifornii. V 60. letech měla každá aplikace vlastní soubory ve vlastním formátu — data redundancy (stejná data uložena vícekrát v různých souborech), data inconsistency (po aktualizaci jedné kopie zůstaly ostatní zastaralé), absence sdílení dat mezi aplikacemi, žádný dotazovací jazyk, žádné zajištění integrity. Změna struktury souboru vyžadovala přepsání všech programů, které s ním pracovaly. Tato situace vyvolala potřebu centralizovaného řízení dat — systému řízení báze dat (DBMS).

Hierarchický databázový model vznikl z konkrétní praktické potřeby. V květnu 1961 prezident Kennedy vyhlásil program Apollo; raketa Saturn V měla odhadem přes 3 miliony komponent, jejichž sledování bylo nad možnosti souborových systémů. V roce 1963 zahájily IBM a North American Aviation (později Rockwell) spolupráci na sledování dílů (formální partnerství uzavřeno v roce 1965) a s účastí firmy Caterpillar (jako raného komerčního uživatele) vyvinuly systém ICS/DL/I — tým tvořilo 12 vývojářů z IBM, 10 z Rockwellu a 3 z Caterpillaru. 14. srpna 1968 zobrazil systém první zprávu „READY“ v NASA Downey v Kalifornii. V roce 1969 byl přejmenován na IMS/360 a uveden na trh. Hlavním architektem byl Vern Watts, neformálně nazývaný „otec IMS“.

IMS organizuje data do stromové struktury — každý databázový záznam se skládá z kořenového segmentu a jeho podřízených segmentů, hierarchie může mít až 15 úrovní a 255 typů segmentů. Programátoři přistupují k datům prostřednictvím jazyka DL/I(Data Language/Interface) pomocí volání jako GU (Get Unique), GN (Get Next), ISRT (Insert) nebo DLET (Delete). Pohled aplikace na databázi definuje PCB (Program Communication Block) se specifikací citlivých segmentů a povolených operací. Fyzickou strukturu popisuje DBD (Database Description).

Silné stránky IMS — extrémní výkon pro předdefinované přístupové vzory, vestavěná obnova a integrita — zajistily jeho přežití dodnes. V roce 2003 měl IMS svůj nejúspěšnější obchodní rok (35 let po uvedení) a k roku 2022 jej stále používalo 95 % společností Fortune 1000. Slabinou byl rigidní strom: každé dítě mohlo mít pouze jednoho rodiče, neexistovaly ad hoc dotazy a změna datové struktury vyžadovala přeprogramování aplikací.

Paralelně s IMS vznikal síťový model. Charles W. Bachman v letech 1961–1963 ve společnosti General Electric vyvinul Integrated Data Store (IDS) — považovaný za první univerzální systém řízení báze dat(DBMS). Na rozdíl od hierarchického modelu IDS organizoval data do grafové struktury s ukazatelovými řetězci — záznam mohl být členem více množin (setů), čímž se přirozeně modelovaly vztahy many-to-many. Bachman rovněž zavedl Bachmanovy diagramypro vizuální reprezentaci datových struktur.

Za svůj přínos obdržel Bachman v roce 1973 Turingovu cenu — byl prvním laureátem bez Ph.D. a prvním s celou kariérou v průmyslu. Jeho přednáška „The Programmer as Navigator“ definovala pojem navigační databáze: programátor se pohybuje (naviguje) databází prostřednictvím ukazatelů.

Standardizační úsilí převzal CODASYL (Conference on Data Systems Languages), původně založený v roce 1959 pro vývoj COBOLu. V roce 1965 vznikla List Processing Task Force, přejmenovaná v roce 1967 na Data Base Task Group (DBTG). Klíčový DBTG Report z dubna 1971definoval architekturu síťové databáze a zavedl pojmy používané dodnes: DDL (Data Definition Language), DML (Data Manipulation Language), schéma a podschéma, datová nezávislost. Síťový model implementovaly produkty jako IDMS(Cullinet/CA, pro mainframy IBM — v roce 2000 stále běžel na více než 1000 mainframech), IDS/2 (Honeywell), DMS-1100 (Univac) či HP IMAGE.

Nevýhodou síťového modelu byla složitost — programátor musel explicitně procházet ukazatelové řetězce záznam po záznamu, bez deklarativního dotazovacího jazyka. Absence matematického základu znemožňovala automatickou optimalizaci přístupových cest. Právě tyto nedostatky přišel relační model řešit.

Edgar Frank „Ted“ Codd(1923–2003), britský počítačový vědec pracující v IBM San Jose Research Laboratory, publikoval v červnu 1970 článek „A Relational Model of Data for Large Shared Data Banks“ v Communications of the ACM (roč. 13, č. 6, s. 377–387). Článek prezentoval radikálně nový přístup: data se organizují jako matematické relace (množiny n-tic), reprezentované jako tabulky s řádky a sloupci. Klíčové přínosy zahrnovaly datovou nezávislost (nezávislost aplikací na fyzickém uložení), relační algebru pro formální manipulaci s daty a eliminaci navigačního přístupu.

V roce 1971 Codd doplnil teorii o normální formy (1NF, 2NF, 3NF), v roce 1974 spolu s Raymondem Boycem definovali BCNF (Boyce-Coddovu normální formu). Ronald Fagin později přidal 4NF (1977) a 5NF(1979). Codd obdržel Turingovu cenu v roce 1981 a v roce 1985 publikoval slavných 12 pravidel (ve skutečnosti 13, číslovaných 0–12) definujících, co je skutečně relační databáze — žádný komerční systém je dodnes plně nesplňuje.

Přelomovým momentem byl debata Bachman–Codd na konferenci SIGFIDET v Ann Arbor v roce 1974 — před ní byl síťový model mainstreamem a relační přístup „vyzyvatelem”; po ní se trend začal obracet.

System R (1973–1979) vznikl v IBM San Jose Research Lab — tým asi 15 lidí zahrnoval Dona Chamberlina a Raymonda Boyce, kteří navrhli jazyk SEQUEL(později přejmenovaný na SQL kvůli ochranné známce Hawker Siddeley). Patricia Selingerová vyvinula průlomový optimalizátor dotazů založený na nákladech — techniku, kterou používají všechny moderní databáze. Jim Grayformalizoval koncepty serializovatelnosti, dvoufázového zamykání a transakčního zpracování. Paradoxně IBM izolovalo vývojový tým od Codda — nepoužili jeho jazyk Alpha, ale vytvořili vlastní SQL.

INGRES (1973–1979) na UC Berkeley vedli Michael Stonebraker a Eugene Wong — nikdy neměl více než 5–6 programátorů, běžel na PDP-11 pod UNIXem a používal jazyk QUEL. QUEL byl považován za matematicky čistší alternativu SQL, ale SQL zvítězil díky snazší čitelnosti. Oba projekty získaly v roce 1988 ACM Software Systems Award a prokázaly praktickou životaschopnost relačního modelu.

SQL-86 (1986, 120 stran) — SELECT, INSERT, UPDATE, DELETE, GROUP BY, subqueries. SQL-89(1989) — PRIMARY KEY, FOREIGN KEY, CHECK, vazby pro C a Ada. SQL-92(1992, 579 stran) — explicitní JOIN syntaxe, CASE, DATE/TIME, ALTER, DROP. SQL:1999 (1999, modulární) — CTE, rekurzivní dotazy, triggery, UDT, BOOLEAN, ROLLUP/CUBE. SQL:2003 (2003) — window funkce, XML, MERGE, SEQUENCE, MULTISET. SQL:2011(2011) — temporální tabulky (system-versioned). SQL:2016(2016) — JSON podpora, MATCH_RECOGNIZE, polymorfní tabulkové funkce. SQL:2023 (2023) — SQL/PGQ (property graph queries), rozšířený JSON, GREATEST/LEAST.

SQL:2023, přijatý v červnu 2023, přináší novou část 16 — SQL/PGQ — umožňující dotazování relačních dat jako grafů. Tím se SQL standard formálně přibližuje grafovým databázím a redukuje potřebu specializovaných grafových systémů.

Larry Ellison v roce 1977 založil Software Development Laboratories (později Oracle) po přečtení veřejně dostupných článků o System R. Oracle V2vyšel v roce 1979 jako první komerčně dostupný SQL RDBMS. IBM uvedlo SQL/DS v roce 1981 a DB2 v roce 1983.

PostgreSQL se vyvíjel z akademického INGRES přes Stonebrakerův projekt POSTGRES (1986) a Postgres95 (1994, kdy Andrew Yu a Jolly Chen přidali SQL) po přejmenování v roce 1996 — dnes je jednou z nejpopulárnějších databází na světě. MySQL vytvořili Michael „Monty“ Widenius a David Axmark, první vydání proběhlo 23. května 1995; v roce 2008 jej Sun Microsystems koupil za 1 miliardu dolarů, v roce 2010 přešel pod Oracle a Widenius odpověděl forkem MariaDB.

Microsoft SQL Server vznikl z partnerství s Sybase(1988); kód z Sybase byl kompletně přepsán až v SQL Server 2005. SQLite, vytvořený D. Richardem Hippem v roce 2000 pro americké námořnictvo (systém řízení poškození na torpédoborci USS Oscar Austin), je dnes nejrozšířenější databází na světě — běží na miliardách zařízení.

Akronym ACID vytvořili Theo Härder a Andreas Reuterv článku z roku 1983 „Principles of Transaction-Oriented Database Recovery“. Stavěli na práci Jima Graye, který v roce 1981 pojmenoval atomicitu, konzistenci a trvalost (ale ne izolaci). Gray — držitel Turingovy ceny 1998 — formalizoval serializovatelnost, dvoufázové zamykání, Write-Ahead Logging (WAL) a dvoufázový commit. Tyto koncepty zůstávají základem transakčního zpracování dodnes. Zajímavostí je, že IMS od IBM podporoval ACID transakce už od roku 1973 — deset let před vznikem akronymu.

Objektově orientované databáze (OODBMS) se pokusily vyřešit takzvaný impedanční nesoulad(impedance mismatch) — fundamentální koncepční propast mezi objektově orientovaným programováním (objekty, metody, dědičnost, grafy referencí) a relačním modelem (tabulky, řádky, joiny, SQL). Standard ODMG (Object Data Management Group), založený v létě 1991 z iniciativy Ricka Cattella ze Sun Microsystems s pěti klíčovými výrobci OODBMS, definoval objektový model, dotazovací jazyk OQL a vazby pro C++, Smalltalk a Javu. Vyšlo pět revizí (ODMG 1.0 v 1993 až ODMG 3.0 v 2000), skupina se poté rozpustila.

Klíčové produkty zahrnovaly ObjectStore (Object Design, Inc., silný v CAD/telco), Versant(telecom, finance, obrana), GemStone/S (Smalltalk, pojišťovnictví, doprava), db4o (open-source Java/C#) a InterSystems Caché — komerčně nejúspěšnější OODBMS, dominující ve zdravotnictví. OODBMS se prosadily v CAD/CAM, telekomunikacích, vědeckém výpočetnictví a zdravotnictví, ale masového rozšíření nedosáhly.

Důvody neúspěchu byly mnohočetné: vazba na konkrétní kompilátor (různé C++ kompilátory ukládaly objekty v nekompatibilních formátech), absence univerzálního dotazovacího jazyka srovnatelného s SQL, slabá podpora ad hoc dotazů a reportingu, fragmentace trhu mezi desítku malých dodavatelů bez podpory velkých hráčů (Oracle, IBM zůstali u relačního modelu) a obrovské existující investice organizací do relačních databází. Přibližně 70 % příjmů OODBMS tvořily profesionální služby, což naznačovalo silnou závislost na dodavateli.

Úspěšnějším řešením impedančního nesouladu se stal objektově-relační model, který rozšířil existující SQL a relační základy o objektové prvky. Klíčovým příkladem je PostgreSQL, přímo navazující na Stonebrakerův projekt POSTGRES (1986), jehož cílem bylo přidat k relačnímu modelu uživatelsky definované datové typy, dědičnost a rozšiřitelnost.

Standard SQL:1999 formálně zakotvil uživatelsky definované typy (UDT), typovou dědičnost, referenční typy (REF), kolekce (pole, multisety) a uložené procedury. Oracle, IBM DB2 i SQL Server implementovaly objektově-relační rozšíření s různou mírou shody se standardem. Zásadní výhodou byla zpětná kompatibilita — organizace mohly přidávat objektové prvky postupně, aniž by opouštěly relační základ a investice do SQL.

Exploze webu 2.0 v polovině 2000. let přinesla objem, rozmanitost a rychlost dat přesahující možnosti tradičních RDBMS. Tři technické články z Googlu a Amazonu změnily paradigma: Google MapReduce (2004, Jeffrey Dean a Sanjay Ghemawat) — model pro paralelní zpracování; Google Bigtable (2006) — sloupcový distribuovaný systém inspirující HBase a Cassandru; a Amazon Dynamo (2007) — master-less key-value store s konzistentním hashováním a eventuální konzistencí, inspirující Riak a DynamoDB.

Termín „NoSQL“ v moderním smyslu vznikl 11. června 2009, když Johan Oskarsson z Last.fm potřeboval krátký hashtag pro setkání v San Franciscu věnované „open-source distribuovaným, nerelačním databázím“ — na IRC kanálu #cassandra někdo navrhl „NoSQL“. Označení nemělo přetrvat, ale virálně se rozšířilo. Později se ustálil výklad „Not Only SQL“.

Eric Brewer z UC Berkeley představil svou domněnku na keynotu konference PODC v červenci 2000 v Portlandu: distribuovaný datový systém může současně zaručit nejvýše dva ze tří vlastností — konzistenci (každé čtení vrací nejnovější zápis), dostupnost (každý požadavek na funkční uzel dostane odpověď) a toleranci k rozdělení sítě (systém funguje i při výpadku komunikace mezi uzly). V roce 2002 Seth Gilbert a Nancy Lynch z MIT publikovali formální důkaz. Protože síťová rozdělení jsou v distribuovaných systémech nevyhnutelná, reálná volba je mezi CP(konzistence + tolerance) a AP (dostupnost + tolerance).

Key-Value stores nabízejí nejjednodušší model — klíč mapovaný na hodnotu. Redis(REmote DIctionary Server), vytvořený Salvatorem Sanfilippema vydaný open-source 10. dubna 2009, podporuje bohaté datové struktury v paměti (řetězce, hashe, seznamy, seřazené množiny). Amazon DynamoDB (cloud služba od 2012) nabízí plně spravovaný key-value/document store. Tyto systémy excelují v cachování, správě sessions a real-time leaderboardech.

Document stores ukládají polostrukturovaná data jako dokumenty (typicky JSON/BSON). MongoDB(vývoj od 2007 ve firmě 10gen, první veřejné vydání 2009) se stal nejpopulárnějším — ukládá dokumenty v BSON, podporuje dynamické schéma, sharding a od verze 4.0 (2018) i multi-dokumentové ACID transakce. Apache CouchDB, vytvořený Damienem Katzem v dubnu 2005 (původně v C++, přepsaný do Erlangu v roce 2006), nabízí RESTful API a multi-master replikaci pro offline-first scénáře.

Column-family (široké sloupce)kombinují přístupy BigTable a Dynamo. Apache Cassandra, původně vyvinutá na Facebooku v roce 2008 pro vyhledávání v příchozí poště (Avinash Lakshman a Prashant Malik), spojuje Bigtable datový model s Dynamo architekturou bez master uzlu. Je AP systémem s laditelnou konzistencí. HBase je open-source implementace BigTable nad Hadoopem (CP systém). ScyllaDBje přepis Cassandry v C++, eliminující pauzy garbage collectoru JVM.

Grafové databáze modelují data jako uzly a hrany. Neo4j, konceptualizovaný kolem roku 2000 Emilem Eifremem ve Švédsku (verze 1.0 v únoru 2010), používá property graph model a dotazovací jazyk Cypher. Proslavil se analýzou Panama Papers v roce 2016. V červnu 2021 dosáhl valuace přes 2 miliardy dolarů.

NoSQL systémy často pracují s modelem BASE — Basically Available (systém odpovídá i při částečných výpadcích), Soft state (stav se může měnit v čase i bez vnějšího vstupu), Eventually consistent (po rozšíření všech aktualizací se repliky shodnou). Akronym BASE byl záměrně zvolen jako protiklad ACID (zásada vs kyselina v chemii). Dan Pritchett z eBay jej popularizoval v článku pro ACM Queue v roce 2008. ACID je vhodný pro finanční systémy a zdravotnictví, kde je integrita dat kritická; BASE pro sociální sítě a e-commerce ve velkém měřítku, kde je prioritou dostupnost.

Termín NewSQL vytvořil Matthew Aslett z 451 Research 6. dubna 2011 jako zkratku pro nové škálovatelné SQL databáze, které kombinují ACID záruky tradičních RDBMS s horizontální škálovatelností NoSQL.

Google Spanner, popsaný v článku na OSDI 2012, představuje přelomový systém — první globálně distribuovanou databázi se silnou konzistencí. Klíčovou inovací je TrueTime API využívající GPS přijímače a atomové hodiny v každém datacentru k poskytování globálně synchronizovaných časových razítek s omezenou nejistotou (typicky pod 10 ms). Spanner dosahuje externální konzistence — nejsilnější konzistenční vlastnosti pro transakční systémy — prostřednictvím commit-wait fáze, kdy čeká, až TrueTime potvrdí, že přidělené časové razítko je v minulosti. Pohání Gmail, YouTube a je dostupný jako Google Cloud Spanner.

CockroachDB, založený v roce 2015 ex-Googláky Spencerem Kimballem, Peterem Mattisem a Benem Darnerem (všichni pracovali s Bigtable/Spanner), nabízí distribuovanou SQL databázi s PostgreSQL wire protokolem — dosahuje podobné konzistence jako Spanner, ale bez specializovaného hardware (používá hybridní logické hodiny).

TiDB od PingCAP (2015) je MySQL-kompatibilní s dvouvrstvou architekturou (SQL vrstva + TiKV storage s Raft konsenzem) a podporou HTAP díky sloupcovému enginu TiFlash. VoltDB, komercionalizace výzkumného projektu H-Store pod vedením Michaela Stonebrakera (Turingova cena 2014), je in-memory ACID databáze dosahující 3 milionů transakcí za sekundu na 384 jádrech díky eliminaci zamykání, WAL a buffer pool managementu.

Do roku 2025 se termín NewSQL z velké části transformoval na „Distributed SQL“ — průzkum 451 Research ukázal, že 58 % IT rozhodovatelů očekávalo nasazení globálně distribuované databáze do jednoho roku.

Obecné RDBMS mohou modelovat časové řady, ale nejsou optimalizovány pro trvalý vysokofrekvenční příjem dat ani rozsáhlé analytické skeny. InfluxDB (2013, InfluxData) používá TSM engine (Time-Structured Merge Tree) a ve verzi 3.0 přešel na sloupcovou architekturu s Apache Arrow a Parquet. TimescaleDB (2017) je rozšíření PostgreSQLzavádějící koncept hypertabulek — automatické particionování časových dat do chunků. V červnu 2025 se mateřská společnost Timescale přejmenovala na TigerData. QuestDB, napsaný v low-latency Javě, C++ a Rustu, v benchmarcích dosahuje 12–36× vyššího výkonu než InfluxDB 3 Core pro příjem dat a 43–418× rychlejší analytické dotazy. Typická nasazení zahrnují IoT, monitoring infrastruktury a finanční tržní data.

Vektorové databáze ukládají vysokodimenzionální vektorové embeddingy (numerické reprezentace textu, obrázků, zvuku) a provádějí přibližné vyhledávání nejbližších sousedů (ANN). Klíčové indexovací struktury zahrnují HNSW (Hierarchical Navigable Small World — grafový algoritmus s logaritmickou složitostí) a IVF (Inverted File Index — shlukování vektorů). Trh vektorových databází vzrostl z 1,73 miliardy USD v roce 2024 na projektovaných 10,6 miliardy do 2032.

Pro RAG (Retrieval-Augmented Generation) jsou vektorové databáze nezbytné: obsah se rozloží na segmenty, převede na vektorové embeddingy, uloží do databáze a při dotazu se sémantickým vyhledáváním najdou relevantní fragmenty pro obohacení odpovědi LLM.

Klíčové produkty:

V roce 2025 se vektorové vyhledávání stalo komoditní funkcí — tradiční databáze (PostgreSQL, MongoDB, Oracle, Elasticsearch) ho integrují nativně. Článek VentureBeat z listopadu 2025 konstatoval, že dedikované vektorové databáze ztrácejí diferenciaci, protože vektorový index se stává jen dalším typem indexu vedle B-tree a GIN/GiST.

SQLite zůstává nejrozšířenější databází na světě s miliardami instancí — běží v každém smartphonu (Android i iOS), prohlížeči, IoT zařízení. Její design „celá databáze v jednom souboru“ je ideální pro embedded a edge scénáře.

DuckDB, vytvořený v roce 2018 Markem Raasveldem a Hannesem Mühleisenem na CWI v Amsterdamu (Centrum Wiskunde & Informatica — instituce, kde vznikl MonetDB a kde Guido van Rossum vytvořil Python), představuje revoluci v analytice. Je to „SQLite pro analytiku”— in-process OLAP databáze se sloupcovým uložením a vektorizovaným zpracováním dotazů. DuckDB je 10–50× rychlejší než SQLite pro analytické dotazy, přímo čte Parquet, CSV, JSON i Arrow soubory bez importu, a běží kdekoli — od Jupyter notebooku po WebAssembly v prohlížeči. V roce 2025 dosáhl 6 milionů PyPI stažení měsíčně. Benchmark DuckDB 1.4 ukázal 100× zrychlení oproti Apache Spark pro typické BI dotazy na středních datasetech.

RocksDB (Meta/Facebook) je embeddovaný key-value store založený na LSM-tree (Log-Structured Merge Tree), optimalizovaný pro SSD s vysokou propustností zápisů. Není databází pro koncové uživatele, ale storage enginempoužívaným uvnitř jiných databází — TiKV (pod TiDB), CockroachDB, YugabyteDB a mnohých dalších.

ArangoDB kombinuje document + graph + key-value v jednom enginu s jednotným dotazovacím jazykem AQL. SurrealDB (Rust, 44 milionů USD financování) se pokouší o nejambicióznější integraci — relační, dokumentový, grafový, time-series, key-value i vektorový model v jednom. Na opačném konci spektra stojí varovný příběh FaunaDB — multimodel serverless databáze, která 30. května 2025 ukončila provoz. Fauna ve svém zenitu tvrdila, že ji používá přes 80 000 vývojářských týmů; při uzavření služby musely stovky platících zákazníků a tisíce týmů urgentně migrovat. Tento incident podtrhl riziko vendor lock-in u proprietárních cloudových databází.

Serverless model přesouvá správu infrastruktury kompletně na poskytovatele — uživatel platí jen za spotřebu, databáze se automaticky škáluje včetně škálování na nulu.

Výsledky Stack Overflow Developer Survey 2025: 55,6 % vývojářů používá PostgreSQL (nejvyšší podíl ze všech databází, třetí rok #1 v kategoriích „most used“, „most loved“ i „most wanted”), MySQL 40,5 %. Rok 2025 přinesl bezprecedentní vlnu akvizic v PostgreSQL ekosystému:

PostgreSQL 18 (vydán 25. září 2025) přinesl zásadní technické vylepšení: asynchronní I/O subsystém (AIO) dramaticky zrychlující sekvenční skeny a checkpointing, skip scans pro efektivnější využití multi-column indexů, vylepšení optimalizátoru dotazů a rozšířenou podporu JSON.

Síla PostgreSQL spočívá v jeho ekosystému rozšíření— PostGIS (geoprostorová data), pgvector (vektorové embeddingy), Citus (horizontální škálování), TimescaleDB (časové řady), pg_duckdb (OLAP analytika), ParadeDB (full-text search s BM25) — díky nimž jedna databáze pokrývá OLTP, OLAP, vektory, grafy, geoprostorová i časová data. Otázka roku 2025 už nezní „relační, nebo nerelační?“, ale „které rozšíření potřebuji?“.

DuckDB zaznamenal v DB-Engines žebříčku skok z pozice #81 na #51 s 50,7% meziročním růstem — nejrychleji rostoucí databáze v žebříčku. Klíčové milníky:

DuckDB se v roce 2025 etabloval jako klíčový hráč analytického ekosystému — inspiroval novou vlnu „in-process“ analytických nástrojů a jeho adopce stále akceleruje.

Lakehouse architektura, kde se data ukládají v otevřených formátech na objektovém úložišti (S3/GCS/ADLS) s ACID transakčními garancemi, se v roce 2025 stala mainstreamem. „S3 je nový disk“ — tento výrok shrnuje posun od proprietárních storage enginů k komoditnímu objektovému úložišti.

Tři hlavní otevřené tabulkové formáty:

Konvergence se streamovacími systémy (Kafka + Flink → Iceberg) umožňuje budovat real-time lakehouse — data proudí z operačních systémů přes streaming platformu přímo do Iceberg tabulek, kde jsou okamžitě dostupná pro analytické dotazy.

Rok 2025 přinesl zásadní posun v tom, jak databáze interagují s AI systémy:

Oracle AI Database 26ai (říjen 2025) zavedl koncept „Select AI Agent“ — AI agenty jako „občany první třídy“ databáze, kteří mohou autonomně generovat a spouštět SQL dotazy, optimalizovat schémata a odpovídat na otázky v přirozeném jazyce přímo nad databází.

Google Cloud představil HTAP+V— konvergenci transakčního, analytického a vektorového zpracování v jedné databázi. TiDB (PingCAP) se začal pozicionovat jako „AI-nativní databáze pro miliony autonomních agentů“ — každý agent má vlastní context window obohacený o strukturovaná i nestrukturovaná data z TiDB.

Klíčovou inovací roku 2025 se stal Model Context Protocol (MCP) — otevřený standard pro připojení AI agentů k datovým zdrojům, popisovaný jako „nové ODBC pro éru AI“. MCP definuje standardizované rozhraní, přes které AI modely přistupují k databázím, API a dalším datovým zdrojům bez nutnosti specifické integrace pro každý systém. Ke konci roku 2025 MCP podporovaly Oracle, Databricks, Snowflake a desítky dalších platforem.

Článek VentureBeat z ledna 2026 konstatoval, že „RAG je mrtvý ve své původní podobě“ — jednoduchá pipeline architektura (chunk → embed → retrieve → generate) je nahrazována agentickými paměťovými systémy, kde AI agenti autonomně rozhodují, kdy a jak přistupovat k datovým zdrojům, kombinují vektorové vyhledávání s SQL dotazy a udržují si persistentní paměť napříč sezeními.

Herman Hollerith (1860–1929) — děrný štítek, tabulátor, zakladatel firmy → IBM.

Edgar F. Codd (1923–2003) — relační model (1970), normální formy, 12 pravidel. Turingova cena 1981.

Charles W. Bachman (1924–2017) — IDS (první DBMS), síťový model, CODASYL DBTG. Turingova cena 1973.

Michael Stonebraker (1943–) — INGRES, POSTGRES/PostgreSQL, VoltDB. Turingova cena 2014.

Jim Gray (1944–2007*) — System R, transakční teorie (serializovatelnost, WAL, 2PC). Turingova cena 1998.

Patricia Selinger — cost-based query optimizer (System R). ACM Fellow.

Eric Brewer (1966–) — CAP teorém (2000), Google infrastruktura. ACM Prize 2009.

Don Chamberlin (1944–) — spolutvůrce SQL (SEQUEL, 1974). ACM Fellow.

*Jim Gray zmizel při plavbě u San Franciska v lednu 2007, prohlášen za mrtvého v roce 2012.

Historie databázových modelů odhaluje opakující se vzorec: každá generace řeší nedostatky předchozí, ale zavádí vlastní kompromisy:

1. Konvergence modelů. Hranice mezi SQL, NoSQL, grafovými a vektorovými databázemi se rozpouštějí. PostgreSQL s rozšířeními pokrývá téměř všechny scénáře použití. SQL:2023 s SQL/PGQ přináší grafové dotazování do relačního světa.

2. Data jako infrastruktura pro AI.Vektorové vyhledávání se stalo komoditou. MCP nahrazuje ODBC jako standardní rozhraní. Databáze se transformují ze „systémů záznamu“ (systems of record) na „systémy uvažování“ (systems of reasoning).

3. Decentralizace výpočtu. Edge databáze (Turso, D1), in-process analytika (DuckDB), lakehouse formáty (Iceberg, DuckLake) přesouvají zpracování blíže k datům a uživatelům. Streaming a batch zpracování konvergují.

Databáze roku 2026 už není jeden produkt, ale ekosystém vzájemně propojených vrstev:

Vývojář na počátku roku 2026 nevolí mezi relační a nerelační databází — volí, které rozšíření přidá do PostgreSQL a které vrstvy ekosystému propojí.

Metodická poznámka

Koncepce, struktura a redakční linie článku jsou dílem autora, který vypracoval obsahovou skicu, stanovil klíčové teze a řídil celý proces tvorby. Generativní AI (Claude, Anthropic) byla využita jako technický nástroj pro rešerši, ověřování faktů a rozepsání autorovy předlohy.

Autor výstupy průběžně redigoval, ověřil klíčová zjištění a schválil finální znění. Žádná část textu nebyla publikována bez lidské kontroly. Všechny faktické údaje byly ověřeny proti veřejně dostupným zdrojům uvedeným v textu.

Postup je v souladu s požadavky Čl. 50 Nařízení EU 2024/1689 (AI Act) na transparentnost AI-generovaného obsahu. #poweredByAI