Překlad článku byl vyhotoven před začátkem kurzu .
Hlavní body:
- Je velmi důležité navrhnout schéma, i když je v MongoDB nepovinné.
- Podobně by indexy měly odpovídat vašemu schématu a vzorům přístupu.
- Vyhněte se používání velkých objektů a velkých polí.
- Buďte opatrní s nastavením MongoDB, zejména pokud jde o bezpečnost a spolehlivost.
- V MongoDB neexistuje optimalizátor dotazů, takže byste měli být opatrní při provádění dotazovacích operací.
Dlouho pracuji s databázemi, ale teprve nedávno jsem objevil MongoDB. Je několik věcí, které bych chtěl vědět, než s ní začnu pracovat. Jakmile má člověk zkušenosti v určité oblasti, má předpojaté představy o tom, co databáze jsou a co dělají. S cílem usnadnit porozumění ostatním lidem představím seznam běžných chyb.
Vytvoření serveru MongoDB bez autentizace
Bohužel, MongoDB se ve výchozím nastavení instaluje bez autentizace. Pro pracovní stanici, ke které je přístup lokální, je taková praxe normální. Ale protože MongoDB je vícerozměrný systém, který rád používá velké množství paměti, bylo by lepší, kdybyste ji nainstalovali na server s co největším možným množstvím RAM, i když ji plánujete používat jen pro vývoj. Instalace na server přes výchozí port může být problematická, zejména pokud v dotazu může být vykonán libovolný kód v JavaScriptu (například, $where jako nápad pro ).
Existuje několik metod autentizace, ale nejjednodušší je nastavit uživatelské ID/heslo. Využijte tuto myšlenku, dokud budete přemýšlet o komplikovanější autentizaci založené na . Co se týče bezpečnosti, MongoDB by měla být pravidelně aktualizována a logy by měly být vždy kontrolovány na neautorizovaný přístup. Například rád vybírám jiný port jako výchozí port.
Nezapomeňte svázat útočnou plochu s MongoDB
obsahuje dobré rady pro snížení rizika narušení sítě a úniku dat. Je snadné si myslet, že server pro vývoj nepotřebuje vysokou úroveň zabezpečení. Ale vše není tak jednoduché a to platí pro všechny servery MongoDB. Zejména pokud neexistuje vážný důvod pro použití , nebo , je třeba zakázat používání libovolného kódu v JavaScriptu tím, že do konfiguračního souboru napíšete . Vzhledem k tomu, že v běžné MongoDB nejsou datové soubory šifrovány, je rozumné spouštět MongoDB s , který má plný přístup k souborům, s omezeným přístupem pouze pro něj a možností používat vlastní prostředky řízení přístupu k souborům operačního systému.
Chyba při navrhování schématu
MongoDB nepoužívá schéma. Ale to neznamená, že schéma není potřeba. Pokud chcete jen ukládat dokumenty bez jakéhokoli konzistentního schématu, jejich ukládání může být rychlé a jednoduché, ale jejich pozdější vyhledávání může být .
Klasický článek " stojí za to přečíst, a takové funkce jako v externím nástroji Studio 3T by se měly používat pro pravidelné kontroly schématu.
Nezapomeňte na pořadí třídění
Zapomenutí na pořadí třídění vás může nejvíce zklamat a ztratit více času než při použití jakékoli jiné nesprávné konfigurace. Ve výchozím nastavení MongoBD používá . Ale málokdo z toho bude mít prospěch. Citlivá na velikost písmen, diakritiku, binární třídění byla považována za podivné anachronismy vedle korálků, kaftanů a kroucených knírů ještě v osmdesátých letech. Nyní je jejich používání nepřípustné. Ve skutečnosti "motocykl" je to samé jako "Motocykl". A "Británie" a "británie" jsou stejná místa. Malé písmeno je prostě velkým písmenem ve formátu malého písmena. A nedonucujte mě mluvit o třídění diakritických znaků. Při vytváření databáze v MongoDB používejte třídicí parametry bez ohledu na diakritiku a , které odpovídají jazyku a . Tím výrazně usnadníte vyhledávání v textových datech.
Vytváření kolekcí s velkými dokumenty
MongoDB umožňuje ukládat velké dokumenty o velikosti až 16 MB v kolekcích, a je určena pro velké dokumenty přesahující 16 MB. Ale jen proto, že je možné je tam uložit, není to nejlepší nápad. MongoDB bude fungovat nejlépe, pokud budete ukládat jednotlivé dokumenty o velikosti několika kilobajtů a považovat je spíše za řádky v široké SQL tabulce. Velké dokumenty budou zdrojem problémů s .
Vytváření dokumentů s velkými poli
Dokumenty mohou obsahovat pole. Nejlepší je, když počet prvků v poli je daleko od čtyřmístného čísla. Pokud se prvky do pole často přidávají, překročí obsahující dokument a bude nutné jej , což znamená, že bude nutné . Při opětovném indexování dokumentu s velkým polem budou indexy často přepisovány, protože pro každý prvek existuje , který uchovává jeho index. Takové přeindexování také nastává, když je dokument vložen nebo odstraněn.
V MongoDB existuje takzvaný , který poskytuje prostor pro růst dokumentů, aby se tato problematika minimalizovala.
Můžete si myslet, že se můžete obejít bez indexace polí. Bohužel, absence indexů může přinést jiné problémy. Protože dokumenty jsou prohlíženy od začátku do konce, hledání prvků na konci pole bude trvat více času, a většina operací souvisejících s takovým dokumentem bude .
Nezapomeňte, že pořadí fází v agregaci má své místo
V databázovém systému s optimalizátorem dotazů to, co píšete, je vysvětlením toho, co chcete získat, ne jak to získat. Takový mechanismus funguje analogicky k objednávce v restauraci: obvykle si jednoduše objednáte jídlo, místo abyste dávali podrobné pokyny kuchaři.
V MongoDB instruujete kuchaře. Například je nutné zajistit, aby data prošla reduce co nejdříve v pipeline pomocí $match a $project, a třídění probíhá až po reduce, a co se hledání děje přesně v pořadí, které potřebujete. Přítomnost optimalizátoru dotazů, který odstraňuje zbytečnou práci, optimálně uspořádává fáze a vybírá typ připojení, vás může rozmazlovat. V MongoDB máte více kontroly na úkor pohodlí.
Takové nástroje jako usnadní tvoření agregačních dotazů v . Funkce Aggregation Editor vám umožní aplikovat operátory potrubí po jednom kroku, a také ověřovat vstupy a výstupy v každé fázi pro zjednodušení debugování.
Použití rychlého záznamu
Nikdy nenastavujte v MongoDB parametry záznamu s vysokou rychlostí, ale nízkou spolehlivostí. Tento režim „file-and-forget“ se zdá rychlý, protože příkaz se vrátí ještě před tím, než se provede záznam. Pokud systém selže předtím, než jsou data zapsána na disk, ztratí se a dostanou se do nekonzistentního stavu. Naštěstí v 64bitové verzi MongoDB bylo zavedeno protokolování.
Úložné motory MMAPv1 a WiredTiger používají protokolování k prevenci tohoto, i když WiredTiger se může obnovit na poslední konzistentní , pokud je protokolování vypnuté.
Protokolování zajišťuje, že databáze je v konzistentním stavu po obnově a uchovává všechna data do okamžiku záznamu v protokolu. Periodicita záznamů se nastavuje pomocí parametru .
Aby bylo zajištěno, že záznamy jsou spolehlivé, ujistěte se, že v konfiguračním souboru je protokolování povoleno ), a že periodicita záznamů odpovídá množství informací, které si můžete dovolit ztratit.
Třídění bez indexu
Při hledání a agregaci často vyvstává potřeba třídit data. Doufejme, že se to děje na jednom z závěrečných stádií, po filtrování výsledku za účelem snížení objemu tříděných dat. A i v takovém případě budete potřebovat pro třídění . Můžete použít jednoduchý nebo složený index.
Pokud neexistuje vhodný index, MongoDB si poradí bez něj. Existuje paměťové omezení 32 MB na celkovou velikost všech dokumentů v , a pokud MongoDB dosáhne této hranice, buď vyhodí chybu, nebo vrátí .
Hledání bez podpory indexů
Vyhledávací dotazy plní funkci obdobnou operaci JOIN v SQL. Pro lepší fungování potřebují index hodnoty klíče, který je použit jako cizí klíč. To není zřejmé, protože použití není odráženo v explain(). Tyto indexy jsou doplňkem k indexu zapsanému v explain(), který je zase používán operátory pipeline $match a $sort, když se setkávají na začátku pipeline. Indexy nyní mohou pokrývat jakoukoliv fázi .
Vzdání se používání multiaktualizací
Metoda se využívá k úpravě části existujícího dokumentu nebo celého dokumentu, až po úplnou náhradu v závislosti na parametru, který jste nastavili . Není tak zřejmé, že nezpracovává všechny dokumenty ve sbírce, dokud nenastavíte parametr pro aktualizaci všech dokumentů splňujících kritéria dotazu.
Nezapomínejte na důležitost pořadí klíčů v hash tabulce
V JSONu je objekt složen z neuspořádané kolekce o velikosti nula nebo více párů jméno/hodnota, kde jméno je řetězec a hodnota je řetězec, číslo, logická hodnota, nula, objekt nebo pole.
Bohužel, BSON klade velký důraz na pořadí při hledání. V MongoDB má pořadí klíčů uvnitř vložených objektů , tj. { firstname: "Phil", surname: "factor" } – to není totéž, co { { surname: "factor", firstname: "Phil" }. To znamená, že musíte v dokumentech uchovávat pořadí párů jméno/hodnota, pokud chcete mít jistotu, že je najdete.
Nepleťte si "null" a "undefined"
Hodnota "undefined" nikdy nebyly platné v JSON, podle JSON (ECMA-404, Část 5), i když je používán v JavaScriptu. Navíc, pro BSON je to zastaralé a převádí se na $null, což není vždy dobré řešení. .
Použití $limit() bez $sort()
Velmi často, když vyvíjíte v MongoDB, je užitečné prostě vidět ukázku výsledku, který se vrátí z dotazu nebo agregace. Pro tento úkol se vám hodí $limit(), ale nikdy by to nemělo být ve finální verzi kódu, pokud před ním nepoužíváte $sort. Tato mechanika je potřebná, protože jinak nemůžete zaručit pořadí výsledků a nebudete moci spolehlivě prohlížet data. V horní části výsledku budete dostávat různé záznamy v závislosti na třídění. Aby bylo zajištěno spolehlivé fungování, musí být dotazy a agregace deterministické, tedy musí přinášet stejné výsledky při každém provedení. Kód, ve kterém je $limit(), ale není $sort, nebude deterministický a může později vyvolat chyby, které budou obtížné sledovat.
Závěr
Jedním z mála způsobů, jak se zklamat v MongoDB, je porovnávat ji přímo s jiným typem databází, jako je RDBMS, nebo se k jejímu použití dostat s nějakými předem stanovenými očekáváními. Je to jako porovnávat pomeranč s vidlicí. Databázové systémy sledují určité cíle. Nejlepší je jednoduše pochopit a ocenit tyto rozdíly. Bylo by škoda tlačit na vývojáře MongoDB kvůli cestě, kterou byli nuceni jít směrem k RDBMS. Rád bych viděl nové a zajímavé způsoby řešení starých problémů, jako je zajištění integrity dat a vytváření systémů dat odolných vůči poruchám a útokům hackerů.
Implementace ACID transakčnosti v MongoDB verze 4.0 je dobrým příkladem zavedení důležitých vylepšení inovativním způsobem. Multidokumentové a multioperátorové transakce jsou nyní atomární. Také se objevila možnost regulovat čas potřebný k získání zámků a ukončovat visící transakce, stejně jako měnit úroveň izolace.
Číst víc:
Zdroj: habr.com
