Datový sloupec JSON v MySQL

Ahoj, jak se stavite k datovym formatum JSON v MySQL pripadne i jinych dtb technologiich? Ja jsem to zacal pouzivat misto N:M propojovacich tabulek a prijde mi, ze to funguje docela svizne. Uznavam, ze zatim nikde nemam stovky tisic zaznamu, abych mohl porovnat datove zatizeni a hlavne casy jendotlivych dotazu, ale zatim jsem spokojeny. Prijde mi, ze JSON sloupce jsou na tohle docela sikovne, protoze usetri hodne radku. Samozrejme pak rostou objemy zaznamu v radku. Ale jak rikam, zatim to nikde nemam u milionu zaznamu, atd. Chci ovsem urcite otestovat.

kvoli tomu ze sa uz par rokov babrem s event sourcingom a cqrs tak som zacal pouzivat taky model ze v jednej tabulke mam serializovane objekty ako mediumblob(mysql), kludne to moze byt json, a vsetky ostatne tabulky su len indexy, co je myslim presne to co popisujes. vyhoda je taktiez ze tie tabulky mozes navrhnut na mieru logike systemu, cize mozes mat komplexne indexy bez dodatocnych joinov napriklad, pripadne ak robis s kompilovanym jazykom, tak to de facto mozes previest to kvdb a menezovat to cele v jednej binarke bez zavyslosti na externej sluzbe ako mysql, mongo... samozejme ak mas velke entity, pripadne malokedy vyuzivas vsetky polia na entitach tak to nie je idealne lebo potom zbytocne mas overhead de/serialziacie a datoveho prenosu dat ktore nepouzivas. len potom ide skor o DX nez UX(ie. mozno tam pridas par milisekund na response time ale zase je kod jendoduchsi/lepsie sa s nim robi). --- len aby bolo jasne, lebo tomas aj ales dolu pisu o json datovom type, ja hovorim o serializovanej podobe entit v binarnej podobe, nie o strukturovanom jsone a podobne. preto pisem o de/serializaci pri cani a zapise. pri spominanom ES sa to bezne pouziva pre uchovavanie snapshotov aktualnych stavov entit aby sa nemuseli neustale hydratovat z event streamu.

odmítavě pro produkci :). Pro prototypování je to je super, ale jakmile začneš řešit WAL, recovery, determistické stavy v databázi, konzistence a integrity datových modelů, těžce s tím narazíš. Nemluvě o tom, že MySQL/Mariadb má dost nešikovně řešeny blob/text datové typy, které ukládá mimo samotný row, generuje to obrovské množství iops a je pak těžké dělat jakékoliv optimalizace, chování je dost nepredikovatelné.V praktickém světě se projekty, takhle vymyšlené dostávají poměrně rychle při dalším rozvoji do kolen. Dělat jakékoliv evoluce datové struktury je skoro nemožné, neskutečně špatně se řeší datový polymorfismus, je to prostě neflexibilní, dneska chceš vypisovat data takhle, zítra jinak, tady pak musíš přeuložit nemalou část dat, to vede pak k těžce kontrolovatelným chybám. Pro objem dat to je fatální, pokud takové hodnoty obsahují čísla, která jsou v binárním hodnotě daleko efektivnější než v ascii. Udělat v tom prototyp, proč ne, ale stavět na tom produkci a další rozvoj rozhodně ne, počáteční výhodnost strašně rychle zmizí. Ono se to týká i všude oblíbeného Monga, ta databáze z hlediska spolehlivosti je jedna z nejhorších co jsem viděl. Přestavoval jsem desítky takových aplikací, původní ušetřené náklady se rychle vytrácí.Postgressql, Oracle, MSSQL mají určitou podporu a rozšíření přímo pro nested row datové typy vč. jsonu nebo xml, tam to za určitých okolností dává smysl, ale opravdu jen za určitých.Kde máme běžně json v blobech, je to rozhodně input stage vrstva, kdy se jedná o data z venku před tím, že jsou naparsovaná a normalizovaná.Dokumentový přístup k relačním datům a potlačení 3. normální formy se někdy využívá jako předpjatá cache. Data máš interně stejně v datovým skladu v relačním modelu, ale mezi aplikací a datovým skladem máš mezivrstvu v podobě dokumentové databáze (klidně postavené na bloby v mysql, postgresu či přímo v elastic, mongu, redisu, dnes třeba docela začínáme používat Apache Kudu), někda je dokonce i obousměrná synchronizace, kdy může aplikace uložit celý nový dokument a backend to pak rozloží do relační databáze. Dají se pak řešit zajímavé věci jako cestování v čase (point in time), kdy mohu si libovolně modifikovat časovou osu a přehrávat si postupně změny, které nastaly a stav, který tam v té době byl. Bankovnictví AirBanky je třeba přesně takhle postavané.

Pouzivam to vyjimecne v PostgreSQL, protoze ma pro to skvelou podporu, daj se nad tim relativne normalne delat dotazy a vsechno to je docela svizne, takze to sem tam ma smysl, ale jinak v relacni databazi urcite spis ty relacni data... Vyslovene si musim rict, ze mit tohle v klasickych relacich nedava smysl nebo je to proste zbytecne slozity...

Trošku s tím koketuju, moc velké zkušenosti nemám.Použil jsem to ve svém sranda projektu, který má maximálně tisíce záznamů. Ale nemyslím si, že objem dat je jediné kritérium pro použití.Podle mě lze typ JSON v db použít, pokud:- tím vyloženě neznásilňuju stávající relační databázovou architekturu (tj. nesnažím se tím nahrazovat to, co relační databáze dělají dobře, jen protože je to možné a frikulín)- daný sloupec není příliš zatěžovaný, například se podle něj často nehledá, neřadí (i když některé funkce extrakci dat podporují, pro databázový engine je velký rozdíl při zpracování velkého počtu záznamů každou hodnotu jen načíst versus načíst ji, dekódovat do datové struktury a z ní extrahovat položku podle nějakého konkrétního zadání)- klasické řešení by bylo výrazně dražší (na čas, úsilí, peníze) - klasické řešení by výrazně zesložiťovalo a znepřehledňovalo celý datový návrh- řešení s JSON oproti klasickému řešení by snižovalo počet dotazů do databáze, složitost a propojenost dotazů, popř. též psaní kódu, který by dodatečná data získával.- ukládáš něco, co může být jeden z více typů. V relační databázi a klasicky bys na to musel založit tabulku s tolika sloupci, kolik těch typů je; při spolupráci s nějakým programem/frameworkem a předávání proměnných do šablon, např., bys všechny hodnoty podle toho, která je vyplněná a která není, nějak vyhodnocovat... v tom je JSON mnohem elegantnější.- předpokládáš, že se bude rozšiřovat (změna přímo v JSONu je rychlejší a řekl bych příjemnější než update databázového návrhu a modlení se, aby se něco nerozbilo)Nevýhody:- je to relativně nové; nepatří mezi klasické SQL standardy- při přechodu na jinou databázi můžeš narazit, že ten typ (nebo přidružené funkce) nebudou podporovány- chyba při kódování/dekódování z/do JSONu (např. při provizorním ručním zadání) může vyústit v null --> ztrátu všech dat ve struktuřePříklady:- Možná sis při zadání klienta vyslechl něco následujícího: "tady se bude ukládat jedna konkrétní hodnota" a později: "no, vlastně... někdy, v ojedinělých případech bychom tam chtěli uložit hodnoty dvě". Pokud to místo, kam se ukládá, není pro databázi stěžejní (viz výše), pak je JSON jednodušší, elegantnější a rychlejší řešení než být orthodoxní.- na různé parametry, proměnné nebo nastavení k záznamu, které do databáze ukládáš (pro článek např. nějaké upozornění, pro produkt nějaký detail, jak ho zobrazit)