Po vývoji vaší aplikace a databázového modelu (když je čas přesunout prostředí do produkce) je třeba nejprve udělat několik věcí. Vývojáři často nevezmou v úvahu další důležité kroky MongoDB před nasazením databáze do produkce. V důsledku toho se v produkčním režimu setkávají se základními překážkami, které nejsou uvedeny ve vývojovém režimu. Někdy může být příliš pozdě nebo spíše dojde ke ztrátě velkého množství dat, pokud dojde ke katastrofě. Kromě toho některé ze zde probíraných kroků umožní změřit stav databáze, a tudíž naplánovat nezbytná opatření před katastrofou.
Použít aktuální verzi a nejnovější ovladače
Obecně platí, že nejnovější verze jakékoli technologie mají vylepšené funkce s ohledem na základní funkce než jejich předchůdci. Nejnovější verze MongoDB jsou robustnější a vylepšené než jejich předchůdci, pokud jde o výkon, škálovatelnost a kapacitu paměti. Totéž platí pro související ovladače, protože jsou vyvíjeny hlavními databázovými inženýry a jsou aktualizovány častěji než samotná databáze.
Nativní rozšíření nainstalovaná pro váš jazyk mohou snadno vytvořit platformu pro rychlé a standardní postupy testování, schvalování a upgradu nových ovladačů. Existuje také automobilový software, jako je Ansible, Puppet, SaltStack a Chef, který lze použít pro snadný upgrade MongoDB ve všech vašich uzlech, aniž byste museli vynakládat profesionální výdaje a čas.
Zvažte také použití úložiště WiredTiger, protože je nejrozvinutější s moderními funkcemi, které vyhovují očekáváním moderních databází
Přihlaste se k odběru e-mailové konference MongoDB a získejte nejnovější informace o změnách nových verzí a ovladačů a opravách chyb, a proto budete průběžně aktualizováni.
Použití 64bitového systému ke spuštění MongoDB
V 32bitových systémech jsou procesy MongoDB omezeny na přibližně 2,5 GB dat, protože databáze využívá k výkonu soubory mapované v paměti. To se stává omezením pro procesy, které mohou překročit hranici vedoucí k rozdrcení. Hlavní dopad bude:v případě chyby nebudete moci restartovat server, dokud neodstraníte svá data nebo nemigrujete databázi na vyšší systém, jako je 64bitový, tedy delší výpadek vaší aplikace.
Pokud musíte nadále používat 32bitový systém, vaše kódování musí být velmi jednoduché, aby se snížil počet chyb a latence pro operace propustnosti.
Avšak pro složité kódy, jako je agregační kanál a geodata, je vhodné použít 64bitový systém.
Ujistěte se, že jsou dokumenty omezeny na velikost 16 MB
Dokumenty MongoDB jsou omezeny na velikost 16 MB, ale tomuto limitu se nemusíte přibližovat, protože by to znamenalo určité snížení výkonu. V praxi mají dokumenty většinou velikost KB nebo méně. Velikost dokumentu závisí na strategii modelování dat mezi vkládáním a odkazováním. Vkládání je preferováno tam, kde se neočekává, že se velikost dokumentu příliš zvětší. Máte-li například aplikaci na sociálních sítích, kam uživatelé přidávají příspěvky a která obsahuje komentáře, nejlepším postupem bude mít dvě sbírky, v níž budou uloženy informace o příspěvku.
{
_id:1,
post: 'What is in your mind?',
datePosted: '12-06-2019',
postedBy:'xyz',
likes: 10,
comments: 30
}a druhé pro pozastavení komentářů k tomuto příspěvku.
{
_id: ObjectId('2434k23k4'),
postId: 1,
dateCommented: '12-06-2019',
commentedBy:'ABCD',
comment: 'When will we get better again',
}Díky takovým datovým modelům budou komentáře uloženy v jiné kolekci než příspěvek. To zabrání tomu, aby se dokument ve shromažďování příspěvků rozrostl z vazby v případě, že bude tolik komentářů. Ujistěte se, že se vyhnete vzorům aplikací, které by umožnily neomezený růst dokumentů.
Zajistěte, aby se pracovní sada vešla do paměti
Databáze může selhat při čtení dat z virtuální paměti (RAM), což vede k chybám stránky. Chyby stránek přinutí databázi číst data z fyzického disku, což povede ke zvýšení latence a následně ke zpoždění v celkovém výkonu aplikace. K chybám stránek dochází kvůli práci s velkou sadou, která se nevejde do paměti. To může být důsledkem toho, že některé dokumenty mají neomezenou velikost nebo špatnou strategii shardingu. Nápravy pro chyby stránky budou:
- Zajištění, že dokumenty jsou omezeny na velikost 16 MB.
- Zajištění dobré strategie sdílení výběrem optimálního klíče sdílení, který omezí počet dokumentů, kterým bude operace propustnosti vystavena.
- Zvětšete velikost instance MongoDB, aby se do ní vešlo více pracovních sad.
Ujistěte se, že máte na svém místě sady replik
V databázovém světě není ideální spoléhat se na jedinou databázi, protože může dojít ke katastrofě. Kromě toho byste očekávali nárůst počtu uživatelů databáze, a proto je třeba zajistit vysokou dostupnost dat. Replikace je zásadní přístup pro zajištění vysoké dostupnosti v případě převzetí služeb při selhání. MongoDB má schopnost poskytovat data geograficky:což znamená, že uživatelé z různých míst budou obsluhováni nejbližším cloudovým hostitelem, což je jeden ze způsobů, jak snížit latenci požadavků.
V případě, že primární uzel selže, sekundární uzly si mohou zvolit nový, aby udržely krok s operacemi zápisu, místo aby aplikace měla výpadek během převzetí služeb při selhání. Ve skutečnosti některé cloudové hostingové platformy, které jsou velmi ohleduplné k replikaci, nepodporují nereplikované MongoDB pro produkční prostředí.
Povolit ukládání do deníku
Jakkoli žurnálování implikuje určité snížení výkonu, je také důležité. Žurnálování vylepšuje operace zápisu dopředu, což znamená, že v případě, že databáze selže v procesu aktualizace, aktualizace by byla někde uložena a až znovu ožije, proces lze dokončit. Žurnálování může snadno usnadnit obnovu po havárii, proto by mělo být ve výchozím nastavení zapnuto.
Ujistěte se, že jste nastavili strategii zálohování
Mnoho podniků nedokáže po ztrátě dat pokračovat v činnosti kvůli chybějícím nebo špatným zálohovacím systémům. Před nasazením databáze do provozu se ujistěte, že jste použili některou z těchto strategií zálohování:
- Mongodump :optimální pro malá nasazení a při vytváření záloh filtrovaných podle konkrétních potřeb.
- Kopírování podkladu :optimální pro velká nasazení a efektivní přístup k pořizování úplných záloh a jejich obnově.
- Služba správy MongoDB (MMS) :poskytuje nepřetržité online zálohování pro MongoDB jako plně spravovanou službu. Optimální pro střepy clusteru a sady replik.
Záložní soubory by také neměly být uloženy u stejného poskytovatele hostitele databáze. Backup Ninja je služba, kterou lze k tomu použít.
Buďte připraveni na pomalé dotazy
Stěží lze realizovat pomalé dotazy ve vývojovém prostředí kvůli skutečnosti, že se jedná o málo dat. To však nemusí být případ výroby, vezmeme-li v úvahu, že budete mít mnoho uživatelů nebo půjde o hodně dat. Pokud se vám nepodařilo použít indexy nebo jste použili indexovací klíč, který není optimální, mohou se objevit pomalé dotazy. Přesto bychom měli najít způsob, který vám ukáže důvod pomalých dotazů.
Rozhodli jsme se proto povolit MongoDB Query Profiler. Jakkoli to může vést ke snížení výkonu, profiler pomůže odhalit problémy s výkonem. Před nasazením databáze musíte povolit profilovač pro kolekce, o kterých se domníváte, že by mohly mít pomalé dotazy, zejména ty, které zahrnují dokumenty s velkým množstvím vložení.
Připojte se k monitorovacímu nástroji
Kapacitní plánování je v MongoDB velmi zásadní. V každém okamžiku budete také potřebovat znát stav vaší db. Pro větší pohodlí vám připojení databáze k monitorovacímu nástroji ušetří čas při uvědomování si toho, co je třeba na databázi časem vylepšit. Například grafické znázornění, které ukazuje pomalý výkon CPU v důsledku zvýšených dotazů, vás nasměruje k přidání dalších hardwarových prostředků do vašeho systému.
Monitorovací nástroje mají také systém upozornění prostřednictvím e-mailu nebo krátkých zpráv, které vás pohodlně informují o některých problémech dříve, než přerostou v katastrofu. Proto se při výrobě ujistěte, že je vaše databáze připojena k monitorovacímu nástroji.
ClusterControl poskytuje bezplatné monitorování MongoDB v komunitní edici.
Implementujte bezpečnostní opatření
Zabezpečení databáze je další důležitou funkcí, kterou je třeba přísně brát v úvahu. Musíte chránit instalaci MongoDB v produkci tím, že zajistíte dodržování některých předprodukčních bezpečnostních kontrolních seznamů. Některé z úvah jsou:
- Konfigurace řízení přístupu na základě rolí
- Povolení řízení přístupu a vynucení ověřování
- Šifrování příchozích a odchozích připojení (TLS/SSL)
- Omezení vystavení sítě
- Šifrování a ochrana dat
- Mějte plán sledování přístupu a změn konfigurací databáze
Vyhněte se externím injekcím spuštěním MongoDB se zabezpečenými možnostmi konfigurace. Například deaktivace skriptování na straně serveru, pokud nepoužíváte operace na straně serveru JavaScript, jako je mapReduce a $where. Pomocí validátoru JSON pro data sbírek prostřednictvím některých modulů, jako je mongoose, zajistíte, že všechny uložené dokumenty budou v platném formátu BSON.
Hardwarové a softwarové aspekty
MongoDB má málo hardwarových předpokladů, protože je explicitně navržen s velkým ohledem na nezbytný komoditní hardware. Níže jsou uvedeny hlavní hardwarové úvahy pro MongoDB, které musíte zvážit před nasazením do produkce.
- Přiřaďte odpovídající RAM a CPU
- Použijte modul úložiště WiredTiger. Navrženo pro použití mezipaměti souborového systému a interní mezipaměti WiredTiger, čímž se zvyšuje výkon. Například při provozu se systémem 4 GB RAM využívá mezipaměť WiredTiger 1,5 GB RAM ( 0,5 * (4 GB -1 GB) =1,5 GB), zatímco systém s 1,2 GB mezipaměti WiredTiger využívá pouze 256 MB.
- Hardware NUMA. Existuje mnoho provozních problémů, které zahrnují pomalý výkon a vysoké využití systémových procesů, proto je třeba zvážit konfiguraci zásady prokládání paměti.
- Systém disku a úložiště:Použijte disky SSD (Solid State Disk):MongoDB vykazuje lepší poměr ceny a výkonu se SATA SSD
Závěr
Databáze ve výrobě jsou velmi důležité pro zajištění hladkého chodu podniku, a proto by se k nim mělo přistupovat s mnoha ohledy. Je třeba stanovit některé postupy, které mohou pomoci snížit chyby nebo spíše poskytnout snadný způsob, jak tyto chyby najít. Kromě toho je vhodné nastavit varovný systém, který bude ukazovat stav databáze s časem pro plánování kapacity a zjišťování problémů, než se zmírní v katastrofu.