Nasazení klastrované databáze je jedna věc, ale způsob údržby DBM v klastru může být velký úkol pro konzistentní obsluhu vašich aplikací. Člověk by měl mít často aktualizované informace o stavu databáze, konkrétněji o nejdůležitějších metrikách, aby získal představu o tom, co upgradovat nebo spíše změnit jako způsob, jak předejít případným úzkým hrdlům.
Existuje mnoho aspektů týkajících se MongoDB, které byste měli vzít v úvahu zejména skutečnost, že jeho instalace a spuštění jsou poměrně snadné, šance na zanedbání základních postupů správy databází jsou vysoké.
Mnoho vývojářů občas nedokáže vzít v úvahu budoucí růst a zvýšené využití databáze, což má za následek pád aplikace nebo dat s určitými problémy s integritou, kromě toho, že jsou nekonzistentní.
V tomto článku budeme diskutovat o některých osvědčených postupech, které byste měli použít pro cluster MongoDB pro efektivní výkon vašich aplikací. Některé z faktorů, které je třeba zvážit, zahrnují...
- Upgrade na nejnovější verzi
- Vhodný modul úložiště
- Přidělení hardwarových prostředků
- Replikace a sdílení
- Nikdy neměňte konfigurační soubor serveru
- Dobrá bezpečnostní strategie
Upgrade na nejnovější verzi
Pracoval jsem s MongoDB z verzí před 3.2 a abych byl upřímný, v té době to nebylo jednoduché. Díky skvělému vývoji, opraveným chybám a nově zavedeným funkcím vám poradím, abyste vždy aktualizovali svou databázi na nejnovější verzi. Například zavedení agregačního rámce mělo lepší dopad na výkon než spoléhání na koncept Map-Reduce, který již existoval. S nejnovější verzí 4.0 je nyní možné využívat funkci transakcí s více dokumenty, která obecně zlepšuje propustnost operací. Nejnovější verze má také některé další nové operátory konverze typu, jako jsou $toInt, $toString, $trim a $toBool. Tyto operátory výrazně pomohou při ověřování dat, a tím vytvářejí určitý pocit konzistence dat. Při upgradu se prosím řiďte dokumentem, abyste se vyhnuli drobným chybám, které by mohly vést k chybám.
Vyberte si vhodný modul úložiště
MongoDB nyní podporuje 3 úložné motory:WiredTiger, In-Memory a MMAPv1. Každý z těchto úložišť má své přednosti a omezení oproti druhému, ale váš výběr bude záviset na specifikaci vaší aplikace a základní funkčnosti enginu. Osobně však preferuji úložiště WiredTiger a doporučil bych jej pro toho, kdo si není jistý, který z nich použít. Úložný modul WiredTiger se dobře hodí pro většinu pracovních zátěží, poskytuje model souběžnosti na úrovni dokumentu, kontrolní body a kompresi.
Některé úvahy týkající se výběru úložného enginu jsou závislé na těchto aspektech:
- Transakce a atomicita: poskytování dat během vkládání nebo aktualizace, která je potvrzena pouze tehdy, když byly úspěšně provedeny všechny podmínky a fáze aplikace. Operace jsou proto spojeny do neměnné jednotky. Díky tomu může být podporována transakce s více dokumenty, jak je vidět v nejnovější verzi MongoDB pro úložiště WiredTiger.
- Typ uzamčení: je to kontrolní strategie přístupu nebo aktualizace informací. Během trvání uzamčení nemůže žádná jiná operace změnit data vybraného objektu, dokud nebude provedena aktuální operace. V důsledku toho jsou v tuto chvíli ovlivňovány dotazy, a proto je důležité je sledovat a snížit objem zamykacího mechanismu tím, že zajistíte výběr nejvhodnějšího úložiště pro vaše data.
- Indexování: Úložné stroje v MongoDB poskytují různé strategie indexování v závislosti na typech dat, která ukládáte. Efektivita této datové struktury by měla být docela přátelská k vašemu pracovnímu vytížení a lze to určit tak, že každý další index bude mít určitou režii na výkon. Datové struktury optimalizované pro zápis mají nižší režii pro každý index v prostředí aplikací s vysokým počtem vložení než datové struktury bez optimalizovaného zápisu. To bude velká překážka zejména tam, kde se jedná o velký počet indexů a výběr nevhodného úložiště. Výběr vhodného úložiště může mít proto dramatický dopad.
Přidělení hardwarových prostředků
Jak se do vaší aplikace přihlašují noví uživatelé, databáze se časem rozrůstá a budou zaváděny nové úlomky. Nemůžete se však spoléhat na hardwarové prostředky, které jste vytvořili během fáze nasazení. Dojde k odpovídajícímu nárůstu pracovní zátěže, a proto bude vyžadovat více prostředků na zpracování, jako je CPU a RAM pro podporu vašich velkých datových clusterů. To je často označováno jako plánování kapacity v MongoDB. Mezi osvědčené postupy týkající se plánování kapacity patří:
- Neustále sledujte svou databázi a upravujte ji podle očekávání. Jak již bylo zmíněno dříve, zvýšení počtu uživatelů bude od nynějška spouštět více dotazů se zvýšeným pracovním zatížením, zejména pokud používáte indexy. Tyto dopady na konec aplikace můžete začít pociťovat, když začne zaznamenávat změnu procenta zápisů oproti čtení s časem. Budete proto muset překonfigurovat konfiguraci hardwaru, abyste tento problém vyřešili. Použijte mongoperf a nástroj MMS k detekci změn v parametrech výkonu systému.
- Všechny požadavky na výkon předem zdokumentujte. Když narazíte na stejný problém, budete mít alespoň referenční bod, který vám ušetří čas. Vaše nahrávání by mělo zahrnovat velikost dat, která chcete uložit, analýzu dotazů z hlediska latence a množství dat, ke kterým byste chtěli v daném čase přistupovat. V produkčním prostředí musíte určit, kolik požadavků za sekundu zpracujete, a nakonec, jakou latenci budete tolerovat.
- Připravte důkaz konceptu. Proveďte návrh schématu/indexu a pochopte vzory dotazů a poté zpřesněte svůj odhad velikosti pracovní sady. Zaznamenejte si tuto konfiguraci jako referenční bod pro testování s následnými revizemi aplikace.
- Proveďte své testy se skutečnou pracovní zátěží. Po provedení fáze ověření konceptu nasaďte až po provedení důkladného testování s reálnými daty a požadavky na výkon.
Replikace a sdílení
Toto jsou dva hlavní koncepty zajištění vysoké dostupnosti dat a zvýšené horizontální škálovatelnosti v clusteru MongoDB.
Sdílení v podstatě rozděluje data mezi servery na malé části známé jako úlomky. Vyrovnávání dat mezi datovými fragmenty je automatické, fragmenty lze přidávat nebo odebírat, aniž by bylo nutné databázi přepínat do režimu offline.
Replikace na druhém konci udržuje více redundantních kopií dat pro vysokou dostupnost. Je to vestavěná funkce v MongoDB a funguje v rozsáhlých sítích bez potřeby specializovaných sítí. Pro nastavení clusteru doporučuji mít alespoň 2+ mongo, 3 konfigurační servery, 1 shard, abyste zajistili konektivitu mezi stroji zapojenými do sdíleného clusteru. V konfiguraci použijte místo IP název DNS.
Pro produkční prostředí použijte sadu replik s alespoň 3 členy a nezapomeňte naplnit více konfiguračních proměnných, jako je velikost oplogu.
Při spouštění instancí mongodů pro vaše členy použijte stejný soubor klíče.
Některé z úvah týkajících se vašeho shardkey by měly zahrnovat:
- Klíč a hodnota jsou neměnné
- Vždy zvažte použití indexů ve sdílené kolekci
- Příkaz aktualizace ovladače by měl obsahovat klíčový klíč
- Jedinečná omezení, která mají být zachována pomocí shard key.
- Shard key nemůže obsahovat speciální typy indexů a nesmí přesáhnout 512 bajtů.
Nikdy neměňte konfigurační soubor serveru
Po prvním nasazení je vhodné neměnit mnoho parametrů v konfiguračním souboru, jinak se můžete dostat do problémů, zejména s úlomky. Nejslabším článkem shardingu jsou konfigurační servery. To znamená, že všechny instance mongodů musí být spuštěny, aby sharding fungoval.
Dobrá bezpečnostní strategie
MongoDB byl v posledních letech zranitelný vůči externím útokům, a proto je důležité, aby vaše databáze měla nějaké bezpečnostní protokoly. Kromě spouštění procesů na různých portech je třeba použít alespoň jeden z 5 různých způsobů zabezpečení databází MongoDB. Můžete zvážit platformy, jako je MongoDB Atlas, které ve výchozím nastavení zajišťují databáze pomocí šifrování dat při přenosu i v klidu. Můžete použít strategie jako TLS/SSL pro všechna příchozí a odchozí připojení.
Závěr
Ovládání clusteru MongoDB není snadný úkol a zahrnuje spoustu řešení. Databáze rostou v důsledku většího počtu uživatelů, a tím i zvýšené pracovní zátěže. Společnost On má proto mandát zajistit, aby byl výkon DBM v souladu s tímto zvýšeným počtem uživatelů. Osvědčené postupy jdou nad rámec zvyšování hardwarových zdrojů a používání některých konceptů MongoDB, jako je sharding, replikace a indexování. Mnoho nepříjemností, které mohou nastat, je však dobře vyřešeno aktualizací vaší verze MongoDB. Nejnovější verze mají častěji opravené chyby, integrované požadavky na nové funkce a téměř žádný negativní dopad na upgrade, a to ani s velkými čísly revizí.