Benchmarking MongoDB – řízení výkonu NoSQL

Databázové systémy jsou klíčovými součástmi v cyklu každé úspěšné běžící aplikace. Každá organizace, která je zapojí, má proto mandát zajistit hladký výkon těchto DBM prostřednictvím důsledného monitorování a řešení drobných neúspěchů, než přerostou v obrovské komplikace, které mohou vést k výpadku aplikace nebo pomalému výkonu.

Můžete se zeptat, jak můžete zjistit, zda databáze skutečně bude mít problém, když funguje normálně? No, to je to, o čem budeme diskutovat v tomto článku a nazýváme to benchmarking. Benchmarking je v podstatě spouštění určité sady dotazů s určitými testovacími daty spolu s určitým poskytováním zdrojů, aby se zjistilo, zda tyto parametry splňují očekávanou úroveň výkonu.

MongoDB nemá standardní metodiku benchmarkingu, takže musíme vyřešit testovací dotazy na vlastním hardwaru. Jakkoli můžete získat působivá čísla z procesu benchmarku, musíte být opatrní, protože to může být jiný případ, když provozujete databázi se skutečnými dotazy.

Smyslem benchmarkingu je získat obecnou představu o tom, jak různé možnosti konfigurace ovlivňují výkon, jak můžete některé z těchto konfigurací vyladit, abyste dosáhli maximálního výkonu a odhadnout náklady na vylepšení této implementace. Kromě toho, aplikace rostou s časem, pokud jde o uživatele a pravděpodobně množství dat, která mají být obsluhována, a proto je třeba před touto dobou provést určité plánování kapacity. Poté, co si uvědomíte rostoucí trend dat, musíte provést nějaké srovnání, jak splníte požadavky těchto obrovských rostoucích dat.

Úvahy o srovnávání MongoDB

1. Vyberte úlohy, které jsou typickou reprezentací dnešních moderních aplikací. Moderní aplikace jsou každým dnem složitější a to se přenáší až do datových struktur. To znamená, že prezentace dat se také časem změnila, například ukládání jednoduchých polí do objektů a polí. Není úplně snadné pracovat s těmito daty s výchozí nebo spíše nestandardní databázovou konfigurací, protože to může eskalovat k problémům, jako je špatná latence a špatná propustnost operací zahrnujících složitá data. Při spouštění benchmarku byste proto měli používat data, která jsou jasnou prezentací vaší aplikace.
2. Dvojí kontrola zápisů. Vždy se ujistěte, že všechny zápisy dat byly provedeny způsobem, který neumožňuje ztrátu dat. Cílem je zlepšit integritu dat zajištěním konzistentnosti dat a jejich použití zejména v produkčním prostředí.
3. Využijte objemy dat, které představují datové sady „velkých dat“, které jistě překročí kapacitu paměti RAM pro jednotlivý uzel. Když je testovací zátěž velká, pomůže vám to předpovědět budoucí očekávání výkonu vaší databáze, a proto začněte s plánováním kapacity dostatečně brzy.

Metodika

Náš srovnávací test bude zahrnovat některá velká data o poloze, která lze stáhnout odtud, a k manipulaci s našimi daty a shromažďování informací, které potřebujeme, budeme používat software Robo3t. Soubor má více než 500 dokumentů, což je pro náš test docela dost. Používáme MongoDB verze 4.0 na dedikovaném serveru Ubuntu Linux 12.04 Intel Xeon-SandyBridge E3-1270-Quadcore 3,4 GHz s 32 GB RAM, 1TB rotujícím diskem Western Digital WD Caviar RE4 a 256GB SSD Smart XceedIOPS. Vložili jsme prvních 500 dokumentů.

Spustili jsme níže uvedené příkazy vložení

db.getCollection('location').insertMany([<document1, <document2>…<document500>],{w:0})
db.getCollection('location').insertMany([<document1, <document2>…<document500>],{w:1})

Napište obavy

Zájem o zápis popisuje úroveň potvrzení požadovaná od MongoDB pro operace zápisu v tomto případě do samostatné MongoDB. Pro operace s vysokou propustností, pokud je tato hodnota nastavena na nízkou, budou volání zápisu tak rychlá, čímž se sníží latence požadavku. Na druhou stranu, pokud je hodnota nastavena vysoko, pak jsou volání zápisu pomalá a následně se zvyšuje latence dotazu. Jednoduchým vysvětlením je, že když je hodnota nízká, nemusíte se obávat možnosti ztráty některých zápisů v případě zhroucení mongodu, chyby sítě nebo selhání anonymního systému. Omezení v tomto případě bude, nebudete si jisti, zda byly tyto zápisy úspěšné. Na druhou stranu, pokud je problém se zápisem velký, objeví se výzva k ošetření chyb a zápisy budou tedy potvrzeny. Potvrzení je jednoduše potvrzení, že server akceptoval zápis ke zpracování.

V našem testu problém se zápisem nastavený na nízkou vedl k tomu, že dotaz byl proveden v min. 0,013 ms a max. 0,017 ms. V tomto případě je základní potvrzení zápisu zakázáno, ale stále můžete získat informace o výjimkách soketu a jakékoli síťové chybě, která mohla být spuštěna.

Když je problém se zápisem nastaven vysoko, návrat trvá téměř dvojnásobek času s dobou provádění 0,027 ms min a 0,031 ms max. Potvrzení je v tomto případě zaručeno, ale není 100% dosaženo diskového deníku. V tomto případě je tedy šance na ztrátu zápisu 50% kvůli oknu 100 ms, kdy žurnál nemusí být vyprázdněn na disk.

Ukládání deníků

Jedná se o techniku, která zajišťuje, že nedochází ke ztrátě dat tím, že poskytuje odolnost v případě selhání. Toho je dosaženo prostřednictvím protokolování s předběžným zápisem do souborů žurnálu na disku. Je to nejúčinnější, když je starost o zápis nastavena vysoko.

U rotujícího disku je doba provádění s povoleným žurnálováním trochu vysoká, například v našem testu to bylo asi 0,251 ms pro stejnou operaci výše.

Doba provádění pro SSD je však o něco kratší pro stejný příkaz. V našem testu to bylo asi 0,207 ms, ale v závislosti na povaze dat to někdy mohlo být 3krát rychlejší než rotující disk.

Když je žurnálování povoleno, potvrzuje, že byly provedeny zápisy do žurnálu, a tím zajišťuje trvanlivost dat. V důsledku toho operace zápisu přežije vypnutí mongodu a zajistí, že operace zápisu bude trvalá.

Pro operace s vysokou propustností můžete nastavit poloviční časy dotazování nastavením w=0. V opačném případě, pokud potřebujete mít jistotu, že data byla zaznamenána nebo spíše budou v případě obnovení po selhání, musíte nastavit w=1.

Replikace

Potvrzení problému se zápisem lze povolit pro více než jeden uzel, který je primárním a některým sekundárním v sadě replik. To bude charakterizováno tím, jaké celé číslo má hodnotu parametru write. Pokud například w =3, musí Mongod zajistit, aby dotaz obdržel potvrzení od hlavního uzlu a 2 podřízených. Pokud se pokusíte nastavit hodnotu větší než jedna a uzel ještě není replikován, vyvolá to chybu, že hostitel musí být replikován.

Replikace přichází se zpožděním latence, takže doba provádění se prodlouží. Pro výše uvedený jednoduchý dotaz, pokud w=3, se průměrná doba provádění zvýší na 270 ms. Hnacím faktorem je rozsah doby odezvy mezi uzly ovlivněnými latencí sítě, režií komunikace mezi třemi uzly a přetížením. Kromě toho všechny tři uzly čekají na dokončení, než vrátí výsledek. V produkčním nasazení proto nebudete muset zapojit tolik uzlů, pokud chcete zlepšit výkon. MongoDB je zodpovědný za výběr, které uzly mají být potvrzeny, pokud v konfiguračním souboru není specifikace pomocí značek.

Otáčející se disk versus pevný disk

Jak bylo uvedeno výše, SSD disk je poměrně rychlý než rotující disk v závislosti na použitých datech. Někdy by to mohlo být 3krát rychlejší, a proto stojí za to za něj v případě potřeby zaplatit. Použití SSD však bude dražší, zejména při práci s rozsáhlými daty. MongoDB má zásluhu na tom, že podporuje ukládání databází do adresářů, které lze připojit, a tedy možnost používat SSD. Použití SSD a povolení žurnálování je skvělá optimalizace.

Závěr

Experiment byl jistý, že zakázaný zápis má za následek zkrácení doby provádění dotazu na úkor možnosti ztráty dat. Na druhou stranu, když je povolena obava o zápis, doba provádění je téměř dvojnásobná, když je zakázána, ale existuje záruka, že nedojde ke ztrátě dat. Kromě toho jsme schopni ospravedlnit, že SSD je rychlejší než Spinning disk. Chcete-li však zajistit trvanlivost dat v případě selhání systému, je vhodné povolit problém se zápisem. Když povolujete problém se zápisem pro sadu replik, nenastavujte číslo příliš velké, takže by to mohlo mít za následek snížení výkonu na konci aplikace.