Jan Mikoláš
Slovník pojmů
MongoDB
Dokumentová databáze pro data, která dávají smysl jako ucelené dokumenty. Flexibilita pomáhá jen tehdy, když ji doprovází promyšlené schéma a indexy.
Stručná definice
Dokument je jednotka dat i důležitá hranice návrhu.
MongoDB patří mezi databáze orientované na dokumenty. Základní záznam není řádek rozdělený do pevně daných sloupců, ale BSON dokument složený z polí a hodnot. BSON je binární reprezentace podobná JSON, ale podporuje i další typy, například datum, binární data, ObjectId nebo Decimal128. Dokument proto není pouhý JSON soubor uložený na disku.
Dokumenty podobného účelu se ukládají do kolekcí. Kolekce se částečně podobá SQL tabulce, ale její dokumenty mohou mít odlišná pole a vnořené struktury. Každý dokument ve standardní kolekci má unikátní pole `_id`; pokud ho aplikace nedodá, ovladač nebo server obvykle vytvoří ObjectId. Flexibilita struktury je vlastnost, nikoli omluva pro chybějící pravidla.
Jaký problém řeší
Související data lze číst a měnit jako jeden celek.
MongoDB je užitečná tam, kde se hranice businessového objektu přirozeně shoduje s dokumentem a aplikace zná své hlavní přístupové vzory.
- produktový katalog s proměnlivými atributy pro různé kategorie
- profil nebo nastavení uživatele čtené většinou jako jeden celek
- obsahové dokumenty s vnořenými bloky a verzovanou strukturou
- telemetrie nebo události, pokud tomu odpovídá objem, retence a dotazy
- API aplikace, jejichž datový model je opravdu dokumentový, ne pouze proto, že odpověď používá JSON
Praktický příklad
Produkt s atributy a omezeným seznamem variant
E-shop prodává produkty, jejichž atributy se liší podle kategorie. Název, kategorie, atributy a menší počet variant se na detailu produktu načítají společně, proto mohou tvořit jeden dokument. Kategorie je reference, protože existuje samostatně a může ji sdílet mnoho produktů. Index podporuje konkrétní filtr podle kategorie a barvy.
Pole `variants` nesmí růst bez omezení. Pokud by produkt měl statisíce samostatně měněných nabídek, přirozenější by byla vlastní kolekce s referencí. Stejně jako u databázového indexu se přínos složeného indexu ověřuje na reálných dotazech; každý další index zabírá prostor a zdražuje zápis.
MongoDB Shell (mongosh)
db.products.insertOne({
_id: ObjectId("66b100000000000000000001"),
sku: "SHOE-42",
name: "Trail Runner",
categoryId: ObjectId("66b200000000000000000001"),
attributes: { color: "blue", material: "mesh" },
variants: [
{ sku: "SHOE-42-43", size: 43, price: Decimal128("2490.00"), stock: 7 },
{ sku: "SHOE-42-44", size: 44, price: Decimal128("2490.00"), stock: 3 }
]
});
db.products.createIndex({ categoryId: 1, "attributes.color": 1 });
db.products.find(
{ categoryId: ObjectId("66b200000000000000000001"), "attributes.color": "blue" },
{ name: 1, variants: 1 }
);Jak funguje
Od přístupového vzoru k výslednému dokumentu
Textová alternativa diagramu: požadavky aplikace určí hranici dokumentu, dokument se uloží do kolekce, dotaz použije vhodný index a agregační pipeline případně odvodí souhrn.
- Přístupové vzory Nejprve se popíše, co aplikace čte společně, co mění atomicky a jak mohou data růst.
- Dokument Související hodnoty se vloží do BSON dokumentu nebo se propojí referencí na jiný dokument.
- Kolekce Dokument se uloží do kolekce, kde `_id` zajišťuje jeho jedinečnou identitu.
- Dotaz a index Filtr, projekce a řazení vyberou data; odpovídající index může omezit drahé procházení kolekce.
- Agregace Pipeline skládá kroky jako filtrování, rozbalení pole, seskupení a výpočet výsledku.
Hlavní principy
Model se navrhuje podle operací, ne podle podobnosti s JSON odpovědí.
Dokumentový model má vlastní pravidla integrity, vztahů a provozu.
Embedding a reference
Embedding drží související data uvnitř jednoho dokumentu, takže je lze číst a měnit společně. Reference ukládá identifikátor jiného dokumentu a hodí se pro nezávisle existující entity, složité vztahy nebo neomezeně rostoucí kolekce hodnot. MongoDB umí spojování v agregaci přes `$lookup`, ale není to důvod bezmyšlenkovitě kopírovat relační model.
Flexibilní schéma a validace
Dokumenty v kolekci nemusí mít ve výchozím stavu stejná pole ani typy. Aplikace přesto má schéma a musí řešit jeho evoluci. Schema validation umí přes pravidla včetně `$jsonSchema` kontrolovat povinná pole, BSON typy nebo rozsahy a standardně odmítnout neplatný zápis.
Atomické operace a transakce
Zápis do jednoho dokumentu je atomický, což podporuje dobře zvolené embedding hranice. Pokud jedna businessová změna zasahuje více dokumentů, kolekcí nebo shardů, MongoDB podporuje vícedokumentové transakce. Ty mají vyšší cenu a nenahrazují dobrý model ani promyšlenou hranici transakce.
Replikace a sharding
Replica set udržuje kopie dat na více uzlech a umožňuje volbu nového primary při výpadku. Sharding rozděluje dokumenty kolekce mezi shardy podle shard key, když data nebo zátěž přesahují jeden uzel. Obě schopnosti přidávají provozní rozhodnutí; sharding není výchozí optimalizace pro malou aplikaci.
Výhody a omezení
Přínos závisí na tom, zda dokument odpovídá businessové hranici.
Možné přínosy
- načtení souvisejících dat jednou operací při vhodném embeddingu
- atomická změna celého jednoho dokumentu
- flexibilní evoluce dokumentů doplněná cílenou validací
- dotazy a agregace nad vnořenými poli a poli hodnot
Omezení a časté chyby
- neomezeně rostoucí embedded pole a opakované přepisování velkých dokumentů
- ignorování indexů, selektivity dotazů a ceny zápisu
- nekontrolovaná duplicita dat vedoucí k rozdílným kopiím
- volba MongoDB jen proto, že REST API přenáší JSON
Porovnání a hranice použití
MongoDB není automaticky rychlejší ani jednodušší než relační databáze.
U katalogu s rozdílnými atributy a předvídatelným čtením po celých produktech může dokumentový model zjednodušit práci. Duplicita, například kopie zobrazovaného názvu kategorie, může být vědomou optimalizací čtení. Musí ale existovat proces, který po změně zdroje aktualizuje kopie a umí odhalit jejich rozpor. Výkon se hodnotí pro konkrétní model, indexy, objem a workload.
Pokud doména stojí na mnoha vztazích, cizích klíčích, unikátních pravidlech napříč entitami, složitých ad hoc dotazech a častých transakcích přes více záznamů, může být přirozenější relační model v PostgreSQL nebo MySQL. Nejde o žebříček databází: správná volba vychází z invariants, přístupových vzorů, provozních znalostí a rizik migrace.
Na co myslet
Dokumentový model je konkrétní architektonické rozhodnutí.
Před nasazením je potřeba ověřit nejen ukázkový insert, ale i růst, souběh a obnovu.
- sepsat hlavní dotazy, zápisy a businessové hranice před volbou embeddingu
- zavést schema validation pro kritická pole a bezpečně verzovat změny struktury
- měřit plány dotazů a navrhovat složené indexy podle skutečných filtrů a řazení
- omezit velikost a kardinalitu polí uvnitř dokumentu; BSON dokument má maximální velikost 16 MiB
- testovat souběžné změny, zálohy, obnovu a chování ovladače při přechodné chybě
Časté otázky
Co flexibilní dokumentový model znamená v praxi
Je MongoDB databáze bez schématu?
Ne. Ve výchozím stavu dovoluje flexibilní strukturu dokumentů, ale aplikace má datový model a MongoDB podporuje schema validation pro typy, povinná pole i další pravidla.
Podporuje MongoDB transakce?
Ano. Operace nad jedním dokumentem jsou atomické a pro změny více dokumentů, kolekcí, databází nebo shardů jsou dostupné transakce. Jejich provozní cena nenahrazuje vhodný model.
Kdy data vložit do dokumentu a kdy použít referenci?
Embedding se hodí pro data čtená a měněná společně s omezeným růstem. Reference je vhodnější pro samostatné entity, složité vztahy, časté nezávislé změny nebo neomezenou kardinalitu.
Je MongoDB automaticky lepší pro JSON API?
Ne. Přenosový formát API neurčuje vhodný perzistentní model. Rozhodují vztahy, pravidla integrity, dotazy, způsob aktualizace a provozní zkušenosti.
Nahrazují agregace relační SQL dotazy?
Agregační pipeline umí filtrovat, transformovat, seskupovat a spojovat dokumenty, ale má jiný model a kompromisy. Návrh databáze se nemá zakládat na mechanickém přepisu SQL.
Osobní zkušenost
Databázi volím podle dat, operací a provozních hranic.
V e-commerce projektech propojuji datové modelování s integritou, indexy, migracemi a měřením skutečných dotazů.