De siger, at alt i livet er værd at prøve mindst én gang. Og hvis du er vant til at arbejde med relationelle DBMS'er, så er det værd at stifte bekendtskab med NoSQL i praksis, først og fremmest, i hvert fald til generel udvikling. Nu, på grund af den hurtige udvikling af denne teknologi, er der mange modstridende meninger og ophedede debatter om dette emne, hvilket især vækker interesse.
Hvis du dykker ned i essensen af alle disse tvister, kan du se, at de opstår på grund af den forkerte tilgang. De, der bruger NoSQL-databaser præcis, hvor der er brug for dem, er tilfredse og får alle fordelene ved denne løsning. Og forsøgspersoner, der stoler på denne teknologi som et vidundermiddel, hvor den slet ikke er anvendelig, er skuffede, da de har mistet styrkerne ved relationelle databaser uden at opnå væsentlige fordele.
Jeg vil fortælle dig om vores erfaring med at implementere en løsning baseret på Cassandra DBMS: hvad vi skulle stå over for, hvordan vi kom ud af vanskelige situationer, om vi var i stand til at drage fordel af at bruge NoSQL, og hvor vi skulle investere yderligere kræfter/midler .
Den første opgave er at bygge et system, der optager opkald i en form for lager.
Funktionsprincippet for systemet er som følger. Inputtet inkluderer filer med en specifik struktur, der beskriver opkaldets struktur. Applikationen sikrer derefter, at denne struktur er gemt i de relevante kolonner. Fremover bruges de gemte opkald til at vise information om trafikforbrug for abonnenter (takster, opkald, saldohistorik).
Det er helt klart, hvorfor de valgte Cassandra - hun skriver som et maskingevær, er let skalerbar og fejltolerant.
Så det er, hvad oplevelsen gav os
Ja, en mislykket knude er ikke en tragedie. Dette er essensen af Cassandras fejltolerance. Men en node kan være i live og samtidig begynde at lide i ydeevnen. Som det viste sig, påvirker dette øjeblikkeligt hele klyngens ydeevne.
Cassandra vil ikke beskytte dig, hvor Oracle reddede dig med sine begrænsninger. Og hvis forfatteren af ansøgningen ikke forstod dette på forhånd, så er den dobbelte, der ankom til Cassandra, ikke værre end originalen. Når den er ankommet, lægger vi den ind.
IB kunne stærkt ikke lide den gratis Cassandra ud af æsken: Der er ingen logning af brugerhandlinger, ingen differentiering af rettigheder. Oplysninger om opkald betragtes som persondata, hvilket betyder, at alle forsøg på at anmode om/ændre dem på nogen måde skal logges med mulighed for efterfølgende revision. Du skal også være opmærksom på behovet for at adskille rettigheder på forskellige niveauer for forskellige brugere. En simpel driftsingeniør og en superadministrator, der frit kan slette hele nøglerummet, er forskellige roller, forskellige ansvarsområder og kompetencer. Uden en sådan differentiering af adgangsrettigheder vil værdien og integriteten af dataene straks komme i tvivl hurtigere end med NOGET konsistensniveau.
Vi tog ikke højde for, at opkald kræver både seriøs analyse og periodisk prøveudtagning for en række forskellige tilstande. Da de valgte poster så formodes at blive slettet og omskrevet (som en del af opgaven skal vi understøtte processen med at opdatere data, når dataene oprindeligt kom forkert ind i vores loop), er Cassandra ikke vores ven her. Cassandra er som en sparegris - det er praktisk at lægge ting i, men du kan ikke regne med det.
Vi stødte på et problem med at overføre data til testzoner (5 noder i testen mod 20 i bal). I dette tilfælde kan lossepladsen ikke bruges.
Problemet med at opdatere dataskemaet for en applikation, der skriver til Cassandra. En rollback vil generere rigtig mange gravsten, som kan føre til produktivitetstab på uforudsigelige måder.. Cassandra er optimeret til optagelse, og tænker sig ikke så meget om, før man skriver.Enhver operation med eksisterende data i er også en optagelse. Det vil sige, at vi ved at slette det unødvendige simpelthen producerer endnu flere plader, og kun nogle af dem bliver markeret med gravsten.
Timeouts ved indsættelse. Cassandra er smuk i optagelsen, men nogle gange kan den indkommende strøm forvirre hende betydeligt. Dette sker, når applikationen begynder at cykle rundt om flere poster, der af en eller anden grund ikke kan indsættes. Og vi får brug for en rigtig DBA, der vil overvåge gc.log, system og debug logs for langsomme forespørgsler, målinger om komprimering afventer.
Flere datacentre i en klynge. Hvor skal man læse fra og hvor skal man skrive?
Måske opdeles i læsning og skrivning? Og skal der i så fald være en DC tættere på ansøgningen om at skrive eller læse? Og vil vi ikke ende med en rigtig splittet hjerne, hvis vi vælger det forkerte konsistensniveau? Der er en masse spørgsmål, en masse ukendte indstillinger, muligheder, som du virkelig gerne vil pille ved.
Hvordan vi besluttede
For at forhindre noden i at synke, blev SWAP deaktiveret. Og nu, hvis der mangler hukommelse, skal noden gå ned og ikke skabe store gc-pauser.
Så vi er ikke længere afhængige af logik i databasen. Applikationsudviklere omskoler sig selv og begynder aktivt at tage forholdsregler i deres egen kode. Ideel klar adskillelse af datalagring og -behandling.
Vi købte support fra DataStax. Udviklingen af boxed Cassandra er allerede ophørt (den sidste commit var i februar 2018). Samtidig tilbyder Datastax fremragende service og en lang række modificerede og tilpassede løsninger til eksisterende IP-løsninger.
Jeg vil også bemærke, at Cassandra ikke er særlig praktisk til valgforespørgsler. Selvfølgelig er CQL et stort skridt fremad for brugerne (sammenlignet med Trift). Men hvis du har hele afdelinger, der er vant til sådanne bekvemme joinforbindelser, gratis filtrering efter ethvert felt og forespørgselsoptimeringsmuligheder, og disse afdelinger arbejder på at løse klager og ulykker, så virker løsningen på Cassandra fjendtlig og dum over for dem. Og vi begyndte at beslutte, hvordan vores kolleger skulle lave prøver.
Vi overvejede to muligheder: I den første mulighed skriver vi ikke kun opkald i C*, men også i den arkiverede Oracle-database. Kun, i modsætning til C*, gemmer denne database kun opkald for den aktuelle måned (tilstrækkelig opkaldslagringsdybde til genopladningssager). Her så vi straks følgende problem: hvis vi skriver synkront, så mister vi alle fordelene ved C* forbundet med hurtig indsættelse; hvis vi skriver asynkront, er der ingen garanti for, at alle de nødvendige opkald overhovedet kom ind i Oracle. Der var et plus, men et stort: til drift forbliver den samme velkendte PL/SQL-udvikler, dvs. vi implementerer praktisk talt "Facade"-mønsteret. En alternativ mulighed. Vi implementerer en mekanisme, der aflæser opkald fra C*, trækker nogle data til berigelse fra de tilsvarende tabeller i Oracle, forbinder de resulterende prøver og giver os resultatet, som vi derefter på en eller anden måde bruger (rulle tilbage, gentage, analysere, beundre). Ulemper: processen er ret multi-trin, og derudover er der ingen grænseflade for driftsmedarbejdere.
Til sidst besluttede vi os for den anden mulighed. Apache Spark blev brugt til at prøve fra forskellige krukker. Essensen af mekanismen er blevet reduceret til Java-kode, som ved hjælp af de angivne nøgler (abonnent, opkaldstidspunkt - sektionsnøgler) trækker data ud fra C*, såvel som de nødvendige data til berigelse fra enhver anden database. Hvorefter den samler dem i sin hukommelse og viser resultatet i den resulterende tabel. Vi tegnede et web-ansigt over gnisten, og det viste sig ganske brugbart.
Da vi løste problemet med at opdatere industrielle testdata, overvejede vi igen flere løsninger. Både overførsel via Sstloader og muligheden for at opdele klyngen i testzonen i to dele, som hver skiftevis tilhører den samme klynge med den salgsfremmende, og dermed drives af den. Ved opdatering af testen var det planlagt at bytte dem: den del, der fungerede i testen, ryddes og sættes i produktion, og den anden begynder at arbejde med dataene separat. Men efter at have tænkt igen, vurderede vi mere rationelt de data, der var værd at overføre, og indså, at opkaldene i sig selv er en inkonsekvent enhed for test, hurtigt genereret om nødvendigt, og det er det salgsfremmende datasæt, der ikke har nogen værdi for overførsel til prøve. Der er flere opbevaringsgenstande, der er værd at flytte, men disse er bogstaveligt talt et par borde, og ikke særlig tunge. Derfor vi som en løsning kom Spark igen til undsætning, ved hjælp af hvilken vi skrev og begyndte aktivt at bruge et script til overførsel af data mellem tabeller, prom-test.
Vores nuværende implementeringspolitik giver os mulighed for at arbejde uden rollbacks. Inden kampagnen er der en obligatorisk testkørsel, hvor en fejl ikke er så dyr. I tilfælde af fiasko kan du altid droppe sagsrummet og rulle hele ordningen fra begyndelsen.
For at sikre kontinuerlig tilgængelighed af Cassandra har du brug for en dba og ikke kun ham. Alle, der arbejder med applikationen, skal forstå, hvor og hvordan man ser på den aktuelle situation, og hvordan man kan diagnosticere problemer i tide. For at gøre dette bruger vi aktivt DataStax OpsCenter (Administration og overvågning af arbejdsbelastninger), Cassandra Driver-systemmetrics (antal timeouts for skrivning til C*, antal timeouts for læsning fra C*, maksimal latenstid osv.), overvåger driften af selve applikationen, i samarbejde med Cassandra.
Da vi tænkte over det forrige spørgsmål, indså vi, hvor vores største risiko kunne ligge. Disse er datavisningsformularer, der viser data fra flere uafhængige forespørgsler til lageret. På denne måde kan vi få ret inkonsekvente oplysninger. Men dette problem ville være lige så relevant, hvis vi kun arbejdede med ét datacenter. Så det mest fornuftige her er selvfølgelig at lave en batch-funktion til at læse data på en tredjepartsapplikation, som sikrer at data modtages i en enkelt periode. Hvad angår præstationsopdelingen i læsning og skrivning, så blev vi her stoppet af risikoen for, at vi med et vist tab af forbindelse mellem DC'erne kunne ende med to klynger, der er fuldstændig inkonsistente med hinanden.
Som et resultat, for nu stoppet på konsistensniveauet for at skrive EACH_QUORUM, til læsning - LOCAL_QUORUM
Korte indtryk og konklusioner
For at vurdere den resulterende løsning ud fra et synspunkt om driftsstøtte og udsigter til videre udvikling, besluttede vi at overveje, hvor en sådan udvikling ellers kunne anvendes.
Lige fra starten, derefter datascoring for programmer som "Betal, når det er praktisk" (vi indlæser oplysninger i C*, beregning ved hjælp af Spark-scripts), tager højde for krav med aggregering efter område, lagring af roller og beregning af brugeradgangsrettigheder baseret på rollen matrix.
Som du kan se, er repertoiret bredt og varieret. Og hvis vi vælger lejren af tilhængere/modstandere af NoSQL, så vil vi slutte os til tilhængerne, da vi fik vores fordele, og præcis hvor vi forventede.
Selv Cassandra-muligheden ud af boksen tillader horisontal skalering i realtid, hvilket helt smertefrit løser problemet med at øge data i systemet. Vi var i stand til at flytte en meget høj belastningsmekanisme til beregning af opkaldsaggregater ind i et separat kredsløb, og også adskille applikationsskemaet og logikken, og slippe af med den dårlige praksis med at skrive tilpassede job og objekter i selve databasen. Vi fik mulighed for at vælge og konfigurere, for at fremskynde, hvilke DC'er vi vil udføre beregninger på, og hvilke vi vil registrere data på, vi forsikrede os mod nedbrud af både individuelle noder og DC'en som helhed.
Ved at anvende vores arkitektur på nye projekter, og allerede have en vis erfaring, vil jeg gerne straks tage højde for de nuancer, der er beskrevet ovenfor, og forhindre nogle fejl, udglatte nogle skarpe hjørner, der ikke kunne undgås i starten.
For eksempel, holde styr på Cassandras opdateringer rettidigtfordi en del af de problemer, vi fik, allerede var kendt og rettet.
Sæt ikke både selve databasen og Spark på de samme noder (eller strengt divider med mængden af tilladt ressourceforbrug), da Spark kan spise mere OP end forventet, og vi vil hurtigt få problem nummer 1 fra vores liste.
Forbedre overvågning og operationel kompetence på projektteststadiet. Tag i første omgang så meget som muligt højde for alle potentielle forbrugere af vores løsning, fordi det er det, databasestrukturen i sidste ende vil afhænge af.
Drej det resulterende kredsløb flere gange for mulig optimering. Vælg hvilke felter der kan serialiseres. Forstå hvilke yderligere tabeller vi bør lave for mest korrekt og optimalt at tage højde for, og så giv de nødvendige oplysninger efter anmodning (f.eks. ved at antage, at vi kan gemme de samme data i forskellige tabeller under hensyntagen til forskellige opdelinger iflg. forskellige kriterier, kan vi spare betydeligt CPU-tid til læseanmodninger).
ikke dårligt Sørg med det samme for at vedhæfte TTL og rydde forældede data.
Når du downloader data fra Cassandra Applikationslogikken skulle fungere efter FETCH-princippet, så ikke alle rækker indlæses i hukommelsen på én gang, men vælges i batches.
Det er tilrådeligt, før projektet overføres til den beskrevne løsning kontrollere systemets fejltolerance ved at udføre en række crashtests, såsom tab af data i ét datacenter, retablering af beskadigede data over en vis periode, netværksfrafald mellem datacentre. Sådanne test vil ikke kun give en mulighed for at evaluere fordele og ulemper ved den foreslåede arkitektur, men vil også give god opvarmningspraksis for de ingeniører, der udfører dem, og den erhvervede færdighed vil være langt fra overflødig, hvis systemfejl reproduceres i produktionen.
Hvis vi arbejder med kritisk information (såsom data til fakturering, beregning af abonnentgæld), så er det også værd at være opmærksom på værktøjer, der reducerer de risici, der opstår på grund af funktionerne i DBMS. Brug for eksempel nodesync-værktøjet (Datastax), efter at have udviklet en optimal strategi for dets brug i rækkefølge af hensyn til konsistensen, lad være med at skabe en overdreven belastning på Cassandra og brug det kun til bestemte borde i en bestemt periode.
Hvad sker der med Cassandra efter seks måneders liv? Generelt er der ingen uløste problemer. Vi tillod heller ikke nogen alvorlige ulykker eller tab af data. Ja, vi var nødt til at tænke på at kompensere for nogle problemer, der ikke tidligere var opstået, men i sidste ende forplumrede det ikke vores arkitektoniske løsning. Hvis du vil og ikke er bange for at prøve noget nyt, og samtidig ikke vil blive for skuffet, så gør dig klar til, at intet er gratis. Du bliver nødt til at forstå, dykke ned i dokumentationen og sammensætte din egen individuelle rake mere end i den gamle legacy-løsning, og ingen teori vil fortælle dig på forhånd, hvilken rake der venter på dig.
Kilde: www.habr.com