Preklad článku bol pripravený v predstihu pred začiatkom kurzu .
Hlavné body:
- Je veľmi dôležité vypracovať schému, aj keď v MongoDB nie je povinná.
- Rovnako musia byť indexy prispôsobené vašej schéme a prístupovým vzorcom.
- Vyhnite sa používaniu veľkých objektov a rozsiahlych polí.
- Buďte opatrní s nastaveniami MongoDB, najmä pokiaľ ide o bezpečnosť a spoľahlivosť.
- V MongoDB nie je optimalizátor dotazov, preto by ste mali byť opatrní pri vykonávaní dotazovacích operácií.
Dlho pracujem s databázami, ale nedávno som objavil MongoDB. Existuje niekoľko vecí, ktoré by som chcel vedieť pred začiatkom práce s ňou. Keď má človek už skúsenosti v určitej oblasti, existujú určité predsudky o tom, čo sú databázy a čo robia. V nádeji, že uľahčím pochopenie iným, predstavujem zoznam bežných chýb.
Vytvorenie servera MongoDB bez autentifikácie
Bohužiaľ, MongoDB je predvolene inštalovaná bez autentifikácie. Pre pracovnú stanicu, ku ktorej sa pristupuje lokálne, je takéto nastavenie akceptovateľné. Ale keďže MongoDB je systém s viacerými používateľmi, ktorý rád používa veľké množstvá pamäte, bolo by lepšie nainštalovať ju na server s maximálnym možným množstvom RAM vo vašich podmienkach, aj keď ju plánujete používať len na vývoj. Inštalácia na server cez predvolený port môže byť problematická, najmä ak je možné vykonať akýkoľvek kód v jazyku JavaScript v dotaze (napríklad, $where ako nápad pre ).
Existuje niekoľko metód autentifikácie, ale najjednoduchšie je nastaviť ID/heslo pre používateľa. Využite tento nápad, kým premýšľate nad zložitými autentifikačnými metódami. Pokiaľ ide o bezpečnosť, MongoDB by sa mala neustále aktualizovať a protokoly by sa mali pravidelne kontrolovať na neautorizovaný prístup. Napríklad, rád si vyberiem iný port ako predvolený.
Nezabudnite pripevniť povrch útoku k MongoDB
obsahuje dobré rady na sníženie rizika prieniku do siete a úniku dát. Je ľahké mávnuť rukou a povedať, že server pre vývoj nevyžaduje vysokú úroveň zabezpečenia. Avšak všetko nie je tak jednoduché a to platí pre všetky servery MongoDB. Najmä ak neexistuje presvedčivý dôvod na používanie , alebo , je potrebné zakázať používanie svojho vlastného kódu v JavaScripte úpravou konfiguračného súboru . Keďže v štandardnej MongoDB nie sú súbory dát zašifrované, je rozumné spustiť MongoDB s , ktorý má plný prístup k súborom, s obmedzeným prístupom iba pre neho a možnosťou používať vlastné prostriedky na spravovanie prístupu k súborom operačného systému.
Chyba pri navrhnutí schémy
MongoDB nepoužíva schému. Ale to neznamená, že schéma nie je potrebná. Ak chcete jednoducho uchovávať dokumenty bez akejkoľvek konzistentnej schémy, ukladanie je rýchle a jednoduché, ale ich neskoršie získanie môže byť .
Klasický článok „ stojí za prečítanie a také funkcie ako v externom nástroji Studio 3T by sa mali používať na pravidelné kontroly schémy.
Nezabudnite na poradie triedenia
Zabudnúť na poradie triedenia môže byť najväčším sklamaním a môžete stratiť viac času než pri akejkoľvek inej nesprávnej konfigurácii. Predvolená MongoDB používa . Ale ťažko povedať, že by to niekomu pomohlo. Citlivé na veľké/malé písmená, binárne triedenia sa považovali za zaujímavé anachronizmy spolu s perlami, kaftanmi a zakrivenými fúzmi ešte v 80-tych rokoch minulého storočia. Teraz je ich použitie neodpustiteľné. V reálnom živote je "motorbike" to isté ako "Motorbike". A "Británia" a "británia" sú to isté miesto. Malé písmeno je jednoducho veľkým ekvivalentom veľkého písmena. A nenechajte ma rozprávať o triedení diakritických znamienok. Pri vytváraní databázy v MongoDB použite parametre triedenia bez ohľadu na diakritiku a , ktoré odpovedajú jazyku a . Tak výrazne zjednodušíte vyhľadávanie v reťazcových údajoch.
Vytvorenie kolekcií s veľkými dokumentmi
MongoDB umožňuje uloženie veľkých dokumentov až do 16 MB v kolekciách, a je určená pre dokumenty väčšie ako 16 MB. Ale len preto, že je možné uložiť veľké dokumenty, neznamená, že je to najlepšia idea. Najlepšie funguje MongoDB, ak ukladáte jednotlivé dokumenty veľkosti niekoľkých kilobajtov, pričom ich skôr považujete za riadky v širokej SQL tabuľke. Veľké dokumenty môžu spôsobiť problémy s .
Vytváranie dokumentov s veľkými poľami
Dokumenty môžu obsahovať polia. Najlepšie je, ak počet prvkov v poli nie je blízko štyrom značkám. Ak sa prvky do poľa často pridávajú, prekročí obsahujúci dokument a bude potrebné ho , čo znamená, že bude potrebné . Pri opätovnej indexácii dokumentu s veľkým poľom sa indexy často prepisujú, pretože pod každý prvok existuje , ktorý uchováva jeho index. Takáto preindeksácia sa tiež deje, keď sa dokument vloží alebo odstráni.
V MongoDB existuje takzvaný , ktorý poskytuje priestor pre rast dokumentov, aby sa táto otázka minimalizovala.
Môžete si myslieť, že sa dá obísť bez indexovania polí. Bohužiaľ, kvôli absencii indexov môžu vzniknúť iné problémy. Pretože dokumenty sú prezerané od začiatku do konca, vyhľadávanie prvkov na konci poľa potrvá dlhšie a väčšina operácií súvisiacich s takýmto dokumentom bude .
Nezabudnite, že poradie etáp v agregácii je dôležité
V databázovom systéme s optimalizátorom dopytov sú dopyty, ktoré píšete, vysvetlením toho, čo chcete získať, a nie toho, ako to získať. Tento mechanizmus funguje podľa analógie s objednávkou v reštaurácii: obyčajne jednoducho objednávate jedlo, a nie dávate podrobné pokyny kuchárovi.
V MongoDB príkazy inštruujete kuchára. Napríklad, treba zabezpečiť, aby dáta prešli cez reduce čo najskôr v pipeline pomocou $match a $project, zatiaľ čo triedenie prebieha až po reduce, a vyhľadávanie prebieha presne v tom poradí, v ktorom potrebujete. Prítomnosť optimalizátora dopytov, ktorý zbaví zbytočnej práce, optimálne usporiada fázy a vyberie typ pripojenia, vás môže rozmaznávať. V MongoDB získavate viac kontroly výmenou za pohodlie.
Nástroje ako uľahčia zostavenie dopytov agregácie v . Funkcia Aggregation Editor vám umožní aplikovať operátory pipeline po jednom kroku naraz a skontrolovať vstupy a výstupy v každom kroku pre uľahčenie ladenia.
Používanie rýchlej zápisu
Nikdy nenastavujte v MongoDB parametre zápisu s vysokou rýchlosťou, ale nízkou spoľahlivosťou. Tento režim „file-and-forget“ sa javí rýchly, pretože príkaz sa vracia predtým, než sa vykoná zápis. Ak systém havaruje skôr, než budú dáta zapísané na disk, stratia sa a budú v nekonzistentnom stave. Našťastie 64-bitový MongoDB má zapnuté logovanie.
Úložné motory MMAPv1 a WiredTiger používajú logovanie, aby tomu zabránili, hoci WiredTiger sa môže obnoviť do posledného konzistentného , ak je logovanie vypnuté.
Logovanie zabezpečuje, že databáza je v konzistentnom stave po obnovení a uchováva všetky údaje do momentu zapísania do protokolu. Frekvencia zápisov sa nastavuje pomocou parametra .
Aby ste sa uistili v zápisoch, overte, že v konfiguračnom súbore je logovanie zapnuté ), a frekvencia zápisov zodpovedá objemu informácií, ktorý si môžete dovoliť stratiť.
Zoradenie bez indexu
Pri vyhľadávaní a agregovaní často nastáva potreba zoradenia údajov. Dúfajme, že to robíte na jednom z konečných krokov, po filtrovaní výsledkov s cieľom zmenšiť objem zoradovaných údajov. A aj v takom prípade budete potrebovať . Môžete použiť jednoduchý alebo zložený index.
Ak vhodný index neexistuje, MongoDB sa zaobíde bez neho. Existuje pamäťové obmedzenie 32 MB na celkovú veľkosť všetkých dokumentov v , a ak MongoDB dosiahne tento limit, vráti buď chybu alebo .
Vyhľadávanie bez podpory indexov
Vyhľadávacie dopyty plnia funkciu podobnú operácii JOIN v SQL. Na lepšiu funkčnosť potrebujú index hodnoty kľúča, ktorý sa používa ako zahraničný kľúč. To nie je zjavné, pretože použitie nie je zobrazené v explain(). Tieto indexy sú doplnkom k indexu zapísanému v explain(), ktorý sa zase používa operátormi pipeline $match a $sort, keď sa objavia na začiatku pipeline. Indexy teraz môžu pokrývať akúkoľvek fázu .
Odstránenie použitia multi-aktualizácií
Metóda sa používa na zmenu časti existujúceho dokumentu alebo celého dokumentu, až do úplnej náhrady v závislosti od zadaného parametra . Nie je to také zjavné, že nevypracuje všetky dokumenty v kolekcii, pokiaľ nenastavíte parameter na aktualizáciu všetkých dokumentov, ktoré spĺňajú kritériá dopytu.
Nezabudnite na dôležitosť poradia kľúčov v hash tabuľke
V JSON je objekt zložený z neusporiadanej kolekcie veľkosti nula alebo viacerých párov názov/hodnota, kde názov je reťazec a hodnota je reťazec, číslo, booleovská hodnota, nula, objekt alebo pole.
Bohužiaľ, BSON priraďuje veľký význam poradiu pri vyhľadávaní. V MongoDB poradie kľúčov vnútri vnorených objektov , t.j. { firstname: "Phil", surname: "factor" } – to nie je to isté ako { { surname: "factor", firstname: "Phil" }. To znamená, že musíte uchovávať v dokumentoch poradie párov názov/hodnota, ak chcete mať istotu, že ich nájdete.
Nezamieňajte "null" a "undefined"
Hodnota "undefined" nikdy nebolo platné v JSON, podľa JSON (ECMA-404, Časť 5), aj keď sa používa v JavaScripte. Navyše, pre BSON je zastarané a prevádza sa na $null, čo nie vždy je dobré riešenie. .
Použitie $limit() bez $sort()
Veľmi často, keď vyvíjate v MongoDB, je užitočné len vidieť vzor výsledku, ktorý sa vráti z dopytu alebo agregácie. Na tento účel vám pomôže $limit(), ale nikdy by to nemalo byť vo finálnej verzii kódu, pokiaľ pred ním nepoužívate $sortTáto mechanika je potrebná, pretože inak nemôžete zaručiť poradie výsledkov a nemôžete spoľahlivo prezerať údaje. Na vrchole výsledku dostanete rôzne záznamy v závislosti od triedenia. Pre spoľahlivú funkciu musia byť dotazy a agregácie deterministické, teda musia vracať rovnaké výsledky pri každom vykonaní. Kód, v ktorom je $limit(), ale nie $sort, nebude považovaný za deterministický a môže neskôr spôsobiť chyby, ktoré bude ťažké sledovať.
Záver
Jediný spôsob, ako sa sklamať v MongoDB, je priamo ju porovnávať s iným typom databáz, ako je RDBMS, alebo prísť k jej používaniu na základe určitých očakávaní. Je to ako porovnávať pomaranč s vidlicou. Databázové systémy sledujú určité ciele. Najlepšie je jednoducho pochopiť a oceniť tieto rozdiely. Bolo by hanbou tlačiť na vývojárov MongoDB kvôli ceste, ktorou boli nútení ísť smerom RDBMS. Chcem vidieť nové a zaujímavé spôsoby, ako riešiť staré problémy, ako je zabezpečenie integrity údajov a vytváranie údajových systémov odolných voči poruchám a útokom zločincov.
Implementácia ACID transakcií v MongoDB vo verzii 4.0 je dobrým príkladom zavedenia dôležitých vylepšení inovatívnym spôsobom. Viacdokumentové a viacoperátorové transakcie sú teraz atomické. Rovnako sa objavila možnosť regulovať čas potrebný na získanie zámkov a končiť zablokované transakcie, ako aj meniť úroveň izolácie.
Čítať ďalej:
Zdroj: habr.com
