Učení MongoDB vyžaduje hodně přesného myšlení. Často se málo zohledňuje zásadní podniky, které by jinak mohly ohrozit výkon databáze v produkčním režimu.
MongoDB je NoSQL DBMS, který se doslova řídí jiným vzorem než databáze SQL, zejména pokud jde o zabezpečení a strukturu. Ačkoli některé integrované funkce podporují jeho výkon a činí jej jedním z nejlepších v poslední době, některé z funkcí následně představují potenciální hrozby, které mohou zničit jeho výkon, pokud nebudou brány v úvahu.
V nedávné zkušenosti s „nejhorším případem“ jsem se pokoušel dotazovat kolekci s dokumenty, které měly velká pole, a trvalo mi věky, než jsem výsledky získal zpět. Rozhodl jsem se napsat tento blog, protože jsem věděl, že pokud někdo zažije stejné problémy, tento blog bude velkou pomocí.
Klíčové úvahy pro MongoDB v produkci
- Zabezpečení a ověřování.
- Indexování dokumentů
- Použití schématu ve sbírkách
- Omezená sbírka
- Velikost dokumentu
- Velikost pole pro vložené dokumenty
- Fáze procesu agregace
- Pořadí klíčů v objektu hash
- „undefined“ a „null“ v MongoDB
- Operace zápisu
Zabezpečení a ověřování MongoDB
Data se v mnoha ohledech liší a je zřejmé, že některé informace budete muset uchovat v tajnosti. Ve výchozím nastavení instalace MongoDB nenastavují požadavek na autentizaci jako nutnost, ale to vám neumožňuje jej používat, zejména pokud se jedná o důvěrná data, jako jsou finanční a lékařské záznamy. Na vývojové pracovní stanici to není velký problém, ale kvůli zapojení více uživatelů do produkčního režimu je dobrou praxí nastavit ověřovací certifikáty. Nejběžnější a snadno použitelnou metodou je výchozí přihlašovací jméno a heslo MongoDB.
Data se zapisují do souborů, ke kterým lze přistupovat pomocí nástroje třetí strany, spíše pokud nejsou šifrována. Data mohou být bez vašeho vědomí změněna, pokud k systémovým souborům získá přístup nějaká anonymní osoba. Hostování databáze na vyhrazeném serveru a přiřazení jednoho uživatele, který bude mít plný přístup k datovým souborům, vám ušetří trik.
Ochrana dat před útoky externího injekce je rovněž zásadním úkolem. Některé operátory jako $group, $whereby a operace mapReduce jsou vyvinuty pomocí javascriptu (js), a proto jsou náchylné k manipulaci s js. Chcete-li se v důsledku toho vyhnout jakékoli instanci integrity dat, můžete zakázat libovolné nastavení JS konfigurací parametru javascriptEnabled:false v konfiguračním souboru, pokud jste nepoužili žádný z uvedených operátorů. Dále můžete snížit riziko přístupu k datům prostřednictvím narušení sítě použitím některých postupů zvýrazněných v Kontrolním seznamu zabezpečení MongoDB.
Indexování vašich dokumentů
Indexování je obecně přiřazení jedinečné identifikační hodnoty každému dokumentu v kolekci MongoDB. Indexování přináší zvýšení výkonu v operacích čtení i zápisu. Ve výchozím nastavení je povoleno a toto nastavení byste měli vždy zachovat. Bez indexování musí databáze kontrolovat více dokumentů od začátku do konce a operace bude bohužel časově nákladná pro dokumenty, které jsou ke konci, což způsobí nízkou latenci dotazu. V určitém okamžiku na konci aplikace mohou uživatelé zaznamenat zpoždění a mohou si myslet, že aplikace ve skutečnosti nefunguje. Indexování je užitečné při operacích řazení a vyhledávacích dotazů a nevynechává samotnou operaci hledání. Třídění je běžnou operací pro mnoho vrácených dokumentů. Často se provádí jako poslední fáze poté, co byly dokumenty vyfiltrovány, takže je potřeba třídit malé množství dat. Index v tomto případě pomůže seřadit data podle povahy položky a omezí vracená data na limit 32 MB. Pokud nedojde k indexování, bude překročena pravděpodobnost limitu 32 paměti pro kombinovanou velikost vrácených dokumentů a kdykoli databáze dosáhne tohoto limitu, kromě vrácení prázdné sady záznamů vyvolá chybu.
Operace $lookup je také podporována se zavedenou indexací. Index hodnoty klíče použité jako cizí klíč je nezbytný pro předchozí fáze zpracování.
Použití schématu ve vašich sbírkách
MongoDB nepotřebuje jeden k definování polí (sloupců), stejně jako to může vyžadovat, abyste to udělali pro SQL dbms. Jakkoli nebudete muset definovat pole, abyste se vyhnuli nekonzistenci dat a některým překážkám, které mohou nastat, je definování schématu vždy dobrou praxí. Návrh schématu vám umožňuje určit, který typ dat jde do určitého pole, které pole musí být opatřeno hodnotou a obecně zlepšuje ověřování dat před zadáním nebo aktualizací, čímž podporuje integritu a konzistenci dat. Návrh schématu vás také nasměruje, zda chcete data odkazovat nebo vkládat. Jako začátečník si můžete myslet, že jediným modelem bude „One-to-N“, který vám usnadní mít položky pole vnořených dokumentů, ale není tomu tak.
Před vytvořením modelu musíte porozumět vztahu mohutnosti mezi dokumenty. Některá z pravidel, která vám pomohou vytvořit optimální schéma, jsou:
- Chcete-li snížit počet dotazů, které budete muset provést před přístupem k některým datům, a pokud se jedná o málo polí nebo prvků pole, můžete vložit vnořené dokumenty. Vezměte si příklad níže uvedeného modelu:
-
{ Name: ‘John Doh’, Age:20 Addresses:[ {street: ‘Moi Avenue’, city:’Nairobi’, countryCode: ‘KE’}, {street: ‘Kenyatta Avenue’, city:’Nairobi’, countryCode: ‘KE’}, ] }
-
- Pro často aktualizované dokumenty použijte denormalizace . Pokud bude nějaké pole často aktualizováno, pak bude úkolem najít všechny instance, které je třeba aktualizovat. To bude mít za následek pomalé zpracování dotazů, a tím pádem i přesilování výhod spojených s denormalizací.
- Provedení složitých dotazů, jako je agregované zřetězení, trvá déle, když se jedná o mnoho dílčích dokumentů a je potřeba načíst dokument samostatně.
- Prvky pole s velkou sadou objektových dat by neměly být vkládány zjevně kvůli skutečnosti, že se mohou zvětšit a následně přesáhnout velikost dokumentu.
Modelování schématu je často určeno vzorem přístupu aplikace. Další postupy, které mohou pomoci při návrhu vašeho modelu, najdete v blogu 6 Rules of Thumb for MongoDB Schema Design
Použít limitovanou sbírku pro prioritu posledních dokumentů
MongoDB poskytuje mnoho zdrojů, jako je omezená kolekce. Některé se bohužel nakonec nevyužijí. Omezená kolekce má pevnou velikost a je známo, že podporuje vysoce výkonné operace, které vkládají a načítají dokumenty na základě objednávky vložení. Po zaplnění jeho místa se staré dokumenty smažou, aby bylo místo pro nové.
Příklad použití omezené kolekce:
- Ukládání často používaných dat do mezipaměti, protože samotná kolekce je náročná spíše na čtení než na zápis. Musíte zajistit, aby kolekce vždy fungovala.
- Protokolovat informace pro velkoobjemové systémy. Limitovaná kolekce často nepoužívá index a to je výhodné v tom, že rychlost záznamu je poměrně vysoká, stejně jako zápis do souboru.
Věnujte pozornost velikosti dokumentu MongoDB
Každý dokument MongoDB je omezen na velikost 16 megabajtů. Pro dokument je však optimální dosáhnout tohoto limitu nebo se mu přiblížit, protože to bude představovat strašlivé problémy s výkonem. Samotný MongoDB funguje nejlépe, když je velikost dokumentů několik kilobajtů. Pokud je dokument dostatečně velký, komplexní požadavek na promítání bude trvat dlouho a dotazu může vypršet časový limit.
Věnujte pozornost velikosti pole vložených dokumentů
Je možné vložit vnořené dokumenty do pole v dokumentu a tím vytvořit hodnotu pole v tomto poli. Jak již bylo zmíněno, je třeba udržovat nízkou velikost vnořených dokumentů. Stejně důležité je zajistit, aby počet prvků pole byl nižší než čtyři číslice. V opačném případě dokument přesáhne svou velikost a bude nutné jej přemístit na disk. Dalším problémem spojeným s takovou operací je to, že každý dokument bude muset být znovu indexován. Každý vnořený dokument bude navíc stejně nutné znovu indexovat. To znamená, že dojde k velkému množství zápisů do indexu, což bude mít za následek pomalé operace. Pro velkou velikost vnořeného dokumentu je spíše důležité uchovávat záznamy v nové kolekci než vkládat.
Fáze agregačního kanálu
Kromě běžných operací dotazů MongoDB se používá agregační rámec pro manipulaci a vracení dat v souladu s některými specifikacemi, jako je řazení a seskupování. MongoDB nemá optimalizátor dotazů, a proto jej potřebujeme, aby bylo možné dotazy správně seřadit. Pomocí agregačního rámce zajistěte správné uspořádání fází kanálu. Začněte tím, že snížíte množství dat, se kterými se zabýváte, pomocí operátoru $match a případně $sort na konci, pokud je potřeba třídit. K optimalizaci agregačního dotazu před integrací do kódu můžete použít nástroje třetích stran, jako je Studio 3T. Tento nástroj vám umožňuje vidět vstup a výstup dat v kterékoli fázi, a tak vědět, s čím máte co do činění.
Použití $limit a $sort by mělo vždy dávat stejné výsledky při každém provedení dotazu. V případě, že použijete $limit, vrácená data nebudou deterministická a mohou způsobit některé problémy, které je obtížné sledovat.
Zkontrolujte pořadí klíčů v objektech hash
Zvažte možnost mít dva velké dokumenty se vzorovými daty
{
FirstName: ‘John’,
LastName: ‘Doh’
}Pokud provedete operaci hledání s dotazem {FirstName:'John', LastName:'Doh'}, operace se neshoduje s dotazem {LastName:'Doh' FirstName:'John' }. Proto musíte ve svých dokumentech udržovat pořadí párů jmen a hodnot.
V MongoDB se vyhněte „undefined“ a „null“
MongoDB používá pro své dokumenty formát BSON. S ověřením JSON není „undefined“ podporováno a měli byste se jej vyhnout. $null přichází jako řešení, ale měli byste se mu také vyhnout.
Zvažte operace zápisu
Můžete nastavit MongoDB pro vysokorychlostní zápisy, ale to představuje překážku v tom, že odpověď je vrácena ještě před zápisem dat. Abyste tomuto scénáři zabránili, mělo by být povoleno ukládání do deníku. Navíc v případě havárie databáze budou data stále dostupná a vytvoří kontrolní bod, který lze použít v procesu obnovy. Konfiguraci doby trvání zápisů do žurnálu lze nastavit pomocí parametru commitIntervalMs.
Závěr
Databázový systém by měl kromě odolnosti vůči selhání a zlomyslnosti zajistit integritu a konzistenci dat. Abychom však k těmto faktorům dospěli, musíme porozumět samotné databázi a datům, které obsahuje. MongoDB bude fungovat dobře, když se vezmou v úvahu výše uvedené faktory. Nejdůležitější z nich je použití schématu. Schéma vám umožňuje ověřit vaše data před zadáním nebo aktualizací a jak budete tato data modelovat. Datové modelování je často řízeno vzorem přístupnosti aplikace. To vše sečteno nabídne lepší výkon databáze.