Nasazení klastrů má velký význam pro zajištění vysoké dostupnosti dat a také pro jejich ochranu. MongoDB to zlepšuje prostřednictvím replikace a shardingu, přičemž replikace zajišťuje vertikální škálování prostřednictvím redundance liftingu, zatímco sharding navyšuje horizontální škálování.
Obecně se oba přístupy snaží rozdělit pracovní zátěž mezi členy a tím snížit zátěž, které by mohl být vystaven jeden uzel. Výkon databáze pak lze považovat za rychlý při obsluze uživatelů s operacemi propustnosti. Bez prvotřídní architektury clusteru však nemusíte vidět stejnou úroveň výsledků, i když se pokusíte o sdílení a replikaci.
Pokud jsou členové sady replik sudí, pak bude pro členy těžké hlasovat a volit nové primární volby, pokud stávající v určitém okamžiku selže. V tomto blogu budeme diskutovat o standardní architektuře nasazení, kterou lze použít, ale ta se může lišit podle požadavků aplikace.
Strategie nasazení MongoDB
Architektura sad replik je velmi určující pro kapacitu a schopnosti MongoDB.
Sada tří uzlových replik je standardním nasazením clusteru pro MongoDB v jakémkoli produkčním prostředí, protože poskytuje redundanci dat a odolnost proti chybám. Redundance je důležitá zejména při obnově databáze po havárii. Základní architekturou nasazení může být sada tří uzlových replik, ale to se může lišit podle specifikací aplikace a požadavků. Nedělejte to však příliš složité, protože to může vést k větším konfiguračním problémům.
Strategie sdílení MongoDB
Sharding snižuje pracovní zátěž, na které má databáze pro daný dotaz pracovat, tím, že snižuje počet dokumentů, se kterými je třeba pracovat. Zlepšuje proto horizontální škálování a umožňuje databázi růst nad hardwarové limity jednoho serveru. V závislosti na požadavcích pracovní zátěže lze přidávat nebo odebírat uzly z clusteru a MongoDB znovu vyváží data optimálním způsobem bez zásahu operace.
Některé z nejlepších strategií nasazení pro sdílený cluster zahrnují:
Zajištění jednotné distribuce sdílených klíčů
Důvodem shardingu je horizontální škálování databáze a snížení počtu operací propustnosti, kterým může být vystavena jedna instance. Pokud nerozmístíte úlomkové klíče jednotně, můžete skončit s malým počtem úlomků. S malým počtem útržků mohou být operace omezeny kapacitou jednoho útržku, a proto jsou operace čtení a zápisu pomalé.
Chunky by měly být předem rozděleny a distribuovány jako první
Shardy mají datové bloky, které jsou seskupeny podle některých kritérií shard key. Při vytváření nové sdílené kolekce byste před načtením dat měli vytvořit prázdné bloky a rozmístit je rovnoměrně na všechny fragmenty. Když budete naplňovat MongoDB daty, bude snadné vyvážit zátěž mezi zapojenými úlomky. Možnost numInitialChunks lze použít k automatickému provedení, pokud používáte sharding na bázi hash. Hodnota celého čísla by však měla být menší než 8192 na fragment.
Počet úlomků
Často jsou vyžadovány dva úlomky jako minimální počet pro dosažení významnosti úlomků. Jediný shard je užitečný pouze v případě, že chcete položit základy pro umožnění shardingu v budoucnu a bez potřeby během doby nasazení.
Upřednostňovat sharování na základě rozsahu před sdílením na základě hash
Sharding na základě rozsahu je výhodný, protože poskytuje více fragmentů, takže operace mohou být směrovány na nejmenší počet potřebných fragmentů a častěji na jeden fragment. Prakticky to může být obtížné, pokud dobře nerozumíte příslušným datům a vzorcům dotazů. Hašované sharding zlepšuje rovnoměrnou distribuci propustnosti na úkor poskytování operací s nižším dosahem.
Použít dotazy typu Scatter-Gather pouze pro velké agregační dotazy
Dotazy, které nelze směrovat na základě fragmentového klíče, by se měly vysílat do všech fragmentů k vyhodnocení, a protože zahrnují více fragmentů pro každý požadavek, neškálují se lineárně, protože se přidávají další fragmenty, čímž vzniká režie což snižuje výkon databáze. Tato operace je známá jako scatter-gather a lze se jí vyhnout pouze tehdy, pokud do dotazu zahrnete shard klíč.
Tento přístup je užitečný pouze při řešení velkých agregačních dotazů, kdy každý dotaz může běžet paralelně na všech fragmentech.
Strategie replikace MongoDB
Replikace vylepšuje vertikální škálování v MongoDB tak, aby byla pracovní zátěž rozdělena mezi zúčastněné členy. V produkčním prostředí jsou to některé z úvah, které je třeba vzít v úvahu pro optimální architekturu clusteru.
Počet uzlů
Maximální počet uzlů, které může sada replik mít, je 50 se 7 hlasujícími členy. Každý člen po 7. dni je považován za nehlasujícího. Dobrý klastr by proto měl mít 7 hlasujících členů, aby byl volební proces pohodlný.
Nasaďte lichý počet hlasujících členů a pokud máte pouze méně než 7, ale sudý počet členů, budete muset nasadit arbitra jako dalšího hlasujícího člena. Rozhodčí neukládají kopie dat, a proto budou vyžadovat méně prostředků na správu. Kromě toho je můžete vystavit prostředí, které byste nemohli vystavit ostatním členům.
Úvahy o odolnosti vůči chybám
Někdy se někteří členové mohou stát nedostupnými v důsledku faktorů, jako jsou výpadky proudu nebo přechodné jevy a odpojení sítě. Počet členů, kteří zůstávají v množině a jsou schopni zvolit primární, vytváří situaci známou jako Fault tolerance. Jde tedy o rozdíl mezi celkovým počtem členů sady replik a většinou hlasujících členů potřebných ke zvolení primárek. Absence primárního určuje, že operace zápisu nelze provést.
Tabulka níže ukazuje vzorový vztah mezi těmito třemi.
| Celkový počet členů sady replik | K zvolení nového primáře je vyžadována většina | Tolerance chyb |
| 3 | 2 | 1 |
| 4 | 3 | 1 |
| 5 | 3 | 2 |
| 6 | 4 | 2 |
| 7 | 5 | 2 |
Vztah není tak přímý v tom, že pokud do sady přidáte další členy, neznamená to, že se odolnost proti chybám zvýší, jak je vidět z tabulky. Další členové poskytují podporu pro vyhrazené funkce, jako je zálohování a vytváření sestav.
Plánování kapacity a vyrovnávání zátěže pro náročné čtení
Potřebujete mít volnou kapacitu pro své nasazení přidáním nových členů, než aktuální poptávka nasytí kapacitu stávající sady.
Pro velmi vysoký provoz při čtení rozdělte propustnost čtení na sekundární členy a kdykoli se klastr rozroste, přidejte nebo přesuňte členy do alternativních datových center, abyste dosáhli redundance a zvýšili dostupnost dat.
Můžete také použít cílové operace se sadami značek k zacílení operací čtení na konkrétní členy nebo k úpravě zájmu o zápis tak, aby bylo požadováno potvrzení od konkrétních členů.
Uzly by měly být rozmístěny geograficky
Datová centra mohou také selhat kvůli nějaké katastrofě . Proto se doporučuje ponechat alespoň jednoho nebo dva členy v samostatném datovém centru pro účely ochrany údajů. Pokud je to možné, použijte lichý počet datových center a vyberte distribuci, která maximalizuje pravděpodobnost, že i při ztrátě datového centra mohou zbývající členové sady replik tvořit většinu nebo alespoň poskytnout kopii dat.
Zaměstnávejte žurnálování pro neočekávaná selhání
Ve výchozím nastavení je toto v MongoDB povoleno. Měli byste se ujistit, že je tato možnost povolena, abyste ochránili ztrátu dat v případě přerušení služby, jako jsou náhlé restarty a výpadky napájení.
Vzory nasazení
Existují hlavně dva přístupy k nasazení, a to:
- Tři členské sady replik, které poskytují minimální doporučenou architekturu pro sadu replik.
- Sada replik distribuovaná ve dvou nebo více datových centrech k ochraně proti specifickým poruchám zařízení, jako je výpadek napájení.
Vzory však závisí na požadavcích aplikace, ale pokud je to možné, můžete v architektuře nasazení kombinovat funkce těchto dvou.
Názvy hostitelů a pojmenování sady replik
Při konfiguraci členů sady replik nebo členů sdíleného klastru použijte místo IP adresy logický název hostitele DNS. Je to proto, abyste se vyhnuli bolesti spojené se změnami konfigurace, které budete muset provést v důsledku změněných IP adres.
V případě pojmenování sady replik použijte pro sady odlišné názvy, protože některé ovladače seskupují připojení sady replik podle názvu sady replik.
Závěr
Rozvržení architektury pro sadu replik určuje kapacitu a možnosti vašeho nasazení. Ochrana dat a výkon systému jsou hlavními faktory při nastavování architektury. Je třeba vzít v úvahu zásadní faktory, jako je odolnost proti chybám, počet členů sady replik, optimální klíč sdílení a vzory nasazení pro vysokou dostupnost a ochranu dat. Geografická distribuce uzlů sady replik může vyřešit mnoho z těchto faktorů zajištěním redundance a zajištěním odolnosti proti chybám, pokud jedno z datových center chybí.