Probíhající debata mezi SQL a NoSQL je stejně stará jako relační databázové systémy. Od roku 1970, kdy Edgar F. Codd představil koncept relační databáze, existuje v databázových systémech trvalé hluboké napětí mezi strukturou a flexibilitou. Databáze SQL si nárokují nadřazenost díky desetiletím prokázané spolehlivosti, silným zárukám ACID a výkonným možnostem dotazování, které jsou ideální pro komplexní relační datové modely. Naproti tomu databáze NoSQL tvrdí, že rigidní schémata nemohou držet krok s moderním vývojem a nabízet flexibilitu schémat, jednoduchý vývoj aplikací nebo lepší výkon pro vysokorychlostní nebo nestrukturovaná data.
Každý tábor si nárokuje dominanci – SQL pro konzistenci a integritu, NoSQL pro rychlost a agilitu – ale reálným trendem je konvergence, protože oba tábory stále více pracují na přebírání funkcí od toho druhého.
SQL a NoSQL: Konvergence do multimodelových databází
Multimodelové databáze jako MySQL, PostgreSQL a Oracle jsou v popředí integrace nerelačních funkcí do tradičně relačních systémů. Mezi nedávné inovace patří vektorové zpracování, funkce ukládání dokumentů a podpora kolekcí dokumentů JSON.
Tyto nové funkce vývojářům umožňují:
- Práce s dokumenty JSON pomocí známých rozhraní API pro dokumenty
- Dotazování a zpracování strukturovaných i polostrukturovaných dat pomocí SQL
- Kombinujte relační normalizaci s vývojem zaměřeným na dokumenty
Multimodelové databáze Podpora nativních API úložiště dokumentů
Všechny tyto multimodelové databáze zavedly binární formát pro nativní a optimalizované ukládání dat JSON. Patří sem i formát OSON od společnosti Oracle, který ve výzkumu prokázal výhody oproti BSON z hlediska výkonu a efektivity inkrementálních aktualizací.
Pro vývojáře, kteří hledají prostředí zaměřené na dokumenty, nabízejí dodavatelé API, která zpřístupňují nativní úložiště JSON, jako je například xDev API od MySQL, FerretDB založené na PostgreSQL nebo Oracle Database API pro MongoDB. Tato API poskytují jednoduchost vývoje NoSQL nad rámec relační infrastruktury. Vývojáři si užívají jednoduchosti a flexibility vývoje s flexibilním schématem, aniž by potřebovali speciální databázi úložiště dokumentů.
Na rozdíl od SQL však API pro úložiště dokumentů nejsou standardizována a zůstávají specifická pro daného dodavatele. Snahy o definování společného standardu probíhají, ale stále jsou v raných fázích.
Dotazování JSON pomocí SQL
Díky nativní podpoře JSON mohou vývojáři zacházet s kolekcemi dokumentů jako s prvotřídními součástmi databáze. Pomocí ANSI SQL/JSON (představeného v SQL:2016) můžete extrahovat hodnoty, odhnocovat pole, filtrovat dokumenty a aplikovat SQL funkce na obsah JSON. To propojuje relační a polostrukturovaná data prostřednictvím jednotného jazyka a otevírá dveře k využití síly SQL pro analytiku a reporting.
Zde je příklad, který dotazuje kolekci filmů ve formátu JSON, extrahuje atributy, agreguje hrubý příjem podle roku a vypočítává podíl na příjmech za každý rok:
S příjmy JAKO (
SELECT
m.data.year
, round(sum(JSON_VALUE(data,'$.gross' VRACÍ ČÍSLO NULL ON ERROR NULL ON EMPTY ))/1000000) jako miliony
FROM movies m
WHERE m.data.gross IS NOT NULL
GROUP BY m.data.year
)
SELECT year
, miliony
, ZAOKROUHLIT((POMĚR_K_VÝKAZU(miliony) PŘES ())*100,2) pct_revenue
FROM tržby r
WHERE rok > 2000
ORDER BY rok DESC;
Tento příklad používá jak operátor ANSI SQL/JSON JSON_VALUE, tak zjednodušenou tečkovou notaci Oracle , což je přímočarý způsob ve stylu SQL, jak extrahovat skalární hodnoty JSON z dokumentu JSON (m.data.year).
Vývojáři extrahují a „relacionalizují“ atributy uložené v dokumentech JSON, spojují tyto informace s relačními tabulkami a používají vnořené poddotazy nebo jiné konstrukce – stejným způsobem, jako používají jakýkoli dostupný operátor nebo funkci SQL pro relační objekty.
Zpřístupnění relačních dat jako dokumentů JSON
Naopak, relační data lze zpřístupnit jako dokumenty JSON pomocí zobrazení kolekcí JSON, což je zpřístupňuje aplikacím zaměřeným na dokumenty. Následující příklad vytváří zobrazení kolekce JSON nad tabulkou EMP v Oracle, pravděpodobně jednou z prvních relačních tabulek, které kdy byly vytvořeny pro demonstrační účely:
VYTVOŘENÍ NEBO NAHRADĚNÍ KOLEKCE JSON VIEW emp_collection AS
SELECT
JSON{‚_id‘ : empno,
‚employeeName‘ : ename,
‚jobRole‘ : job}
FROM emp;
Použití tohoto zobrazení kolekce prostřednictvím API úložiště dokumentů by vrátilo data podobná těmto:
json> db.emp_collection.findOne()
{ _id: 7369, jméno zaměstnance: ‚SMITH‘, pracovní role: ‚POŘADNÍK‘ }
Tato obousměrná flexibilita stírá hranice mezi SQL a NoSQL a odděluje způsob zpracování dat od způsobu jejich ukládání.
Více než duální přístup: Relační dualita JSON
Zatímco nativní binární úložiště JSON, API pro dokumenty a funkce SQL/JSON představují silný pokrok, relační dualita JSON posouvá věci o krok dále. Tato nová funkce nabízí to nejlepší z relačních i JSON dokumentů bez kompromisů obou modelů.
Stručně řečeno, duální zobrazení ukládají dokumenty JSON interně ve vysoce efektivním normalizovaném formátu s využitím relačních a JSON konstruktů. Zároveň vývojáři interagují s dokumenty JSON.
Duality Views – uložené jako řádky, vystavené jako dokumenty
Ať už aplikace používá REST nebo API zaměřená na dokumenty, vývojáři těží z jednoduchosti načítání a práce se všemi daty potřebnými pro jeden objekt na úrovni aplikace: dokument JSON. Vytvoření duálního zobrazení JSON je poměrně jednoduché. Stejně jako u zobrazení kolekce JSON vývojáři definují model objektového dokumentu pro obchodní objekt jako metadata v databázi.
Zde je jednoduchý příklad, který definuje duální pohled pro modelování harmonogramu konference pomocí GraphQL. Objekt schedule se skládá z:
Objekt rozvrhu se skládá z:
- Informace o účastníkovi.
- Harmonogram pro jednotlivého účastníka.
- Harmonogram představuje jednu nebo více lekcí, kterých se účastník plánuje zúčastnit.
- Podrobné informace o relaci, včetně informací o řečníkovi.
vytvořit nebo nahradit JSON Duality zobrazení ScheduleV
AS
attendee
{ _id : aid name : aname
schedule : schedule @insert @update @delete
{ scheduleId : schedule_id
sessions @unnest
{ sessionId : sid
name : name
location : room
speaker @unnest
{ speakerId : sid
speaker : name
}
}
}
} ;
Relační dualita JSON proto poskytuje výhody relačního modelu v oblasti úložiště, konzistence a efektivity, zatímco aplikace načítají a manipulují s hluboce vnořenými strukturami JSON.
To nejlepší z obou světů
Konvergence SQL a NoSQL umožňuje vývojářům těžit z jednoduchosti vývoje dokumentů JSON a síly relačních databází v jediné databázi. Multimodelové databáze eliminují potřebu vybírat si mezi jednotlivými paradigmaty a přebírají tak trh s jednoúčelovými NoSQL databázovými systémy. Vývojáři se nemusí muset rozhodovat mezi SQL a NoSQL systémy a uzavírat se do jednoho programovacího paradigmatu. Užívají si flexibility a svobody zvolit si nejlepší přístup pro jednotlivé aplikace, aniž by obětovali funkčnost.
Pohledy Oracle na relační dualitu JSON jdou nad rámec koexistence tím, že spojují silné stránky relačních a dokumentových modelů do jednotné architektury. Vzhledem k neustálému vývoji multimodelových systémů tento přístup vytváří přesvědčivý precedens – a další ho pravděpodobně budou následovat.
Pro více informací o produktech Oracle nás neváhejte kontaktovat.
Zdroj: Oracle
