Hulle sê dat alles in die lewe die moeite werd is om ten minste een keer te probeer. En as jy gewoond is om met relasionele DBBS'e te werk, is dit die moeite werd om kennis te maak met NoSQL in die praktyk, eerstens, ten minste vir algemene ontwikkeling. Nou, as gevolg van die vinnige ontwikkeling van hierdie tegnologie, is daar baie teenstrydige menings en hewige debatte oor hierdie onderwerp, wat veral belangstelling aanwakker.
As jy in die essensie van al hierdie dispute delf, kan jy sien dat dit ontstaan as gevolg van die verkeerde benadering. Diegene wat NoSQL-databasisse gebruik presies waar dit nodig is, is tevrede en ontvang al die voordele van hierdie oplossing. En eksperimenteerders wat op hierdie tegnologie staatmaak as 'n wondermiddel waar dit glad nie van toepassing is nie, is teleurgesteld, omdat hulle die sterk punte van relasionele databasisse verloor het sonder om noemenswaardige voordele te behaal.
Ek sal jou vertel van ons ervaring met die implementering van 'n oplossing gebaseer op die Cassandra DBMS: wat ons moes trotseer, hoe ons uit moeilike situasies gekom het, of ons voordeel kon trek uit die gebruik van NoSQL en waar ons bykomende pogings/fondse moes belê .
Die aanvanklike taak is om 'n stelsel te bou wat oproepe in 'n soort berging opneem.
Die werkingsbeginsel van die stelsel is soos volg. Die invoer sluit lêers in met 'n spesifieke struktuur wat die struktuur van die oproep beskryf. Die toepassing verseker dan dat hierdie struktuur in die toepaslike kolomme gestoor word. In die toekoms word die gestoorde oproepe gebruik om inligting oor verkeersverbruik vir intekenare te vertoon (koste, oproepe, balansgeskiedenis).
Dit is baie duidelik hoekom hulle Cassandra gekies het - sy skryf soos 'n masjiengeweer, is maklik skaalbaar en foutverdraagsaam.
So, dit is wat ervaring ons gegee het
Ja, 'n mislukte nodus is nie 'n tragedie nie. Dit is die kern van Cassandra se skuldverdraagsaamheid. Maar 'n nodus kan lewendig wees en terselfdertyd begin ly in prestasie. Soos dit geblyk het, beïnvloed dit onmiddellik die prestasie van die hele groepering.
Cassandra sal jou nie beskerm waar Oracle jou met sy beperkings gered het nie. En as die skrywer van die aansoek dit nie vooraf verstaan het nie, dan is die dubbel wat vir Cassandra opgedaag het nie erger as die oorspronklike nie. Sodra dit aangekom het, sal ons dit insit.
IB het baie nie van die gratis Cassandra uit die boks gehou nie: Daar is geen aanteken van gebruikershandelinge nie, geen differensiasie van regte nie. Inligting oor oproepe word as persoonlike data beskou, wat beteken dat alle pogings om dit op enige manier te versoek/verander, aangeteken moet word met die moontlikheid van daaropvolgende ouditering. U moet ook bewus wees van die behoefte om regte op verskillende vlakke vir verskillende gebruikers te skei. 'n Eenvoudige operasionele ingenieur en 'n superadministrateur wat die hele sleutelruimte vrylik kan uitvee, is verskillende rolle, verskillende verantwoordelikhede en bevoegdhede. Sonder so 'n differensiasie van toegangsregte, sal die waarde en integriteit van die data onmiddellik vinniger ter sprake kom as met die ENIGE konsekwentheidsvlak.
Ons het nie in ag geneem dat oproepe beide ernstige ontledings en periodieke steekproefneming vir 'n verskeidenheid toestande vereis nie. Aangesien die geselekteerde rekords dan veronderstel is om uitgevee en herskryf te word (as deel van die taak moet ons die proses van opdatering van data ondersteun wanneer die data aanvanklik verkeerd in ons lus ingekom het), is Cassandra nie ons vriend hier nie. Cassandra is soos 'n spaarvarkie - dit is gerieflik om dinge in te sit, maar jy kan nie daarin tel nie.
Ons het 'n probleem ondervind om data na toetssones oor te dra (5 nodusse in die toets teenoor 20 in die prom). In hierdie geval kan die stortingsterrein nie gebruik word nie.
Die probleem met die opdatering van die dataskema van 'n toepassing wat aan Cassandra skryf. 'n Terugrol sal 'n groot aantal grafstene genereer, wat op onvoorspelbare maniere tot produktiwiteitsverliese kan lei.. Cassandra is geoptimaliseer vir opname, en dink nie veel voor skryf nie. Enige bewerking met bestaande data daarin is ook 'n opname. Dit wil sê, deur die onnodige uit te vee, sal ons eenvoudig nog meer rekords produseer, en slegs sommige van hulle sal met grafstene gemerk word.
Time-outs tydens invoeging. Cassandra is pragtig in die opname, maar soms kan die inkomende vloei haar aansienlik verwar. Dit gebeur wanneer die toepassing om verskeie rekords begin draai wat om een of ander rede nie ingevoeg kan word nie. En ons sal 'n regte DBA nodig hê wat gc.log, stelsel en debug logs sal monitor vir stadige navrae, metrieke oor verdigting hangende.
Verskeie datasentrums in 'n groepering. Waar om te lees en waar om te skryf?
Miskien verdeel in lees en skryf? En indien wel, moet daar 'n DC nader aan die aansoek vir skryf of lees wees? En sal ons nie met 'n regte gesplete brein eindig as ons die verkeerde konsekwentheidsvlak kies nie? Daar is baie vrae, baie onbekende instellings, moontlikhede waarmee jy regtig wil peuter.
Hoe ons besluit het
Om te verhoed dat die nodus sink, is SWAP gedeaktiveer. En nou, as daar 'n gebrek aan geheue is, moet die nodus afgaan en nie groot gc-pouses skep nie.
So, ons maak nie meer staat op logika in die databasis nie. Toepassingsontwikkelaars heroplei hulself en begin aktief voorsorgmaatreëls tref in hul eie kode. Ideale duidelike skeiding van databerging en verwerking.
Ons het ondersteuning by DataStax gekoop. Die ontwikkeling van die boks Cassandra het reeds gestaak (die laaste commit was in Februarie 2018). Terselfdertyd bied Datastax uitstekende diens en 'n groot aantal gewysigde en aangepaste oplossings vir bestaande IP-oplossings.
Ek wil ook daarop let dat Cassandra nie baie gerieflik is vir seleksie-navrae nie. Natuurlik is CQL 'n groot stap vorentoe vir gebruikers (in vergelyking met Trift). Maar as jy hele departemente het wat gewoond is aan sulke gerieflike aansluitings, gratis filtering deur enige veld- en navraagoptimeringsvermoëns, en hierdie departemente werk daaraan om klagtes en ongelukke op te los, dan lyk die oplossing op Cassandra vir hulle vyandig en dom. En ons het begin besluit hoe ons kollegas monsters moet maak.
Ons het twee opsies oorweeg: In die eerste opsie skryf ons oproepe nie net in C* nie, maar ook in die geargiveerde Oracle-databasis. Slegs, anders as C*, stoor hierdie databasis oproepe slegs vir die huidige maand (voldoende oproepbergingsdiepte vir herlaai gevalle). Hier het ons dadelik die volgende probleem gesien: as ons sinchronies skryf, verloor ons al die voordele van C* wat met vinnige invoeging geassosieer word; as ons asinchroon skryf, is daar geen waarborg dat al die nodige oproepe hoegenaamd by Oracle ingekom het nie. Daar was een pluspunt, maar 'n groot een: vir die operasie bly dieselfde bekende PL/SQL-ontwikkelaar oor, dit wil sê ons implementeer prakties die "Facade"-patroon. 'n Alternatiewe opsie. Ons implementeer 'n meganisme wat oproepe van C* aflaai, sommige data vir verryking uit die ooreenstemmende tabelle in Oracle haal, by die resulterende monsters aansluit en vir ons die resultaat gee, wat ons dan op een of ander manier gebruik (terugrol, herhaal, ontleed, bewonder). Nadele: die proses is redelik multi-stap, en daarbenewens is daar geen koppelvlak vir operasionele werknemers nie.
Uiteindelik het ons op die tweede opsie besluit. Apache Spark is gebruik om uit verskillende flesse te monster. Die kern van die meganisme is gereduseer tot Java-kode, wat, met behulp van die gespesifiseerde sleutels (intekenaar, tyd van oproep - afdeling sleutels), data uit C* haal, sowel as die nodige data vir verryking uit enige ander databasis. Daarna voeg dit by hulle in sy geheue en vertoon die resultaat in die resulterende tabel. Ons het 'n web gesig oor die vonk getrek en dit het redelik bruikbaar geword.
Toe ons die probleem van die opdatering van industriële toetsdata opgelos het, het ons weer verskeie oplossings oorweeg. Beide oordrag via Sstloader en die opsie om die groep in die toetssone in twee dele te verdeel, wat elkeen afwisselend aan dieselfde groep as die promosie-een behoort, en dus daardeur aangedryf word. By die opdatering van die toets, was daar beplan om hulle om te ruil: die deel wat in die toets gewerk het, word skoongemaak en in produksie aangegaan, en die ander begin afsonderlik met die data werk. Nadat ons weer gedink het, het ons egter meer rasioneel die data beoordeel wat die moeite werd was om oor te dra, en besef dat die oproepe self 'n inkonsekwente entiteit is vir toetse, vinnig gegenereer indien nodig, en dit is die promosiedatastel wat geen waarde het vir oordrag na die toets. Daar is verskeie stoorvoorwerpe wat die moeite werd is om te skuif, maar dit is letterlik 'n paar tafels, en nie baie swaar nie. Daarom ons as 'n oplossing het Spark weer tot die redding gekom, met die hulp waarvan ons geskryf het en aktief 'n skrip begin gebruik het vir die oordrag van data tussen tabelle, prom-toets.
Ons huidige ontplooiingsbeleid stel ons in staat om te werk sonder terugdraai. Voor die promosie is daar 'n verpligte toetslopie, waar 'n fout nie so duur is nie. In die geval van mislukking, kan jy altyd die saakruimte laat val en die hele skema van die begin af rol.
Om deurlopende beskikbaarheid van Cassandra te verseker, benodig jy 'n dba en nie net hy nie. Almal wat met die toepassing werk, moet verstaan waar en hoe om na die huidige situasie te kyk en hoe om probleme betyds te diagnoseer. Om dit te doen, gebruik ons aktief DataStax OpsCenter (Administrasie en monitering van werkladings), Cassandra Driver-stelselstatistieke (aantal uitteltyd vir skryf na C*, aantal uitteltyd vir lees vanaf C*, maksimum latensie, ens.), monitor die werking van die toepassing self, saam met Cassandra.
Toe ons aan die vorige vraag gedink het, het ons besef waar ons grootste risiko kan lê. Dit is datavertoonvorms wat data van verskeie onafhanklike navrae na die berging vertoon. Op hierdie manier kan ons nogal inkonsekwente inligting kry. Maar hierdie probleem sou net so relevant wees as ons met net een datasentrum werk. So die mees redelike ding hier is natuurlik om 'n bondelfunksie te skep vir die lees van data op 'n derdeparty-toepassing, wat sal verseker dat data in 'n enkele tydperk ontvang word. Wat die verdeling in lees en skryf in terme van prestasie betref, hier is ons gestop deur die risiko dat ons met 'n mate van verbindingsverlies tussen die DK'e kan eindig met twee groepe wat heeltemal inkonsekwent met mekaar is.
As gevolg hiervan, vir nou gestop by die konsekwentheidsvlak vir die skryf van EACH_QUORUM, vir lees - LOCAL_QUORUM
Kort indrukke en gevolgtrekkings
Om die gevolglike oplossing te evalueer vanuit die oogpunt van operasionele ondersteuning en vooruitsigte vir verdere ontwikkeling, het ons besluit om te dink oor waar anders so 'n ontwikkeling toegepas kan word.
Reg van die kolf, dan data-telling vir programme soos "Betaal wanneer dit gerieflik is" (ons laai inligting in C*, berekening deur gebruik te maak van Spark-skrifte), verantwoording van eise met samevoeging volgens area, stoor rolle en bereken gebruikerstoegangsregte gebaseer op die rol matriks.
Soos u kan sien, is die repertorium wyd en gevarieerd. En as ons die kamp van ondersteuners/teenstanders van NoSQL kies, dan sal ons by die ondersteuners aansluit, aangesien ons ons voordele ontvang het, en presies waar ons verwag het.
Selfs die Cassandra-opsie buite die boks laat horisontale skaal in reële tyd toe, wat die probleem van toenemende data in die stelsel absoluut pynloos oplos. Ons was in staat om 'n baie hoë-lading meganisme vir die berekening van oproep aggregate in 'n aparte stroombaan te skuif, en ook die toepassing skema en logika skei, ontslae te raak van die slegte praktyk van die skryf van persoonlike take en voorwerpe in die databasis self. Ons het die geleentheid gekry om te kies en op te stel, om te bespoedig, watter GS'e ons berekeninge sal uitvoer en op watter ons data sal opneem, ons het onsself verseker teen ineenstortings van beide individuele nodusse en die GS as 'n geheel.
Deur ons argitektuur op nuwe projekte toe te pas, en reeds 'n bietjie ervaring het, wil ek dadelik die nuanses wat hierbo beskryf word in ag neem, en 'n paar foute voorkom, 'n paar skerp hoeke glad maak wat aanvanklik nie vermy kon word nie.
Byvoorbeeld, hou betyds tred met Cassandra se opdateringswant heelwat van die probleme wat ons gekry het, was reeds bekend en reggemaak.
Moenie beide die databasis self en Spark op dieselfde nodusse plaas nie (of deel streng deur die hoeveelheid toelaatbare hulpbrongebruik), aangesien Spark meer OP kan eet as wat verwag is, en ons sal vinnig probleem nommer 1 uit ons lys kry.
Verbeter monitering en operasionele bevoegdheid tydens die projektoetsstadium. Neem aanvanklik soveel as moontlik alle potensiële verbruikers van ons oplossing in ag, want dit is waarvan die databasisstruktuur uiteindelik sal afhang.
Draai die resulterende stroombaan verskeie kere vir moontlike optimalisering. Kies watter velde geserialiseer kan word. Verstaan watter bykomende tabelle ons moet maak om die mees korrek en optimaal in ag te neem, en verskaf dan die vereiste inligting op versoek (byvoorbeeld deur te aanvaar dat ons dieselfde data in verskillende tabelle kan stoor, met inagneming van verskillende uiteensettings ooreenkomstig verskillende kriteria, kan ons aansienlik SVE tyd bespaar vir leesversoeke).
Gemiddeld Maak onmiddellik voorsiening vir die aanheg van TTL en die skoonmaak van verouderde data.
Wanneer u data van Cassandra aflaai Die toepassingslogika behoort op die FETCH-beginsel te werk, sodat nie alle rye gelyktydig in die geheue gelaai word nie, maar in bondels geselekteer word.
Dit is raadsaam voordat die projek na die beskryfde oplossing oorgedra word kontroleer die stelsel se fouttoleransie deur 'n reeks botstoetse uit te voer, soos dataverlies in een datasentrum, herstel van beskadigde data oor 'n sekere tydperk, netwerkuitval tussen datasentrums. Sulke toetse sal 'n mens nie net toelaat om die voor- en nadele van die voorgestelde argitektuur te evalueer nie, maar sal ook goeie opwarmoefening verskaf vir die ingenieurs wat dit uitvoer, en die verworwe vaardigheid sal ver van oorbodig wees as stelselfoute in produksie gereproduseer word.
As ons met kritieke inligting werk (soos data vir fakturering, berekening van intekenaarskuld), dan is dit ook die moeite werd om aandag te gee aan gereedskap wat die risiko's wat ontstaan as gevolg van die kenmerke van die DBBS sal verminder. Gebruik byvoorbeeld die nodesync-nutsding (Datastax), nadat u 'n optimale strategie ontwikkel het vir die gebruik daarvan in volgorde ter wille van konsekwentheid, moenie 'n oormatige las op Cassandra skep nie en gebruik dit slegs vir sekere tabelle in 'n sekere tydperk.
Wat gebeur met Cassandra na ses maande van die lewe? Oor die algemeen is daar geen onopgeloste probleme nie. Ons het ook geen ernstige ongelukke of dataverlies toegelaat nie. Ja, ons moes daaraan dink om te vergoed vir sommige probleme wat nie voorheen ontstaan het nie, maar dit het uiteindelik nie ons argitektoniese oplossing baie vertroebel nie. As jy wil en nie bang is om iets nuuts te probeer nie, en terselfdertyd nie te teleurgesteld wil wees nie, maak dan gereed vir die feit dat niks gratis is nie. Jy sal moet verstaan, in die dokumentasie delf en jou eie individuele hark meer moet saamstel as in die ou erfenisoplossing, en geen teorie sal jou vooraf vertel watter hark vir jou wag nie.
Bron: will.com