Þeir segja að allt í lífinu sé þess virði að prófa að minnsta kosti einu sinni. Og ef þú ert vanur að vinna með venslaða DBMS, þá er það þess virði að kynnast NoSQL í reynd, fyrst af öllu, að minnsta kosti fyrir almenna þróun. Nú, vegna örrar þróunar þessarar tækni, eru margar andstæðar skoðanir og heitar umræður um þetta efni, sem sérstaklega ýtir undir áhugann.
Ef þú kafar ofan í kjarna allra þessara deilna geturðu séð að þær koma upp vegna rangrar nálgunar. Þeir sem nota NoSQL gagnagrunna nákvæmlega þar sem þeirra er þörf eru ánægðir og fá alla kosti þessarar lausnar. Og tilraunamenn sem treysta á þessa tækni sem töfralyf þar sem hún á alls ekki við eru fyrir vonbrigðum, eftir að hafa misst styrkleika tengslagagnagrunna án þess að öðlast verulegan ávinning.
Ég mun segja þér frá reynslu okkar af því að innleiða lausn byggða á Cassandra DBMS: hvað við þurftum að horfast í augu við, hvernig við komumst út úr erfiðum aðstæðum, hvort við gátum notið góðs af því að nota NoSQL og hvar við þurftum að fjárfesta frekari viðleitni/fjármuni .
Upphafsverkefnið er að byggja upp kerfi sem tekur upp símtöl í einhvers konar geymslu.
Starfsregla kerfisins er sem hér segir. Inntakið inniheldur skrár með ákveðna uppbyggingu sem lýsir uppbyggingu símtalsins. Forritið tryggir síðan að þessi uppbygging sé geymd í viðeigandi dálkum. Í framtíðinni eru vistuðu símtölin notuð til að birta upplýsingar um umferðarnotkun fyrir áskrifendur (gjöld, símtöl, jafnvægisferill).
Það er alveg ljóst hvers vegna þeir völdu Cassöndru - hún skrifar eins og vélbyssa, er auðvelt að skala og bilanaþolin.
Svo þetta er það sem reynslan gaf okkur
Já, misheppnaður hnútur er ekki harmleikur. Þetta er kjarninn í sektarþoli Cassöndru. En hnútur getur verið á lífi og á sama tíma byrjað að þjást af frammistöðu. Eins og það kom í ljós hefur þetta strax áhrif á frammistöðu alls klasans.
Cassandra mun ekki vernda þig þar sem Oracle bjargaði þér með takmörkunum sínum. Og ef höfundur umsóknarinnar skildi þetta ekki fyrirfram, þá er tvífarinn sem kom fyrir Cassöndru ekki verri en frumritið. Þegar það er komið munum við setja það inn.
IB líkaði mjög illa við ókeypis Cassöndru úr kassanum: Það er engin skráning á aðgerðum notenda, engin aðgreining á réttindum. Upplýsingar um símtöl teljast persónuupplýsingar, sem þýðir að allar tilraunir til að biðja um/breyta þeim á einhvern hátt verða að vera skráðar með möguleika á síðari endurskoðun. Einnig þarftu að vera meðvitaður um nauðsyn þess að aðgreina réttindi á mismunandi stigum fyrir mismunandi notendur. Einfaldur rekstrarverkfræðingur og ofurstjórnandi sem geta frjálslega eytt öllu lyklarýminu eru mismunandi hlutverk, mismunandi ábyrgð og hæfni. Án slíkrar aðgreiningar á aðgangsheimildum mun gildi og heiðarleiki gagnanna strax koma í efa hraðar en við NEITT samræmisstig.
Við tókum ekki tillit til þess að símtöl krefjast bæði alvarlegrar greiningar og reglubundinnar sýnatöku fyrir margvíslegar aðstæður. Þar sem valdar færslur eiga síðan að vera eytt og endurskrifaðar (sem hluti af verkefninu verðum við að styðja ferlið við að uppfæra gögn þegar gögnin fóru rangt inn í lykkjuna okkar í upphafi), er Cassandra ekki vinkona okkar hér. Cassandra er eins og sparigrís - það er þægilegt að setja hluti í, en þú getur ekki talið í það.
Við lentum í vandræðum við að flytja gögn yfir á prófunarsvæði (5 hnútar í prófinu á móti 20 í ballinu). Í þessu tilviki er ekki hægt að nota sorphauginn.
Vandamálið við að uppfæra gagnaskema forrits sem skrifar til Cassöndru. Við afturköllun myndast mjög margir legsteinar, sem getur leitt til framleiðnistaps á ófyrirsjáanlegan hátt.. Cassandra er fínstillt fyrir upptöku og hugsar ekki mikið áður en hún skrifar. Öll aðgerð með núverandi gögnum er líka upptaka. Það er að segja að með því að eyða óþarfa munum við einfaldlega framleiða enn fleiri plötur og aðeins sumar þeirra verða merktar með legsteinum.
Tímamörk við innsetningu. Cassandra er falleg í upptökunni, en stundum getur innstreymi hennar verulega ruglað hana. Þetta gerist þegar forritið byrjar að hjóla í kringum nokkrar færslur sem ekki er hægt að setja inn af einhverjum ástæðum. Og við munum þurfa alvöru DBA sem mun fylgjast með gc.log, kerfis- og villuleitarskrám fyrir hægar fyrirspurnir, mæligildi um þjöppun í bið.
Nokkur gagnaver í þyrpingu. Hvaðan á að lesa og hvar á að skrifa?
Kannski skipt í lestur og ritun? Og ef svo er, ætti þá að vera DC nær umsókninni um að skrifa eða lesa? Og munum við ekki enda með raunverulegan klofnan heila ef við veljum rangt samræmisstig? Það eru margar spurningar, margar óþekktar stillingar, möguleikar sem þú vilt virkilega fikta við.
Hvernig við ákváðum
Til að koma í veg fyrir að hnúturinn sökkvi var SWAP óvirkt. Og nú, ef það er skortur á minni, ætti hnúturinn að fara niður og ekki búa til stórar gc hlé.
Þannig að við treystum ekki lengur á rökfræði í gagnagrunninum. Forritahönnuðir eru að endurmennta sig og eru farnir að taka virkan varúðarráðstafanir í eigin kóða. Tilvalin skýr aðskilnaður gagnageymslu og vinnslu.
Við keyptum stuðning frá DataStax. Þróun Cassöndru í kassa er þegar hætt (síðasta skuldbindingin var í febrúar 2018). Jafnframt býður Datastax framúrskarandi þjónustu og fjölda breyttra og aðlagaðra lausna fyrir núverandi IP lausnir.
Ég vil líka taka fram að Cassandra er ekki mjög hentug fyrir valfyrirspurnir. Auðvitað er CQL stórt skref fram á við fyrir notendur (miðað við Trift). En ef þú ert með heilar deildir sem eru vanar svona þægilegum samskeytum, ókeypis síun eftir hvaða sviði sem er og fínstillingarmöguleika fyrir fyrirspurnir og þessar deildir vinna að því að leysa kvartanir og slys, þá virðist lausnin á Cassöndru fjandsamleg og heimskuleg fyrir þær. Og við byrjuðum að ákveða hvernig samstarfsmenn okkar ættu að gera sýnishorn.
Við skoðuðum tvo valkosti: Í fyrsta valmöguleikanum skrifum við símtöl ekki aðeins í C*, heldur einnig í geymda Oracle gagnagrunninn. Aðeins, ólíkt C*, geymir þessi gagnagrunnur aðeins símtöl fyrir yfirstandandi mánuð (nægileg geymsludýpt símtala fyrir endurhleðsluhylki). Hér sáum við strax eftirfarandi vandamál: ef við skrifum samstillt, þá missum við alla kosti C* sem tengjast hraðri innsetningu; ef við skrifum ósamstillt er engin trygging fyrir því að öll nauðsynleg símtöl hafi yfirhöfuð komist inn í Oracle. Það var einn plús, en stór: fyrir rekstur er sami kunnugi PL/SQL forritarinn eftir, þ.e.a.s. við innleiðum nánast „Facade“ mynstrið. Annar valkostur. Við innleiðum vélbúnað sem afhleður símtöl frá C*, dregur nokkur gögn til auðgunar úr samsvarandi töflum í Oracle, sameinar sýnin sem myndast og gefur okkur niðurstöðuna, sem við notum síðan einhvern veginn (rúlla til baka, endurtaka, greina, dást að). Gallar: ferlið er nokkuð fjölþrepa og að auki er ekkert viðmót fyrir rekstrarstarfsmenn.
Að lokum sættum við okkur við seinni kostinn. Apache Spark var notað til að taka sýni úr mismunandi krukkum. Kjarni vélbúnaðarins hefur verið minnkaður í Java kóða, sem, með því að nota tilgreinda lykla (áskrifandi, símtalstími - hlutalyklar), dregur út gögn úr C*, svo og nauðsynleg gögn til auðgunar úr öðrum gagnagrunni. Eftir það sameinar það þeim í minni sínu og sýnir niðurstöðuna í töflunni sem myndast. Við teiknuðum vefandlit yfir neistann og það reyndist nokkuð nothæft.
Þegar við leystum vandamálið við að uppfæra iðnaðarprófunargögn, skoðuðum við aftur nokkrar lausnir. Bæði flutningur í gegnum Sstloader og möguleikinn á að skipta þyrpingunni á prófunarsvæðinu í tvo hluta, sem hvor um sig tilheyrir sama þyrpingunni til skiptis og kynningarhópnum, þannig að hann er knúinn af honum. Þegar prófið var uppfært var áætlað að skipta þeim: sá hluti sem virkaði í prófinu er hreinsaður og settur í framleiðslu og hinn byrjar að vinna með gögnin sérstaklega. Hins vegar, eftir að hafa hugsað aftur, metum við skynsamlegra gögnin sem var þess virði að flytja og áttuðum okkur á því að símtölin sjálf eru ósamræmi fyrir próf, fljótt búin til ef þörf krefur, og það er kynningargagnasettið sem hefur ekkert gildi fyrir flutning til próf. Það eru nokkrir geymsluhlutir sem vert er að flytja, en þetta eru bókstaflega nokkur borð og ekki mjög þung. Því við sem lausn, Spark kom aftur til bjargar, með hjálp sem við skrifuðum og byrjuðum að virka að nota handrit til að flytja gögn á milli borða, prom-test.
Núverandi dreifingarstefna okkar gerir okkur kleift að vinna án afturköllunar. Áður en kynningin fer fram er lögboðin prufukeyrsla þar sem mistök eru ekki svo dýr. Ef um bilun er að ræða geturðu alltaf sleppt málrýminu og rúlla öllu kerfinu frá upphafi.
Til að tryggja stöðugt framboð á Cassöndru þarftu dba en ekki aðeins hann. Allir sem vinna með forritið verða að skilja hvar og hvernig á að horfa á núverandi aðstæður og hvernig á að greina vandamál tímanlega. Til að gera þetta notum við virkan DataStax OpsCenter (stjórnun og eftirlit með vinnuálagi), Cassandra Driver kerfismælingar (fjöldi tímafresta til að skrifa í C*, fjölda tímaloka fyrir lestur frá C*, hámarksleynd o.s.frv.), fylgjast með aðgerðinni af forritinu sjálfu, vinna með Cassöndru.
Þegar við hugsuðum um fyrri spurninguna áttuðum við okkur á því hvar helsta áhættan okkar gæti legið. Þetta eru gagnabirtingareyðublöð sem sýna gögn úr nokkrum sjálfstæðum fyrirspurnum í geymsluna. Þannig getum við fengið frekar ósamræmar upplýsingar. En þetta vandamál væri alveg eins viðeigandi ef við myndum vinna með aðeins eina gagnaver. Svo sanngjarnast hér er auðvitað að búa til lotuaðgerð til að lesa gögn á þriðja aðila forriti, sem tryggir að gögn berist á einu tímabili. Hvað varðar skiptinguna í lestur og ritun með tilliti til frammistöðu, þá var hætta á því að við gætum lent í tveimur þyrpingum sem eru algjörlega í ósamræmi hver við annan, með einhverju tapi á tengingu á milli DCs.
Þar af leiðandi, í bili hætt við samræmisstigið til að skrifa EACH_QUORUM, fyrir lestur - LOCAL_QUORUM
Stutt hughrif og ályktanir
Til þess að leggja mat á lausnina út frá rekstrarstuðningi og horfum til frekari þróunar ákváðum við að velta fyrir okkur hvar annars væri hægt að beita slíkri þróun.
Strax, síðan gagnaskor fyrir forrit eins og „Borgaðu þegar það hentar“ (við hleðum upplýsingum inn í C*, útreikningar með Spark forskriftum), reikningshaldi fyrir kröfur með söfnun eftir svæði, geymir hlutverk og reiknum út aðgangsrétt notenda út frá hlutverkinu fylki.
Eins og sjá má er efnisskráin fjölbreytt og fjölbreytt. Og ef við veljum herbúðir stuðningsmanna/andstæðinga NoSQL, þá munum við sameinast stuðningsmönnum, þar sem við fengum kosti okkar, og nákvæmlega þar sem við áttum von á.
Jafnvel Cassandra valmöguleikinn út úr kassanum gerir lárétta mælikvarða í rauntíma, sem leysir algerlega sársaukalaust vandamálið við að auka gögn í kerfinu. Okkur tókst að færa mjög mikið hleðslukerfi til að reikna út símtöl saman í sérstaka hringrás, og einnig aðskilja forritaskema og rökfræði, og losa okkur við þá slæmu vinnu við að skrifa sérsniðin verk og hluti í gagnagrunninn sjálfan. Við fengum tækifæri til að velja og stilla, til að flýta fyrir, hvaða DCs við munum framkvæma útreikninga á og hvaða við munum skrá gögn á, við tryggðum okkur fyrir hrun bæði einstakra hnúta og DC í heild.
Með því að beita arkitektúrnum okkar á ný verkefni, og hafa nú þegar nokkra reynslu, vil ég strax taka tillit til blæbrigða sem lýst er hér að ofan og forðast að gera mistök, slétta út nokkur skörp horn sem ekki var hægt að forðast í fyrsta lagi.
Til dæmis, fylgstu með uppfærslum Cassöndru tímanlegavegna þess að allmörg vandamálin sem við fengum voru þegar þekkt og lagfærð.
Ekki setja bæði gagnagrunninn sjálfan og Spark á sömu hnúta (eða deila stranglega með magni leyfilegrar auðlindanotkunar), þar sem Spark getur borðað meira OP en búist var við, og við munum fljótt fá vandamál númer 1 af listanum okkar.
Bæta eftirlit og rekstrarhæfni á prófunarstigi verkefnisins. Í upphafi skaltu taka eins mikið tillit og mögulegt er til allra hugsanlegra neytenda lausnarinnar okkar, vegna þess að þetta er það sem gagnagrunnsuppbyggingin mun að lokum ráðast á.
Snúðu hringrásinni sem myndast nokkrum sinnum fyrir mögulega hagræðingu. Veldu hvaða reiti má raðgreina. Skilja hvaða viðbótartöflur við ættum að gera til að taka sem réttast og sem best tillit til og gefa síðan nauðsynlegar upplýsingar sé þess óskað (t.d. með því að gera ráð fyrir að við getum geymt sömu gögnin í mismunandi töflum, að teknu tilliti til mismunandi sundurliðana skv. mismunandi forsendur, við getum sparað verulega CPU tíma fyrir lestrarbeiðnir).
Meðaltal Gerðu strax ráð fyrir að hengja TTL og hreinsa úrelt gögn.
Þegar þú halar niður gögnum frá Cassandra Forritsrökfræðin ætti að virka á FETCH meginreglunni, þannig að ekki eru allar línur hlaðnar inn í minnið í einu, heldur eru þær valdar í lotum.
Það er ráðlegt áður en verkefnið er flutt yfir í þá lausn sem lýst er athugaðu bilanaþol kerfisins með því að framkvæma röð árekstrarprófa, svo sem tap á gögnum í einni gagnaver, endurheimt skemmdra gagna á tilteknu tímabili, brottfall nets milli gagnavera. Slíkar prófanir munu ekki aðeins gera manni kleift að meta kosti og galla fyrirhugaðs arkitektúrs, heldur munu þeir einnig veita verkfræðingum sem framkvæma þær góða upphitunaræfingu og sú kunnátta sem áunnin er verður langt frá því að vera óþörf ef kerfisbilanir eru endurgerðar í framleiðslu.
Ef við vinnum með mikilvægar upplýsingar (eins og gögn fyrir innheimtu, útreikning á skuldum áskrifenda), þá er líka þess virði að borga eftirtekt til verkfæra sem draga úr áhættu sem stafar af eiginleikum DBMS. Notaðu til dæmis nodesync tólið (Datastax), eftir að hafa þróað ákjósanlega stefnu til notkunar þess í röð vegna samkvæmni, ekki búa til of mikið álag á Cassöndru og nota það aðeins fyrir ákveðin borð á ákveðnu tímabili.
Hvað verður um Cassöndru eftir sex mánaða líf? Almennt séð eru engin óleyst vandamál. Við leyfðum heldur engin alvarleg slys eða tap á gögnum. Já, við þurftum að hugsa um að bæta upp nokkur vandamál sem ekki höfðu komið upp áður, en á endanum skýli þetta ekki mjög arkitektúrlausn okkar. Ef þú vilt og ert óhræddur við að prófa eitthvað nýtt, og vilt á sama tíma ekki verða fyrir of vonbrigðum, þá vertu tilbúinn fyrir þá staðreynd að ekkert er ókeypis. Þú verður að skilja, kafa ofan í skjölin og setja saman þína eigin einstaka hrífu meira en í gömlu eldri lausninni og engin kenning segir þér fyrirfram hvaða hrífa bíður þín.
Heimild: www.habr.com