Hovorí sa, že všetko v živote sa oplatí aspoň raz vyskúšať. A ak ste zvyknutí pracovať s relačnými DBMS, potom sa oplatí zoznámiť sa s NoSQL v praxi, v prvom rade aspoň pre všeobecný vývoj. Teraz, kvôli rýchlemu rozvoju tejto technológie, existuje veľa protichodných názorov a búrlivých debát na túto tému, čo obzvlášť podnecuje záujem.
Ak sa ponoríte do podstaty všetkých týchto sporov, môžete vidieť, že vznikajú v dôsledku nesprávneho prístupu. Tí, ktorí používajú NoSQL databázy presne tam, kde sú potrebné, sú spokojní a získavajú všetky výhody tohto riešenia. A experimentátori, ktorí sa spoliehajú na túto technológiu ako na všeliek tam, kde nie je vôbec použiteľná, sú sklamaní, pretože stratili silné stránky relačných databáz bez toho, aby získali významné výhody.
Poviem vám o našich skúsenostiach s implementáciou riešenia založeného na Cassandra DBMS: čomu sme museli čeliť, ako sme sa dostali z ťažkých situácií, či sme dokázali využiť NoSQL a kam sme museli investovať ďalšie úsilie/financie .
Prvotnou úlohou je vybudovať systém, ktorý zaznamenáva hovory do nejakého úložiska.
Princíp fungovania systému je nasledovný. Vstup obsahuje súbory so špecifickou štruktúrou, ktorá popisuje štruktúru hovoru. Aplikácia potom zabezpečí uloženie tejto štruktúry do príslušných stĺpcov. Uložené hovory sa v budúcnosti používajú na zobrazovanie informácií o spotrebe prevádzky pre účastníkov (poplatky, hovory, história zostatkov).
Je celkom jasné, prečo si vybrali Cassandru - píše ako guľomet, je ľahko škálovateľná a odolná voči chybám.
Takže toto nám dala skúsenosť
Áno, neúspešný uzol nie je tragédia. Toto je podstata Cassandrinej tolerancie chýb. ale uzol môže byť nažive a zároveň začať trpieť výkonom. Ako sa ukázalo, okamžite to ovplyvňuje výkon celého klastra.
Cassandra vás neochráni tam, kde vás Oracle zachránil svojimi obmedzeniami. A ak to autor aplikácie vopred nepochopil, tak dvojka, ktorá dorazila pre Cassandru, nie je o nič horšia ako originál. Keď to príde, vložíme to.
IB sa veľmi nepáčila voľná Cassandra po vybalení z krabice: Neexistuje žiadne protokolovanie akcií používateľa, žiadne rozlišovanie práv. Informácie o hovoroch sú považované za osobné údaje, čo znamená, že všetky pokusy o ich vyžiadanie/zmenu akýmkoľvek spôsobom musia byť zaprotokolované s možnosťou následného auditu. Tiež si musíte uvedomiť potrebu oddeliť práva na rôznych úrovniach pre rôznych používateľov. Jednoduchý prevádzkový inžinier a supersprávca, ktorý môže voľne vymazať celý kľúčový priestor, sú rôzne úlohy, rôzne zodpovednosti a kompetencie. Bez takejto diferenciácie prístupových práv bude hodnota a integrita údajov okamžite spochybňovaná rýchlejšie ako pri AKEJKOĽVEK úrovni konzistencie.
Nebrali sme do úvahy, že hovory si vyžadujú serióznu analýzu a pravidelné vzorkovanie pre rôzne podmienky. Keďže vybrané záznamy sa potom majú vymazať a prepísať (v rámci úlohy musíme podporovať proces aktualizácie údajov, keď sa údaje pôvodne dostali do našej slučky nesprávne), Cassandra tu nie je naša priateľka. Cassandra je ako prasiatko - je pohodlné vkladať veci, ale nemôžete do toho počítať.
Pri prenose údajov do testovacích zón sa vyskytol problém (5 uzlov v teste oproti 20 na plese). V tomto prípade nie je možné použiť výpis.
Problém s aktualizáciou dátovej schémy aplikácie zapisovajúcej do Cassandry. Vrátenie zmien vytvorí veľké množstvo náhrobných kameňov, čo môže viesť k strate produktivity nepredvídateľným spôsobom.. Cassandra je optimalizovaná na nahrávanie a pred zápisom veľa nepremýšľa. Akákoľvek operácia s existujúcimi údajmi v nej je tiež nahrávaním. Čiže vymazaním nepotrebných jednoducho vyrobíme ešte viac záznamov a len niektoré budú označené náhrobnými kameňmi.
Časové limity pri vkladaní. Cassandra je na nahrávke krásna, ale niekedy ju prichádzajúci tok môže výrazne zmiasť. Stáva sa to vtedy, keď aplikácia začne cyklovať okolo niekoľkých záznamov, ktoré sa z nejakého dôvodu nedajú vložiť. A budeme potrebovať skutočného DBA, ktorý bude monitorovať gc.log, systémové a ladiace protokoly pre pomalé dopyty, metriky o komprimácii čakajúce.
Niekoľko dátových centier v klastri. Odkiaľ čítať a kam písať?
Možno rozdeliť na čítanie a písanie? A ak áno, malo by byť bližšie k aplikácii DC na písanie alebo čítanie? A neskončíme so skutočným rozdeleným mozgom, ak zvolíme nesprávnu úroveň konzistencie? Existuje veľa otázok, veľa neznámych nastavení, možností, s ktorými sa naozaj chcete pohrať.
Ako sme sa rozhodli
Aby sa zabránilo potopeniu uzla, SWAP bol zakázaný. A teraz, ak je nedostatok pamäte, uzol by mal ísť dole a nevytvárať veľké gc pauzy.
Takže sa už nespoliehame na logiku v databáze. Vývojári aplikácií sa preškoľujú a začínajú aktívne prijímať preventívne opatrenia vo svojom vlastnom kóde. Ideálne jasné oddelenie ukladania a spracovania dát.
Zakúpili sme podporu od DataStax. Vývoj boxovanej Cassandry sa už zastavil (posledný commit bol vo februári 2018). Zároveň Datastax ponúka vynikajúce služby a veľké množstvo upravených a prispôsobených riešení pre existujúce IP riešenia.
Chcem tiež poznamenať, že Cassandra nie je príliš vhodná na výberové otázky. Samozrejme, CQL je pre používateľov (v porovnaní s Trift) veľkým krokom vpred. Ale ak máte celé oddelenia, ktoré sú zvyknuté na takéto pohodlné spojenia, bezplatné filtrovanie podľa ľubovoľného poľa a možnosti optimalizácie dotazov a tieto oddelenia pracujú na riešení sťažností a nehôd, riešenie na Cassandre sa im zdá nepriateľské a hlúpe. A začali sme riešiť, ako by mali naši kolegovia vyrobiť vzorky.
Zvažovali sme dve možnosti V prvej možnosti zapisujeme volania nielen v C*, ale aj do archivovanej databázy Oracle. Len na rozdiel od C* táto databáza ukladá hovory len za aktuálny mesiac (dostatočná hĺbka uloženia hovorov pre prípady dobíjania). Tu sme okamžite videli nasledujúci problém: ak píšeme synchrónne, strácame všetky výhody C* spojené s rýchlym vkladaním, ak píšeme asynchrónne, nie je zaručené, že sa všetky potrebné volania do Oracle vôbec dostali. Bolo tu jedno plus, ale veľké: pre prevádzku zostáva rovnaký známy PL/SQL Developer, t.j. prakticky implementujeme vzor „Fasáda“. Alternatívna možnosť. Implementujeme mechanizmus, ktorý uvoľní volania z C*, vytiahne nejaké dáta na obohatenie z príslušných tabuliek v Oracle, spojí výsledné vzorky a dá nám výsledok, ktorý potom nejako použijeme (vrátime späť, opakujeme, analyzujeme, obdivujeme). Nevýhody: proces je pomerne viackrokový a navyše neexistuje rozhranie pre zamestnancov prevádzky.
Nakoniec sme sa rozhodli pre druhú možnosť. Apache Spark sa použil na odber vzoriek z rôznych nádob. Podstata mechanizmu sa zredukovala na Java kód, ktorý pomocou zadaných kľúčov (subscriber, time of call - section keys) vytiahne dáta z C*, ako aj potrebné dáta na obohatenie z akejkoľvek inej databázy. Potom ich spojí vo svojej pamäti a výsledok zobrazí vo výslednej tabuľke. Nakreslili sme webovú tvár cez iskru a ukázalo sa, že je celkom použiteľná.
Pri riešení problému aktualizácie údajov priemyselných testov sme opäť zvažovali niekoľko riešení. Ako prenos cez Sstloader, tak aj možnosť rozdelenia klastra v testovacej zóne na dve časti, z ktorých každá patrí striedavo do toho istého klastra s propagačným, teda je ním poháňaný. Pri aktualizácii testu sa plánovalo ich zámena: časť, ktorá fungovala v teste, sa vymaže a zadá do výroby a druhá začne pracovať s údajmi samostatne. Po opätovnom premýšľaní sme však racionálnejšie zhodnotili údaje, ktoré sa oplatili preniesť, a uvedomili sme si, že samotné hovory sú nekonzistentnou entitou na testy, ktoré sa v prípade potreby rýchlo vygenerujú, a práve propagačný súbor údajov nemá žiadnu hodnotu na prenos do test. Existuje niekoľko úložných predmetov, ktoré sa oplatí premiestniť, no ide doslova o pár stolíkov, a nie veľmi ťažkých. Preto my ako riešenie opäť prišiel na pomoc Spark, s pomocou ktorého sme napísali a začali aktívne používať skript na prenos údajov medzi tabuľkami, prom-test.
Naša súčasná politika nasadenia nám umožňuje pracovať bez zmien. Pred promom je povinná testovacia prevádzka, kde chyba nie je taká drahá. V prípade neúspechu môžete vždy zahodiť casespace a zrolovať celú schému od začiatku.
Na zabezpečenie nepretržitej dostupnosti Cassandry potrebujete dba a nielen jeho. Každý, kto s aplikáciou pracuje, musí pochopiť, kde a ako sa pozerať na aktuálnu situáciu a ako včas diagnostikovať problémy. K tomu aktívne využívame DataStax OpsCenter (Administrácia a sledovanie záťaže), systémové metriky Cassandra Driver (počet časových limitov pre zápis do C*, počet časových limitov pre čítanie z C*, maximálna latencia atď.), monitorujeme prevádzku samotnej aplikácie v spolupráci s Cassandrou.
Keď sme sa zamysleli nad predchádzajúcou otázkou, uvedomili sme si, kde môže spočívať naše hlavné riziko. Ide o formuláre na zobrazenie údajov, ktoré zobrazujú údaje z niekoľkých nezávislých dopytov do úložiska. Takto môžeme získať dosť rozporuplné informácie. Ale tento problém by bol rovnako dôležitý, keby sme pracovali len s jedným dátovým centrom. Najrozumnejšie je tu teda, samozrejme, vytvoriť dávkovú funkciu na čítanie údajov v aplikácii tretej strany, ktorá zabezpečí príjem údajov v jedinom časovom úseku. Čo sa týka rozdelenia na čítanie a zápis z hľadiska výkonu, tu nás zastavilo riziko, že pri určitej strate spojenia medzi DC by sme mohli skončiť s dvomi klastrami, ktoré sú navzájom úplne nekonzistentné.
V dôsledku toho zatiaľ zastavené na úrovni konzistencie pre zápis EACH_QUORUM, pre čítanie - LOCAL_QUORUM
Krátke dojmy a závery
Aby sme výsledné riešenie zhodnotili z pohľadu prevádzkovej podpory a perspektívy ďalšieho rozvoja, rozhodli sme sa zamyslieť nad tým, kde inde by sa dal takýto vývoj uplatniť.
Hneď na začiatku potom vyhodnocovanie údajov pre programy ako „Plaťte, keď je to vhodné“ (informácie načítavame do C*, výpočet pomocou skriptov Spark), účtovanie nárokov s agregáciou podľa oblasti, ukladanie rolí a výpočet prístupových práv používateľov na základe roly matice.
Ako vidíte, repertoár je široký a pestrý. A ak si vyberieme tábor priaznivcov/odporcov NoSQL, tak sa k priaznivcom pripojíme, keďže sme dostali svoje výhody a presne tam, kde sme očakávali.
Dokonca aj možnosť Cassandra po vybalení umožňuje horizontálne škálovanie v reálnom čase, čo úplne bezbolestne rieši problém zvyšovania údajov v systéme. Podarilo sa nám presunúť veľmi zaťažený mechanizmus na výpočet agregovaných hovorov do samostatného okruhu a tiež oddeliť aplikačnú schému a logiku, čím sme sa zbavili zlých praktík zapisovania vlastných úloh a objektov do samotnej databázy. Dostali sme možnosť vybrať si a nakonfigurovať, urýchliť, na ktorých DC budeme vykonávať výpočty a na ktoré budeme zaznamenávať dáta, poistili sme sa proti pádom ako jednotlivých uzlov, tak aj DC ako celku.
Aplikovaním našej architektúry na nové projekty a už s určitými skúsenosťami by som chcel okamžite vziať do úvahy vyššie opísané nuansy a zabrániť niektorým chybám, vyhladiť niektoré ostré rohy, ktorým sa spočiatku nedalo vyhnúť.
Napríklad, sledovať aktualizácie Cassandry včaspretože veľa problémov, ktoré sme mali, už bolo známych a opravených.
Neumiestňujte samotnú databázu aj Spark na rovnaké uzly (alebo striktne vydeľte množstvom povoleného využitia zdrojov), keďže Spark môže zjesť viac OP, ako sa očakávalo, a rýchlo dostaneme problém číslo 1 z nášho zoznamu.
Zlepšiť monitorovanie a prevádzkovú spôsobilosť vo fáze testovania projektu. Na začiatok berte čo najviac do úvahy všetkých potenciálnych spotrebiteľov nášho riešenia, pretože od toho bude v konečnom dôsledku závisieť štruktúra databázy.
Pre možnú optimalizáciu výsledný obvod niekoľkokrát otočte. Vyberte polia, ktoré možno serializovať. Pochopte, aké dodatočné tabuľky by sme mali vytvoriť, aby sme čo najsprávnejšie a najoptimálnejšie zohľadnili, a potom na požiadanie poskytnite požadované informácie (napríklad za predpokladu, že rovnaké údaje môžeme uložiť do rôznych tabuliek, pričom zohľadníme rôzne členenia podľa rôzne kritériá, môžeme výrazne ušetriť CPU čas pre požiadavky na čítanie).
Nie je to zlé Okamžite zabezpečte pripojenie TTL a vyčistenie zastaraných údajov.
Pri sťahovaní údajov z Cassandry Aplikačná logika by mala fungovať na princípe FETCH, teda nie všetky riadky sa načítavajú do pamäte naraz, ale vyberajú sa v dávkach.
Odporúča sa pred prenesením projektu do opísaného riešenia skontrolujte odolnosť systému proti chybám vykonaním série nárazových testov, ako je strata dát v jednom dátovom centre, obnova poškodených dát za určité obdobie, výpadok siete medzi dátovými centrami. Takéto testy nielenže umožnia zhodnotiť klady a zápory navrhovanej architektúry, ale poskytnú aj dobrú nácvik zahrievania pre inžinierov, ktorí ich vykonávajú, a získaná zručnosť nebude ani zďaleka zbytočná, ak sa zlyhania systému budú reprodukovať vo výrobe.
Ak pracujeme s kritickými informáciami (ako sú údaje pre fakturáciu, výpočet dlhu predplatiteľa), potom sa oplatí venovať pozornosť aj nástrojom, ktoré znížia riziká vyplývajúce z funkcií DBMS. Napríklad použite pomôcku nodesync (Datastax), ktorá má v poriadku vyvinutú optimálnu stratégiu na jej použitie kvôli konzistencii nevytvárajte nadmerné zaťaženie Cassandry a použiť ho len pre určité tabuľky v určitom období.
Čo sa stane s Cassandrou po šiestich mesiacoch života? Vo všeobecnosti neexistujú žiadne nevyriešené problémy. Nedopustili sme ani žiadne vážne nehody či stratu dát. Áno, museli sme myslieť na kompenzáciu niektorých problémov, ktoré sa predtým nevyskytli, ale nakoniec to veľmi nezahmlievalo naše architektonické riešenie. Ak chcete a nebojíte sa vyskúšať niečo nové a zároveň nechcete byť príliš sklamaní, tak sa pripravte na to, že nič nie je zadarmo. Budete musieť rozumieť, vŕtať sa v dokumentácii a zostavovať si svoj vlastný individuálny hrable viac ako v starom legacy riešení a žiadna teória vám dopredu nepovie, ktorý hrable na vás čaká.
Zdroj: hab.com