Tipy pro plánování schématu MongoDB

Jednou z nejvíce inzerovaných funkcí MongoDB je jeho schopnost být „bez schématu“. To znamená, že MongoDB neukládá žádné schéma na žádné dokumenty uložené v kolekci. MongoDB normálně ukládá dokumenty ve formátu JSON, takže každý dokument může ukládat různé druhy schémat/struktur. To je výhodné pro počáteční fáze vývoje, ale v pozdějších fázích možná budete chtít vynutit určité ověření schématu při vkládání nových dokumentů pro lepší výkon a škálovatelnost. Stručně řečeno, „bez schématu“ neznamená, že nemusíte své schéma navrhovat. V tomto článku proberu několik obecných tipů pro plánování schématu MongoDB.

Vymyslet nejlepší návrh schématu, který vyhovuje vaší aplikaci, může být někdy únavné. Zde je několik bodů, které můžete vzít v úvahu při navrhování schématu.

Vyhněte se rostoucím dokumentům

Pokud vaše schéma umožňuje vytvářet dokumenty, jejichž velikost neustále narůstá, měli byste podniknout kroky, abyste se tomu vyhnuli, protože to může vést ke snížení výkonu DB a IO disku. Ve výchozím nastavení umožňuje MongoDB velikost 16 MB na dokument. Pokud se velikost vašeho dokumentu za určitou dobu zvětší o více než 16 MB, je to známka špatného návrhu schématu. Někdy to může vést k selhání dotazů. Chcete-li se této situaci vyhnout, můžete použít skupiny dokumentů nebo techniky předběžného přidělování dokumentů. V případě, že vaše aplikace potřebuje ukládat dokumenty o velikosti větší než 16 MB, můžete zvážit použití MongoDB GridFS API.

Vyhněte se aktualizaci celých dokumentů

Pokud se pokusíte aktualizovat celý dokument, MongoDB přepíše celý dokument jinam v paměti. To může drasticky snížit výkon zápisu vaší databáze. Namísto aktualizace celého dokumentu můžete použít modifikátory polí k aktualizaci pouze určitých polí v dokumentech. To spustí aktualizaci na místě v paměti, čímž se zlepší výkon.

Snažte se vyhnout spojením na úrovni aplikace

Jak všichni víme, MongoDB nepodporuje připojení na úrovni serveru. Musíme tedy získat všechna data z DB a následně provést spojení na aplikační úrovni. Pokud získáváte data z více kolekcí a spojujete velké množství dat, musíte DB několikrát volat, abyste získali všechna potřebná data. To bude samozřejmě vyžadovat více času, protože to zahrnuje síť. Jako řešení pro tento scénář, pokud vaše aplikace silně spoléhá na spojení, pak má denormalizace schématu větší smysl. Můžete použít vložené dokumenty k získání všech požadovaných dat v jediném dotazu.

Používejte správné indexování

Při vyhledávání nebo agregaci se často data třídí. I když žádáte o řazení v poslední fázi kanálu, stále potřebujete rejstřík k pokrytí řazení. Pokud index na třídicím poli není k dispozici, MongoDB je nucen třídit bez indexu. Existuje limit paměti 32 MB celkové velikosti všech dokumentů, které se účastní operace řazení. Pokud MongoDB dosáhne tohoto limitu, může způsobit chybu nebo vrátit prázdnou sadu.

Po probrání přidávání indexů je také důležité nepřidávat zbytečné indexy. Každý index, který přidáte do databáze, musíte aktualizovat všechny tyto indexy při aktualizaci dokumentů v kolekci. To může snížit výkon databáze. Každý index také zabere určitý prostor a paměť, takže počet indexů může vést k problémům souvisejícím s úložištěm.

Dalším způsobem, jak optimalizovat použití indexu, je přepsání výchozího pole _id. Jediným účelem tohoto pole je zachovat jedno jedinečné pole na dokument. Pokud vaše data obsahují časové razítko nebo jakékoli pole id, můžete pole _id přepsat a uložit jeden index navíc.

Poměr čtení v/s zápisu

Návrh schématu pro jakoukoli aplikaci velmi závisí na tom, zda je aplikace náročná na čtení nebo zápis. Pokud například vytváříte řídicí panel pro zobrazení dat časových řad, měli byste schéma navrhnout tak, abyste maximalizovali propustnost zápisu. Pokud je vaše aplikace založena na elektronickém obchodování, pak většina operací bude operace čtení, protože většina uživatelů bude procházet všechny produkty a procházet různé katalogy. V takových případech byste měli použít denormalizované schéma, abyste snížili počet volání do DB pro získání relevantních dat.

Datové typy BSON

Při navrhování schématu se ujistěte, že jste správně definovali datové typy BSON pro všechna pole. Protože když změníte datový typ libovolného pole, MongoDB přepíše celý dokument do nového paměťového prostoru. Pokud se například pokusíte uložit (int)0 místo pole (float)0.0, MongoDB přepíše celý dokument na novou adresu kvůli změně typu dat BSON.

Závěr

Stručně řečeno, je moudré navrhnout schéma pro vaši databázi Mongo, protože to pouze zlepší výkon vaší aplikace. Od verze 3.2 začala MongoDB podporovat ověřování dokumentů, kde můžete definovat, která pole jsou vyžadována pro vložení nového dokumentu. Od verze 3.6 MongoDB zavedl elegantnější způsob vynucení ověření schématu pomocí JSON Schema Validation. Pomocí této metody ověření můžete vynutit kontrolu typu dat spolu s kontrolou požadovaných polí. Výše uvedené postupy můžete použít ke kontrole, zda všechny dokumenty používají stejný typ schématu nebo ne.