14 věcí, které bych si přál vědět, než jsem začal s MongoDB

Překlad článku byl připraven v předvečer zahájení kurzu "Nerelační databáze".

14 věcí, které bych si přál vědět, než jsem začal s MongoDB

Highlights:

  • Je nesmírně důležité vyvinout schéma, i když je v MongoDB volitelné.
  • Stejně tak indexy musí 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.
  • MongoDB nemá optimalizátor dotazů, takže při provádění operací dotazů musíte být opatrní.

S databázemi pracuji velmi dlouho, ale teprve nedávno jsem objevil MongoDB. Je pár věcí, které bych si přál vědět, než jsem s tím začal pracovat. Když už má člověk zkušenosti v určité oblasti, má předem vytvořené představy o tom, co databáze jsou a co dělají. V naději, že to ostatním usnadním pochopit, uvádím seznam běžných chyb.

Vytvoření serveru MongoDB bez ověřování

MongoDB je bohužel standardně nainstalován bez ověřování. U pracovní stanice, ke které se přistupuje místně, je tento postup normální. Ale protože MongoDB je víceuživatelský systém, který rád využívá velké množství paměti, bude lepší, když jej dáte na server s co největším množstvím RAM, i když jej budete používat pouze pro vývoj. Instalace na server přes výchozí port může být problematická, zejména pokud lze v požadavku spustit jakýkoli kód javascriptu (např. $where jako nápad pro injekcí).

Existuje několik metod ověřování, ale nejjednodušší je nastavit uživatelské ID/heslo. Použijte tento nápad, když budete přemýšlet o luxusní autentizaci založené na LDAP. Pokud jde o bezpečnost, MongoDB by měl být neustále aktualizován a protokoly by měly být vždy kontrolovány na neoprávněný přístup. Například se mi líbí vybrat jiný port jako výchozí port.

Nezapomeňte spojit svůj útočný povrch s MongoDB

Kontrolní seznam zabezpečení MongoDB obsahuje dobré tipy pro snížení rizika narušení sítě a úniku dat. Je snadné to oprášit a říci, že vývojový server nepotřebuje vysokou úroveň zabezpečení. Není to však tak jednoduché a platí to pro všechny servery MongoDB. Zejména pokud neexistuje žádný závažný důvod k použití mapReduce, group nebo $ kde, musíte zakázat použití libovolného kódu v JavaScriptu zápisem do konfiguračního souboru javascriptEnabled:false. Vzhledem k tomu, že datové soubory nejsou ve standardním MongoDB šifrovány, má smysl spouštět MongoDB Vyhrazený uživatel, který má plný přístup k souborům, s omezeným přístupem pouze k němu a možností používat vlastní řízení přístupu k souborům operačního systému.

Chyba při vývoji obvodu

MongoDB nepoužívá schéma. To však neznamená, že schéma není potřeba. Pokud chcete pouze ukládat dokumenty bez jakéhokoli konzistentního vzoru, může být jejich uložení rychlé a snadné, ale jejich pozdější načtení může být obtížné. zatraceně těžké.

Klasický článek"6 pravidel palce pro návrh schématu MongoDB" Stojí za přečtení a funkce jako Průzkumník schémat v nástroji třetí strany Studio 3T se vyplatí používat pro pravidelné kontroly obvodů.

Nezapomeňte na pořadí řazení

Zapomenutí pořadí řazení může způsobit větší frustraci a ztrátu času než jakákoli jiná nesprávná konfigurace. Ve výchozím nastavení používá MongoBD binární řazení. Ale je nepravděpodobné, že by to bylo pro někoho užitečné. Binární druhy rozlišující velká a malá písmena a přízvuk byly považovány za podivné anachronismy spolu s korálky, kaftany a kudrnatými kníry v 80. letech minulého století. Nyní je jejich použití neodpustitelné. V reálném životě je „motocykl“ stejný jako „motocykl“. A „Británie“ a „Británie“ jsou stejné místo. Malé písmeno je prostě velký ekvivalent velkého písmene. A nenuťte mě, abych začal s tříděním diakritiky. Při vytváření databáze v MongoDB použijte řazení bez zvýraznění a Registrovat, které odpovídají jazyku a uživatelská kultura systému. To výrazně usnadní vyhledávání v datech řetězců.

Vytvářejte kolekce s velkými dokumenty

MongoDB s potěšením hostuje velké dokumenty až do 16 MB ve sbírkách a GridFS Určeno pro velké dokumenty větší než 16 MB. Ale právě proto, že se tam dají umístit velké dokumenty, není dobrý nápad je ukládat. MongoDB bude fungovat nejlépe, pokud uložíte jednotlivé dokumenty o velikosti několika kilobajtů a budete s nimi zacházet spíše jako s řádky v široké tabulce SQL. Velké dokumenty budou zdrojem problémů produktivita.

Vytváření dokumentů s velkými poli

Dokumenty mohou obsahovat pole. Nejlepší je, když je počet prvků v poli daleko od čtyřmístného čísla. Pokud jsou prvky přidávány do pole často, přeroste dokument, který je obsahuje, a bude třeba pohybovat, což znamená, že to bude nutné aktualizovat také indexy. Při opětovném indexování dokumentu s velkým polem budou indexy často přepsány, protože existuje a záznam, který ukládá jeho index. K tomuto opětovnému indexování dochází také při vložení nebo odstranění dokumentu.

MongoDB má něco, co se nazývá "faktor plnění", která poskytuje prostor pro růst dokumentů, aby se tento problém minimalizoval.
Možná si myslíte, že se obejdete bez indexování pole. Bohužel nedostatek indexů může způsobit další problémy. Protože se dokumenty skenují od začátku do konce, hledání prvků na konci pole bude trvat déle a většina operací spojených s takovým dokumentem bude pomalý.

Nezapomeňte, že na pořadí fází v agregaci záleží

V databázovém systému s optimalizátorem dotazů jsou dotazy, které píšete, vysvětlením toho, co chcete získat, nikoli tím, jak to získat. Tento mechanismus funguje analogicky s objednáváním v restauraci: obvykle si jednoduše objednáte jídlo a nedáváte kuchaři podrobné pokyny.

V MongoDB dáváte pokyn kuchaři. Musíte se například ujistit, že data procházejí reduce co nejdříve v potrubí pomocí $match и $project, a řazení probíhá až poté reducea že vyhledávání probíhá přesně v požadovaném pořadí. Mít optimalizátor dotazů, který eliminuje zbytečnou práci, optimálně sekvenuje kroky a vybírá typy spojení, vás může zkazit. S MongoDB máte větší kontrolu za cenu pohodlí.

Nástroje jako Studio 3T zjednoduší konstrukci agregačních dotazů v MongoDB. Funkce Editor agregace vám umožňuje aplikovat příkazy potrubí jednu fázi po druhé a kontrolovat vstupní a výstupní data v každé fázi, aby se zjednodušilo ladění.

Použití rychlého nahrávání

Nikdy nenastavujte možnosti zápisu MongoDB tak, aby měly vysokou rychlost, ale nízkou spolehlivost. Tento režim "soubor a zapomeň" se zdá být rychlý, protože příkaz je vrácen dříve, než dojde k zápisu. Pokud se systém zhroutí ještě před zápisem dat na disk, budou ztracena a skončí v nekonzistentním stavu. Naštěstí má 64bitový MongoDB povoleno protokolování.

Úložné enginy MMAPv1 a WiredTiger používají protokolování, aby tomu zabránily, ačkoli WiredTiger se může obnovit do posledního konzistentního kontrolní bod, pokud je zakázáno protokolování.

Žurnálování zajišťuje, že databáze je po obnově v konzistentním stavu a uchovává všechna data, dokud nejsou zapsána do protokolu. Frekvence nahrávek se konfiguruje pomocí parametru commitIntervalMs.

Chcete-li si být jisti položkami, ujistěte se, že je v konfiguračním souboru povoleno protokolování (storage.journal.enabled)a frekvence nahrávek odpovídá množství informací, které si můžete dovolit ztratit.

Řazení bez indexu

Při vyhledávání a agregaci je často potřeba data třídit. Doufejme, že se tak stane v jedné z posledních fází, po filtrování výsledku, aby se snížilo množství tříděných dat. A i v tomto případě pro třídění budete potřebovat index. Můžete použít jednoduchý nebo složený index.

Pokud neexistuje vhodný index, MongoDB se bez něj obejde. Celková velikost všech dokumentů v paměti je omezena na 32 MB třídicí operacea pokud MongoDB dosáhne tohoto limitu, pak buď vyvolá chybu, nebo se vrátí prázdná sada záznamů.

Vyhledávání bez podpory indexu

Vyhledávací dotazy provádějí funkci podobnou operaci JOIN v SQL. Aby fungovaly co nejlépe, potřebují index hodnoty klíče použitého jako cizí klíč. To není zřejmé, protože použití se neodráží v explain(). Takové indexy se zapisují navíc k indexu explain(), který zase využívají provozovatelé potrubí $match и $sort, když se setkají na začátku potrubí. Indexy nyní mohou pokrývat jakoukoli fázi agregační potrubí.

Odhlášení z používání více aktualizací

metoda db.collection.update() slouží ke změně části existujícího dokumentu nebo celého dokumentu až po kompletní nahrazení, v závislosti na vámi zadaném parametru update. Co není tak zřejmé je, že nezpracuje všechny dokumenty v kolekci, pokud tuto možnost nenastavíte multi aktualizovat všechny dokumenty, které splňují kritéria požadavku.

Nezapomeňte na důležitost pořadí klíčů v hashovací tabulce

V JSON se objekt skládá z neuspořádané kolekce velikosti nula nebo více párů název/hodnota, kde název je řetězec a hodnota je řetězec, číslo, logická hodnota, null, objekt nebo pole.

Bohužel BSON klade velký důraz na pořádek při vyhledávání. V MongoDB, pořadí klíčů v rámci vestavěných objektů záležitosti, tj. { firstname: "Phil", surname: "factor" } - to není totéž jako { { surname: "factor", firstname: "Phil" }. To znamená, že musíte uložit pořadí párů název/hodnota ve svých dokumentech, pokud si chcete být jisti jejich nalezením.

Nepleťte se "Nula" и "nedefinováno"

Hodnota "nedefinováno" nebyl nikdy platný v JSON, podle oficiální standard JSON (ECMA-404 sekce 5), i když se používá v JavaScriptu. Navíc pro BSON je zastaralý a je převeden na $null, což není vždy dobré řešení. Vyhněte se používání "nedefinováno" v MongoDB.

Použití $limit() без $sort()

Docela často, když vyvíjíte v MongoDB, je užitečné vidět pouze vzorek výsledku, který bude vrácen z dotazu nebo agregace. Pro tento úkol budete potřebovat $limit(), ale nikdy by neměl být ve finálním kódu, pokud jej předtím nepoužijete $sort. Tato mechanika je nezbytná, protože jinak nemůžete zaručit pořadí výsledku a nebudete moci spolehlivě zobrazit data. V horní části výsledku se zobrazí různé položky v závislosti na řazení. Aby dotazy a agregace fungovaly spolehlivě, musí být deterministické, to znamená, že pokaždé, když jsou provedeny, musí produkovat stejné výsledky. Kód, který obsahuje $limit(), ale ne $sort, nebude deterministický a může následně způsobit chyby, které bude obtížné dohledat.

Závěr

Jediný způsob, jak být zklamán MongoDB, je porovnat ji přímo s jiným typem databáze, jako je DBMS, nebo ji začít používat na základě určitých očekávání. Je to jako srovnávat pomeranč s vidličkou. Databázové systémy slouží specifickým účelům. Nejlepší je jednoduše pochopit a ocenit tyto rozdíly pro sebe. Byla by škoda tlačit na vývojáře MongoDB kvůli cestě, která je přinutila jít cestou DBMS. Chci vidět nové a zajímavé způsoby řešení starých problémů, jako je zajištění integrity dat a vytváření datových systémů, které jsou odolné vůči selhání a škodlivým útokům.

Zavedení transakčnosti ACID od MongoDB ve verzi 4.0 je dobrým příkladem zavedení důležitých vylepšení inovativním způsobem. Transakce s více dokumenty a více výpisy jsou nyní atomické. Je také možné upravit čas potřebný k získání zámků a ukončení zaseknutých transakcí a také změnit úroveň izolace.

14 věcí, které bych si přál vědět, než jsem začal s MongoDB

Přečtěte si více:

Zdroj: www.habr.com

Přidat komentář