<\/a><\/noindex><\/p>\nS\u00e5 her er hvad erfaringen har givet os<\/h2>\n <\/p>\n
Ja, en nedbrudt node er ikke en tragedie. Det er netop essensen af Cassandra\u2019s fejltolerance. Men en node kan v\u00e6re i live og stadig begynde at falde i ydeevne.<\/b>. Som det viste sig, afspejles dette straks i ydeevnen af hele klyngen.<\/p>\n
<\/p>\n
Cassandra vil ikke beskytte der, hvor Oracle reddede med sine begr\u00e6nsninger.<\/b>. Og hvis applikationens forfatter ikke har indset dette p\u00e5 forh\u00e5nd, er en duplikat for Cassandra ikke bedre end originalen. Kommer den, s\u00e5 inds\u00e6tter vi den.<\/p>\n
<\/p>\n
Den gratis Cassandra \"ud af boksen\" blev pludselig ikke popul\u00e6r blandt sikkerhedsafdelingen: der er ingen logf\u00f8ring af brugerhandlinger, heller ikke adskillelse af rettigheder.<\/b>. Oplysninger om opkald vedr\u00f8rer personlige data, hvilket betyder, at alle fors\u00f8g p\u00e5 at anmode om eller \u00e6ndre dem skal logg\u00f8res med mulighed for efterf\u00f8lgende revision. Det er ogs\u00e5 vigtigt at forst\u00e5 behovet for at opdele rettigheder p\u00e5 forskellige niveauer for forskellige brugere. En almindelig driftsingeni\u00f8r og en superadministrator, der frit kan slette hele keyspace, har forskellige roller, ansvar og kompetence. Uden en s\u00e5dan adskillelse af adgangen vil v\u00e6rdien og integriteten af data straks v\u00e6re under sp\u00f8rgsm\u00e5let, hurtigere end ved en konsistensniveau ANY. <\/p>\n
<\/p>\n
Vi har ikke taget h\u00f8jde for, at opkaldene kr\u00e6ver b\u00e5de seri\u00f8s analyse og periodiske stikpr\u00f8ver under en bred vifte af betingelser. Da de udvalgte poster derefter skal slettes og overskrives (i rammerne af opgaven skal vi underst\u00f8tte dataaktualiseringen ved oprindeligt forkert indkomne data til os), er Cassandra ikke vores ven her. Cassandra er som en spareb\u00f8sse \u2013 den er praktisk at gemme i, men man kan ikke t\u00e6lle i den.<\/b><\/p>\n
<\/p>\n
Vi st\u00e5r over for et problem med at overf\u00f8re data til testzoner<\/b> (5 noder i testen mod 20 i produktionen). Dump i s\u00e5 fald kan ikke anvendes.<\/p>\n
<\/p>\n
Problemet med opdateringer af dataskemaet for applikationen, der skriver til Cassandra. Nedrulning vil skabe en stor m\u00e6ngde gravstene, hvilket uforudsigeligt kan s\u00e6nke vores ydeevne<\/b>. Cassandra er optimeret til skrivning, og f\u00f8r den skriver, t\u00e6nker den ikke meget over det. Enhver operation med eksisterende data i den er ogs\u00e5 en skriveoperation. Dvs. ved at slette un\u00f8dvendige poster, skaber vi bare endnu flere poster, og kun en del af dem vil blive markeret som gravsten.<\/p>\n
<\/p>\n
Timeouts ved inds\u00e6ttelse. Cassandra er fantastisk til skrivning, men nogle gange kan den indkommende str\u00f8m forvirre den betydeligt<\/b>. Dette sker, n\u00e5r applikationen begynder at cykle gennem flere poster, som ikke kan inds\u00e6ttes af en eller anden grund. Og vi f\u00e5r brug for en rigtig DBA, der vil overv\u00e5ge gc.log, system- og debugloggerne med henblik p\u00e5 langsomme foresp\u00f8rgsler og m\u00e5linger p\u00e5 compaction pending.\n<\/p>\n
<\/p>\n
Flere datacentre i klyngen. Hvorfra skal der l\u00e6ses, og hvor skal der skrives?<\/b>
<\/p>\n
Hvordan l\u00f8ste vi det<\/h2>\n <\/p>\n
For at forhindre, at noden falder, deaktiverede vi SWAP<\/b>. Og nu, n\u00e5r der mangler hukommelse, skal noden g\u00e5 ned i stedet for at skabe lange gc-pauser.<\/p>\n
<\/p>\n
S\u00e5 vi stoler ikke l\u00e6ngere p\u00e5 logikken i databasen. Applikationsudviklerne genl\u00e6rer og begynder aktivt at sikkerhedskopiere i deres egen kode.<\/b> Ideel og klar opdeling af dataopbevaring og databehandling.<\/p>\n
<\/p>\n
Vi k\u00f8bte support fra DataStax.<\/b> Den pakke-baserede Cassandra udvikles ikke l\u00e6ngere (sidste commit var i februar 2018). Samtidig tilbyder Datastax en fremragende service og et stort antal tilpassede og optimerede l\u00f8sninger til eksisterende IT-systemer.<\/p>\n
<\/p>\n
Jeg vil ogs\u00e5 bem\u00e6rke, at Cassandra ikke er s\u00e6rlig praktisk til foresp\u00f8rgsler ved selection. Selvf\u00f8lgelig er CQL et stort skridt i retning af brugerne (sammenlignet med Thrift). Men hvis du har hele afdelinger, der er vant til s\u00e5danne bekvemme joins, fri filtrering efter ethvert felt og optimeringsmuligheder for foresp\u00f8rgsler, og disse afdelinger arbejder p\u00e5 at lukke klager og problemer, s\u00e5 virker en l\u00f8sning baseret p\u00e5 Cassandra fjendtlig og t\u00e5belig for dem. Og vi begyndte at finde ud af, hvordan vores kolleger kunne lave selectioner. <\/p>\n
<\/p>\n
Vi overvejede to muligheder. I den f\u00f8rste mulighed skriver vi kald ikke kun til C*, men ogs\u00e5 til den arkiverede Oracle-database. Men i mods\u00e6tning til C* gemmes kald kun for den nuv\u00e6rende m\u00e5ned i denne database (tilstr\u00e6kkelig lagringsdybde for kald til ompriss\u00e6tnings tilf\u00e6lde). Her kunne jeg straks se det f\u00f8lgende problem: hvis vi skriver synkront, mister vi alle fordelene ved C*, som er relateret til hurtig inds\u00e6ttelse; hvis asynkront \u2013 er der ingen garanti for, at alle n\u00f8dvendige kald overhovedet havnede i Oracle. Der var en fordel, men stor: til drift forbliver den samme velkendte PL\/SQL Developer, dvs. vi kan praktisk talt implementere m\u00f8nsteret 'Fasade'. Alternativ mulighed. Vi implementerer en mekanisme, som eksporterer kald fra C*, henter nogle data til berigelse fra de relevante tabeller i Oracle, samler de indhentede udtag og giver os det endelige resultat, som vi s\u00e5 bruger p\u00e5 en eller anden m\u00e5de (ruller tilbage, gentager, analyserer, beundrer). Ulemper: processen bliver temmelig flertrins, og derudover mangler der et interface for driftspersonalet.<\/p>\n
<\/p>\n
I sidste ende stoppede vi alligevel ved den anden mulighed. Til udtr\u00e6k fra forskellige databaser brugte vi Apache Spark.<\/b> Essensen af mekanismen er reduceret til Java-kode, som ved hj\u00e6lp af angivne n\u00f8gler (abonent, tidspunkt for opkald \u2013 n\u00f8gler i sektionen) tr\u00e6kker data ud fra C*, samt de n\u00f8dvendige data til berigelse fra enhver anden database. Derefter samler den dem i sin hukommelse og outputter resultatet til en resultat tabel. Vi tegnede en web-gr\u00e6nseflade over Spark, og det viste sig at v\u00e6re ganske egnet til drift.<\/p>\n
\n
I arbejdet med opdateringen af data, overvejede vi igen flere l\u00f8sninger. B\u00e5de flytning via Sstloader og muligheden for at opdele klyngen i testomr\u00e5det i to dele, hvor hver del skiftevis tilslutter sig den ene produktionsklynge og derved f\u00e5r str\u00f8m derfra. Under opdateringen var det planlagt at bytte dem om: den del, der arbejdede i testen, skulle ryddes og introduceres i produktion, mens den anden begynder at arbejde med data separat. Men efter at have t\u00e6nkt over det igen, vurderede vi mere rationelt, hvilke data der er v\u00e6rd at flytte, og inds\u00e5, at disse kald i sig selv er en inkonsistent enhed til tests, der hurtigt kan genereres ved behov, og at den produktionss\u00e6ttede datam\u00e6ngde ikke har v\u00e6rdi til flytning til test. Der er flere lagerobjekter, som er v\u00e6rd at flytte, men det er bogstaveligt talt et par tabeller, der ikke er s\u00e5 tunge. Derfor Blev Spark igen en hj\u00e6lpsom l\u00f8sning, hvor vi skrev og aktivt brugte et script til at overf\u00f8re data mellem tabellerne i produktions-test.<\/b><\/p>\n
<\/p>\n
Vores nuv\u00e6rende deploymentspolitik tillader os at arbejde uden tilbagekaldelser.<\/b> F\u00f8r produktionen er der obligatorisk udrulning til test, hvor fejlen ikke er s\u00e5 kostbar. I tilf\u00e6lde af fejl kan vi altid droppe keyspace og udrulle hele skemaet fra starten.<\/p>\n
<\/p>\n
For at sikre uafbrudt tilg\u00e6ngelighed af Cassandra er der behov for en DBA, men ikke kun ham. Alle, der arbejder med applikationen, skal forst\u00e5, hvor og hvordan man ser den aktuelle situation samt hvordan man rettidigt diagnosticerer problemer.<\/b> Til dette bruger vi aktivt DataStax OpsCenter (Administration og overv\u00e5gning af arbejdsbelastninger), systemmetrikker fra Cassandra-driveren (antal timeouts ved skrivning til C*, antal timeouts ved l\u00e6sning fra C*, maksimal latency osv.), og monitorerer selve applikationens arbejde, der arbejder med Cassandra.\n<\/p>\n
<\/p>\n
Da vi t\u00e6nkte over det tidligere sp\u00f8rgsm\u00e5l, inds\u00e5 vi, hvor vores hovedrisiko kunne ligge. Det er - formerne for datavisualisering, der tr\u00e6kker data fra flere uafh\u00e6ngige foresp\u00f8rgsler til lageret. P\u00e5 den m\u00e5de kan vi f\u00e5 ret usammenh\u00e6ngende information. Men dette problem ville ogs\u00e5 v\u00e6re aktuelt, hvis vi kun arbejdede med et datacenter. S\u00e5 det mest fornuftige her er selvf\u00f8lgelig at lave en batch-funktion til datal\u00e6sning i en ekstern applikation, som sikrer, at data indhentes p\u00e5 \u00e9n gang. Hvad ang\u00e5r adskillelsen mellem l\u00e6sning og skrivning i forhold til ydeevne, s\u00e5 stoppede vi her, fordi risikoen for, at vi ved et mistet forbindelsesmellem D\u0421 kunne f\u00e5 to fuldst\u00e6ndig usammenh\u00e6ngende klynger.<\/p>\n
<\/p>\n
I sidste ende, p\u00e5 nuv\u00e6rende tidspunkt har vi valgt konsistensniveauet for skrivning til EACH_QUORUM, og for l\u00e6sning - LOCAL_QUORUM<\/b><\/p>\n
<\/p>\n
Korte indtryk og konklusioner<\/h2>\n <\/p>\n
For at vurdere den opn\u00e5ede l\u00f8sning med hensyn til driftsupport og fremtidige udviklingsmuligheder, besluttede vi at overveje, hvor vi ellers kunne anvende en s\u00e5dan udvikling.<\/p>\n
<\/p>\n
Hvis vi skal v\u00e6re hurtige, s\u00e5 datascoring for programmer af typen \u201eBetal, n\u00e5r det passer dig\u201c (vi indl\u00e6sser information i S*, beregner med Spark-scripts), h\u00e5ndtering af klager med aggregering efter retninger, opbevaring af roller og beregning efter rollens matrix for brugeradgangsrettigheder. <\/p>\n
<\/p>\n
Som vi kan se, er repertoiret bredt og varieret. Og hvis vi skal v\u00e6lge side blandt fortalere\/imodstandere af NoSQL, s\u00e5 vil vi tilslutte os tilh\u00e6ngerne, da vi har f\u00e5et vores fordele, og netop der, hvor vi forventede det.<\/p>\n
<\/p>\n
Selv Cassandra-versionen ud af boksen tillader horisontal skalering i realtid, hvilket l\u00f8ser sp\u00f8rgsm\u00e5let om at \u00f8ge dataene i systemet helt smertefrit. Vi har form\u00e5et at isolere en meget h\u00f8jt belastet mekanisme til beregning af aggregater baseret p\u00e5 opkald, samt at adskille skemaet og logikken i applikationen, hvilket har befriet os for den skadelige praksis med at skrive skr\u00e6ddersyede jobs og objekter i selve databasen. Vi har f\u00e5et mulighed for at v\u00e6lge og tilpasse, hvor vi vil udf\u00f8re beregninger, og hvor vi vil skrive data, og vi har sikret os mod nedbrud af b\u00e5de enkelte noder og datacenteret generelt.<\/p>\n
<\/p>\n
N\u00e5r vi anvender vores arkitektur p\u00e5 nye projekter, og allerede besidder en vis erfaring, vil vi straks tage de n\u00e6vnte nuancer i betragtning og undg\u00e5 nogle fejl for at glatte de spidse kanter, som vi oprindeligt ikke kunne undg\u00e5.<\/p>\n
<\/p>\n
For eksempel, f\u00f8lges op p\u00e5 opdateringerne af Cassandra i tide<\/b>, fordi mange af de problemer, vi fik, allerede var kendte og blev rettet.<\/p>\n
<\/p>\n
Ikke at placere b\u00e5de databasen og Spark p\u00e5 de samme noder<\/b> (eller strengt adskille efter antallet af tilladte ressourceforbrug), da Spark kan bruge mere RAM end tilladt, og vi hurtigt vil f\u00e5 problem nummer 1 fra vores liste.<\/p>\n
<\/p>\n
At forbedre overv\u00e5gningen og driftskompetencen allerede i testfasen af projektet. <\/b>Oprindeligt at tage h\u00f8jde for s\u00e5 mange potentielle brugere af vores l\u00f8sning som muligt<\/b>, fordi det i sidste ende vil bestemme strukturen af databasen.<\/p>\n
<\/p>\n
At gennemg\u00e5 den resulterende skema flere gange med henblik p\u00e5 mulig optimering. At identificere hvilke felter der kan serialiseres. At forst\u00e5 hvilke ekstra tabeller vi skal lave for bedst og mest optimalt at tage h\u00f8jde for og derefter returnere den n\u00f8dvendige information (for eksempel ved at acceptere, at de samme data kan gemmes i forskellige tabeller med forskellige opdelinger efter forskellige kriterier, kan vi v\u00e6sentligt spare p\u00e5 procesortiden ved l\u00e6seforesp\u00f8rgsler).<\/p>\n
<\/p>\n
Det er ikke d\u00e5rligt at planl\u00e6gge TTL og oprydning af for\u00e6ldede data fra starten.<\/b><\/p>\n
<\/p>\n
N\u00e5r data eksporteres fra Cassandra b\u00f8r applikationens logik fungere efter princippet FETCH, s\u00e5 ikke alle r\u00e6kker bliver indl\u00e6st i hukommelsen p\u00e5 \u00e9n gang, men v\u00e6lges i batches.<\/b><\/p>\n
<\/p>\n
Det er \u00f8nskeligt at kontrollere systemets fejltolerance, inden projektet overf\u00f8res til den beskrevne l\u00f8sning ved at udf\u00f8re en r\u00e6kke crash-tests<\/b>, som f.eks. datatab i et datacenter, genopretning af beskadigede data over en given periode, netv\u00e6rksnedbrud mellem datacentre. S\u00e5danne tests vil ikke kun evaluere fordele og ulemper ved den foresl\u00e5ede arkitektur, men ogs\u00e5 give en god opvarmningspraksis til de ingeni\u00f8rer, der udf\u00f8rer dem, og den opn\u00e5ede f\u00e6rdighed vil bestemt ikke v\u00e6re overfl\u00f8dig, hvis systemfejl opst\u00e5r i produktionen.<\/p>\n
<\/p>\n
Hvis vi arbejder med kritisk information (s\u00e5som data til fakturering, beregning af abonnementsrestancer), er det ogs\u00e5 vigtigt at overveje v\u00e6rkt\u00f8jer, der kan reducere risici, der opst\u00e5r p\u00e5 grund af databasenes s\u00e6rlige karakteristika. For eksempel at bruge v\u00e6rkt\u00f8jet nodesync (Datastax) og udvikle en optimal strategi for dets anvendelse, s\u00e5 man for konsistens ikke skaber en overfl\u00f8dig belastning p\u00e5 Cassandra<\/b> og kun anvende det til bestemte tabeller i bestemte perioder.<\/p>\n
<\/p>\n
Hvordan st\u00e5r det til efter et halvt \u00e5r med Cassandra? Generelt er der ikke ul\u00f8ste problemer. Vi har heller ikke haft alvorlige nedbrud eller datatab. Ja, vi m\u00e5tte t\u00e6nke p\u00e5 at kompensere for nogle problemer, der ikke tidligere fandtes, men det p\u00e5virkede ikke vores arkitektoniske beslutning i n\u00e6vnev\u00e6rdig grad. Hvis du \u00f8nsker at pr\u00f8ve noget nyt og ikke er bange for det, men samtidig ikke vil blive alt for skuffet, s\u00e5 v\u00e6r forberedt p\u00e5, at der ikke er noget gratis. Du m\u00e5 bruge mere tid p\u00e5 at unders\u00f8ge, s\u00e6tte dig ind i dokumentationen og samle din egen erfaring end med det gamle legacy-system, og ingen teori kan p\u00e5 forh\u00e5nd fort\u00e6lle dig, hvilke specifikke udfordringer der venter dig.<\/p>\n
Kilde: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u0413\u043e\u0432\u043e\u0440\u044f\u0442, \u0432 \u0436\u0438\u0437\u043d\u0438 \u0432\u0441\u0435 \u0441\u0442\u043e\u0438\u0442 \u043f\u043e\u043f\u0440\u043e\u0431\u043e\u0432\u0430\u0442\u044c \u0445\u043e\u0442\u044f \u0431\u044b \u0440\u0430\u0437. \u0418 \u0435\u0441\u043b\u0438 \u0432\u044b \u043f\u0440\u0438\u0432\u044b\u043a\u043b\u0438 \u0440\u0430\u0431\u043e\u0442\u0430\u0442\u044c \u0441 \u0440\u0435\u043b\u044f\u0446\u0438\u043e\u043d\u043d\u044b\u043c\u0438 \u0421\u0423\u0411\u0414, \u0442\u043e \u043f\u043e\u0437\u043d\u0430\u043a\u043e\u043c\u0438\u0442\u044c\u0441\u044f \u043d\u0430 \u043f\u0440\u0430\u043a\u0442\u0438\u043a\u0435 \u0441 NoSQL \u0441\u0442\u043e\u0438\u0442 \u0432 \u043f\u0435\u0440\u0432\u0443\u044e \u043e\u0447\u0435\u0440\u0435\u0434\u044c \u0445\u043e\u0442\u044f \u0431\u044b \u0434\u043b\u044f \u043e\u0431\u0449\u0435\u0433\u043e \u0440\u0430\u0437\u0432\u0438\u0442\u0438\u044f. \u0421\u0435\u0439\u0447\u0430\u0441 \u0432 \u0441\u0438\u043b\u0443 \u0431\u0443\u0440\u043d\u043e\u0433\u043e \u0440\u0430\u0437\u0432\u0438\u0442\u0438\u044f \u044d\u0442\u043e\u0439 \u0442\u0435\u0445\u043d\u043e\u043b\u043e\u0433\u0438\u0438 \u043e\u0447\u0435\u043d\u044c \u043c\u043d\u043e\u0433\u043e \u043f\u0440\u043e\u0442\u0438\u0432\u043e\u0440\u0435\u0447\u0438\u0432\u044b\u0445 \u043c\u043d\u0435\u043d\u0438\u0439 \u0438 \u0433\u043e\u0440\u044f\u0447\u0438\u0445 \u0441\u043f\u043e\u0440\u043e\u0432 \u043d\u0430 \u044d\u0442\u0443 \u0442\u0435\u043c\u0443, \u0447\u0442\u043e \u043e\u0441\u043e\u0431\u0435\u043d\u043d\u043e \u043f\u043e\u0434\u043e\u0433\u0440\u0435\u0432\u0430\u0435\u0442 \u0438\u043d\u0442\u0435\u0440\u0435\u0441. \u0415\u0441\u043b\u0438 \u0432\u043d\u0438\u043a\u043d\u0443\u0442\u044c […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":28210,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-37585","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t
![\"Hvordan](\"\/wp-content\/uploads\/2019\/08\/4845d37a9928f888639c4ebeb7807787.jpg\")
![\"Hvordan](\"\/wp-content\/uploads\/2019\/08\/c7b095dc8879011adb751c96427af512.jpg\")
<\/p>\n