Říká se, že všechno v životě stojí za to alespoň jednou vyzkoušet. A pokud jste zvyklí pracovat s relačními DBMS, pak se vyplatí seznámit se s NoSQL v praxi především alespoň pro obecný vývoj. Nyní, vzhledem k rychlému rozvoji této technologie, existuje na toto téma mnoho protichůdných názorů a bouřlivých diskusí, což zvláště podněcuje zájem.
Pokud se ponoříte do podstaty všech těchto sporů, můžete vidět, že vznikají kvůli špatnému přístupu. Ti, kteří používají NoSQL databáze přesně tam, kde jsou potřeba, jsou spokojeni a získávají všechny výhody tohoto řešení. A experimentátoři, kteří spoléhají na tuto technologii jako na všelék tam, kde není vůbec použitelná, jsou zklamáni, protože ztratili silné stránky relačních databází, aniž by získali významné výhody.
Řeknu vám o našich zkušenostech s implementací řešení založeného na Cassandra DBMS: čemu jsme museli čelit, jak jsme se dostali z obtížných situací, zda jsme byli schopni těžit z používání NoSQL a kam jsme museli investovat další úsilí/finance .
Počátečním úkolem je vybudovat systém, který zaznamenává hovory do nějakého úložiště.
Princip fungování systému je následující. Vstup obsahuje soubory se specifickou strukturou, která popisuje strukturu volání. Aplikace pak zajistí uložení této struktury do příslušných sloupců. Uložené hovory se v budoucnu používají k zobrazení informací o spotřebě provozu pro účastníky (poplatky, hovory, historie zůstatků).
Je celkem jasné, proč si vybrali Cassandru – píše jako kulomet, je snadno škálovatelná a odolná proti chybám.
Tak tohle nám dala zkušenost
Ano, neúspěšný uzel není tragédie. To je podstata Cassandriny tolerance chyb. Ale uzel může být naživu a zároveň začít trpět ve výkonu. Jak se ukázalo, okamžitě to ovlivňuje výkon celého clusteru.
Cassandra vás neochrání tam, kde vás Oracle svými omezeními zachránil. A pokud to autor aplikace předem nepochopil, tak dvojka, která pro Cassandru dorazila, není o nic horší než originál. Jakmile dorazí, vložíme ho.
IB se velmi nelíbila svobodná Cassandra po vybalení z krabice: Neexistuje žádné protokolování akcí uživatele, žádné rozlišení práv. Informace o hovorech jsou považovány za osobní údaje, což znamená, že veškeré pokusy o jejich vyžádání/změnu jakýmkoliv způsobem musí být logovány s možností následného auditu. Také si musíte být vědomi potřeby oddělit práva na různých úrovních pro různé uživatele. Jednoduchý provozní inženýr a superadmin, který může libovolně smazat celý klíčový prostor, jsou různé role, různé odpovědnosti a kompetence. Bez takového rozlišení přístupových práv bude hodnota a integrita dat okamžitě zpochybněna rychleji než u JAKÉKOLI úrovně konzistence.
Nebrali jsme v úvahu, že hovory vyžadují jak seriózní analýzu, tak pravidelné vzorkování pro různé podmínky. Vzhledem k tomu, že vybrané záznamy mají být následně smazány a přepsány (v rámci úkolu musíme podporovat proces aktualizace dat, když data zpočátku chybně vstoupila do naší smyčky), není zde Cassandra naším přítelem. Cassandra je jako prasátko - je pohodlné vkládat věci, ale nemůžete do toho počítat.
Narazili jsme na problém s přenosem dat do testovacích zón (5 uzlů v testu versus 20 na maturitní ples). V tomto případě nelze výpis použít.
Problém s aktualizací datového schématu aplikace zapisující Cassandře. Vrácení změn vytvoří velké množství náhrobků, což může vést ke ztrátám produktivity nepředvídatelným způsobem.. Cassandra je optimalizována pro nahrávání a před zápisem moc nepřemýšlí. Jakákoli operace s existujícími daty v ní je také nahrávkou. Čili tím, že smažeme nepotřebné, prostě vyrobíme ještě více záznamů a jen některé budou označeny náhrobky.
Časové limity při vkládání. Cassandra je na nahrávce krásná, ale někdy ji může příchozí proud značně zmást. K tomu dochází, když aplikace začne procházet několik záznamů, které z nějakého důvodu nelze vložit. A budeme potřebovat skutečného DBA, který bude monitorovat gc.log, systémové a ladicí protokoly pro pomalé dotazy, metriky o komprimaci čekající na vyřízení.
Několik datových center v clusteru. Odkud číst a kam psát?
Možná rozdělit na čtení a psaní? A pokud ano, měl by být k aplikaci blíže DC pro psaní nebo čtení? A neskončíme se skutečným rozděleným mozkem, když zvolíme špatnou úroveň konzistence? Je tu spousta otázek, spousta neznámých nastavení, možností, se kterými si opravdu chcete pohrát.
Jak jsme se rozhodli
Aby se zabránilo potopení uzlu, bylo zakázáno SWAP. A nyní, pokud je nedostatek paměti, uzel by měl jít dolů a nevytvářet velké gc pauzy.
Takže se již nespoléháme na logiku v databázi. Vývojáři aplikací se přeškolují a začínají aktivně přijímat opatření ve svém vlastním kódu. Ideální jasné oddělení ukládání a zpracování dat.
Zakoupili jsme podporu od DataStax. Vývoj boxované Cassandry již ustal (poslední commit byl v únoru 2018). Datastax zároveň nabízí vynikající služby a velké množství upravených a přizpůsobených řešení pro stávající IP řešení.
Také chci poznamenat, že Cassandra není příliš vhodná pro výběrové dotazy. CQL je samozřejmě pro uživatele velký krok kupředu (ve srovnání s Triftem). Ale pokud máte celá oddělení, která jsou zvyklá na taková pohodlná spojení, bezplatné filtrování podle libovolného pole a možnosti optimalizace dotazů, a tato oddělení pracují na řešení stížností a nehod, pak se jim řešení na Cassandře zdá nepřátelské a hloupé. A začali jsme řešit, jak by naši kolegové měli vzorky vyrobit.
Zvažovali jsme dvě možnosti: V první možnosti zapisujeme volání nejen v C*, ale i do archivované databáze Oracle. Pouze na rozdíl od C* tato databáze ukládá hovory pouze pro aktuální měsíc (dostatečná hloubka úložiště hovorů pro případy dobíjení). Zde jsme okamžitě viděli následující problém: pokud píšeme synchronně, pak ztrácíme všechny výhody C* spojené s rychlým vkládáním, pokud píšeme asynchronně, není zaručeno, že se všechna potřebná volání do Oracle vůbec dostala. Bylo tu jedno plus, ale velké: pro ovládání zůstává stejný známý PL/SQL Developer, tedy prakticky implementujeme vzor „Fasáda“. Alternativní možnost. Implementujeme mechanismus, který uvolní volání z C*, vytáhne některá data pro obohacení z odpovídajících tabulek v Oracle, spojí výsledné vzorky a dá nám výsledek, který pak nějak použijeme (vrátit zpět, opakovat, analyzovat, obdivovat). Nevýhody: proces je poměrně vícekrokový a navíc chybí rozhraní pro provozní zaměstnance.
Nakonec jsme se rozhodli pro druhou možnost. Apache Spark byl použit k odběru vzorků z různých nádob. Podstata mechanismu se zredukovala na Java kód, který pomocí zadaných klíčů (subscriber, time of call - section keys) vytáhne data z C* a také potřebná data pro obohacení z jakékoliv jiné databáze. Poté je spojí ve své paměti a výsledek zobrazí ve výsledné tabulce. Nakreslili jsme webovou tvář přes jiskru a ukázalo se to docela použitelné.
Při řešení problému aktualizace dat průmyslových testů jsme opět zvažovali několik řešení. Jak přenos přes Sstloader, tak možnost rozdělení clusteru v testovací zóně na dvě části, z nichž každá střídavě patří ke stejnému clusteru s tou propagační, tudíž je jím poháněn. Při aktualizaci testu bylo plánováno jejich prohození: část, která fungovala v testu, se vyčistí a zadá do výroby a druhá začne pracovat s daty samostatně. Po opětovném přemýšlení jsme však racionálněji vyhodnotili data, která stála za přenos, a uvědomili jsme si, že samotné hovory jsou nekonzistentní entita pro testy, v případě potřeby rychle generované, a je to propagační datový soubor, který nemá žádnou hodnotu pro přenos do test. Existuje několik úložných objektů, které stojí za to přesunout, ale jedná se doslova o pár stolů a ne příliš těžkých. Proto my jako řešení přišel opět na pomoc Spark, s jehož pomocí jsme napsali a začali aktivně používat skript pro přenos dat mezi tabulkami, prom-test.
Naše aktuální zásady nasazení nám umožňují pracovat bez vrácení zpět. Před promo akcí je povinný testovací provoz, kde chyba není tak drahá. V případě neúspěchu můžete vždy zahodit casespace a přetočit celé schéma od začátku.
Abyste zajistili nepřetržitou dostupnost Cassandry, potřebujete dba a nejen jeho. Každý, kdo s aplikací pracuje, musí rozumět tomu, kde a jak se na aktuální situaci dívat a jak včas diagnostikovat problémy. K tomu aktivně využíváme DataStax OpsCenter (Administrace a sledování zátěže), systémové metriky Cassandra Driver (počet timeoutů pro zápis do C*, počet timeoutů pro čtení z C*, maximální latence atd.), monitorujeme provoz samotné aplikace ve spolupráci s Cassandrou.
Když jsme se zamysleli nad předchozí otázkou, uvědomili jsme si, kde může spočívat naše hlavní riziko. Jedná se o formuláře pro zobrazení dat, které zobrazují data z několika nezávislých dotazů do úložiště. Můžeme tak získat značně rozporuplné informace. Ale tento problém by byl stejně relevantní, kdybychom pracovali pouze s jedním datovým centrem. Nejrozumnější je zde tedy samozřejmě vytvořit dávkovou funkci pro čtení dat na aplikaci třetí strany, která zajistí příjem dat v jediném časovém úseku. Co se týče rozdělení na čtení a zápis z hlediska výkonu, zde nás zarazilo riziko, že při určité ztrátě spojení mezi DC bychom mohli skončit se dvěma clustery, které jsou mezi sebou naprosto nekonzistentní.
V důsledku toho prozatím zastaveno na úrovni konzistence pro zápis EACH_QUORUM, pro čtení - LOCAL_QUORUM
Krátké dojmy a závěry
Abychom výsledné řešení zhodnotili z pohledu provozní podpory a perspektiv dalšího rozvoje, rozhodli jsme se zamyslet nad tím, kde jinde by se dal takový vývoj uplatnit.
Hned od začátku, poté hodnocení dat pro programy jako „Plaťte, když se to hodí“ (informace načítáme do C*, výpočet pomocí skriptů Spark), účtování nároků s agregací podle oblasti, ukládání rolí a výpočet přístupových práv uživatelů na základě role matice.
Jak je vidět, repertoár je široký a pestrý. A pokud si vybereme tábor příznivců/odpůrců NoSQL, tak se k příznivcům přidáme, jelikož jsme své výhody dostali a přesně tam, kde jsme očekávali.
Dokonce i možnost Cassandra po vybalení umožňuje horizontální škálování v reálném čase, což naprosto bezbolestně řeší problém navyšování dat v systému. Podařilo se nám přesunout velmi zatěžovaný mechanismus pro výpočet agregací volání do samostatného okruhu a také oddělit aplikační schéma a logiku, čímž jsme se zbavili špatné praxe psaní vlastních úloh a objektů v samotné databázi. Dostali jsme možnost vybrat a nakonfigurovat, urychlit, na kterých DC budeme provádět výpočty a na které budeme zaznamenávat data, pojistili jsme se proti pádům jak jednotlivých uzlů, tak DC jako celku.
Při aplikaci naší architektury na nové projekty a již s určitými zkušenostmi bych chtěl okamžitě vzít v úvahu výše popsané nuance a předejít některým chybám, vyhladit některé ostré rohy, kterým se zpočátku nedalo vyhnout.
Například, sledujte včas aktualizace Cassandryprotože docela dost problémů, které jsme měli, už bylo známo a opraveno.
Neumisťujte jak samotnou databázi, tak Spark na stejné uzly (nebo striktně vydělte množstvím povoleného využití zdrojů), protože Spark může sníst více OP, než se očekávalo, a my rychle získáme problém číslo 1 z našeho seznamu.
Zlepšit monitorování a provozní způsobilost ve fázi testování projektu. Zpočátku berte co nejvíce v úvahu všechny potenciální spotřebitele našeho řešení, protože na tom bude nakonec záviset struktura databáze.
Pro případnou optimalizaci výsledný obvod několikrát otočte. Vyberte, která pole lze serializovat. Porozumět tomu, jaké dodatečné tabulky bychom měli vytvořit, abychom co nejsprávněji a nejoptimálněji zohlednili, a poté poskytnout požadované informace na požádání (například za předpokladu, že můžeme stejná data uložit do různých tabulek s přihlédnutím k různým členěním podle různá kritéria, můžeme výrazně ušetřit CPU čas pro požadavky na čtení).
Není to špatné Okamžitě zajistěte připojení TTL a čištění zastaralých dat.
Při stahování dat z Cassandry Aplikační logika by měla fungovat na principu FETCH, aby se všechny řádky nenačítaly do paměti najednou, ale byly vybírány dávkově.
Je vhodné před převedením projektu do popsaného řešení zkontrolujte odolnost systému proti chybám provedením série nárazových testů, jako je ztráta dat v jednom datovém centru, obnova poškozených dat po určitou dobu, výpadek sítě mezi datovými centry. Takové testy nejenže umožní vyhodnotit klady a zápory navrhované architektury, ale také poskytnou dobrou zahřívací praxi pro inženýry, kteří je provádějí, a získaná dovednost nebude ani zdaleka zbytečná, pokud se selhání systému reprodukují ve výrobě.
Pokud pracujeme s kritickými informacemi (jako jsou data pro fakturaci, výpočet dluhu předplatitele), pak se také vyplatí věnovat pozornost nástrojům, které sníží rizika vyplývající z funkcí DBMS. Použijte například obslužný program nodesync (Datastax), který má v pořádku vyvinutou optimální strategii pro jeho použití kvůli důslednosti nevytvářejte nadměrnou zátěž Cassandře a použít jej pouze pro určité tabulky v určitém období.
Co se stane s Cassandrou po šesti měsících života? Obecně neexistují žádné nevyřešené problémy. Nedopustili jsme ani žádné vážné nehody nebo ztrátu dat. Ano, museli jsme myslet na kompenzaci některých problémů, které se dříve nevyskytly, ale nakonec to naše architektonické řešení příliš nezatemnilo. Pokud chcete a nebojíte se vyzkoušet něco nového a zároveň nechcete být příliš zklamaní, pak se připravte na to, že nic není zadarmo. Budete muset rozumět, ponořit se do dokumentace a sestavit si vlastní individuální hrábě více než ve starém legacy řešení a žádná teorie vám předem neřekne, který hrábě na vás čeká.
Zdroj: www.habr.com