<\/a><\/noindex><\/p>\nS\u00e5 h\u00e4r har v\u00e5r erfarenhet givit oss.<\/h2>\n <\/p>\n
Ja, en st\u00f6rd nod \u00e4r inte en tragedi. Det \u00e4r just po\u00e4ngen med Cassandras motst\u00e5ndskraft. Men en nod kan vara aktiv och samtidigt b\u00f6rja f\u00e5 prestandaproblem.<\/b>. Det visade sig att detta omedelbart p\u00e5verkar hela klustrets prestanda.<\/p>\n
<\/p>\n
Cassandra skyddar inte i de situationerna d\u00e4r Oracle r\u00e4ddade med sina begr\u00e4nsningar.<\/b>. Och om applikationens f\u00f6rfattare inte f\u00f6rstod detta i f\u00f6rv\u00e4g, s\u00e5 \u00e4r en duplikatpost f\u00f6r Cassandra inte ett dugg s\u00e4mre \u00e4n originalet. Kommit in, s\u00e5 l\u00e5t oss s\u00e4tta in.<\/p>\n
<\/p>\n
Den kostnadsfria Cassandra \"ur l\u00e5dan\" uppskattades inte av s\u00e4kerhetsavdelningen: det finns ingen loggning av anv\u00e4ndar\u00e5tg\u00e4rder, inte heller r\u00e4ttighetsindelning.<\/b>. Information about calls relates to personal data, meaning that all attempts to request\/change it in any way must be logged with the possibility of subsequent audits. It is also necessary to understand the need to separate rights at different levels for different users. A simple operations engineer and a superadmin, who can freely delete the entire keyspace, are different roles, with different responsibilities and competencies. Without such access rights segregation, the value and integrity of the data will quickly come into question, faster than with an ANY consistency level. <\/p>\n
<\/p>\n
We did not consider that call data requires both serious analytics and periodic samples under various conditions. Since the selected records are expected to be deleted and overwritten later (as part of the task, we need to support the data update process for initially incorrectly received data), Cassandra is not our friend here. Cassandra, as a piggy bank \u2013 it's convenient to store things, but you can't really count on it.<\/b><\/p>\n
<\/p>\n
Encountered a problem transferring data to test zones.<\/b> (5 nodes in test compared to 20 in production). In this case, a dump cannot be used.<\/p>\n
<\/p>\n
The problem of updating the application\u2019s data schema that writes to Cassandra. Rolling back will create a great many tombstones, which may unpredictably degrade performance.<\/b>. Cassandra is optimized for writes, and before writing, it doesn\u2019t think much. Any operation with existing data is also a write. That is, by deleting the unnecessary, we just create even more records, only some of which will be marked as tombstones.<\/p>\n
<\/p>\n
Timeouts when inserting. Cassandra is great at writing, but sometimes the incoming stream can significantly puzzle it.<\/b>. This happens when the application starts looping through several records that cannot be inserted for some reason. And we will need a real DBA who will monitor gc.log, system, and debug logs for slow queries, and metrics on compaction pending.\n<\/p>\n
<\/p>\n
Several data centers in the cluster. Where to read from and where to write to?<\/b>
<\/p>\n
Hur vi l\u00f6ste det<\/h2>\n <\/p>\n
F\u00f6r att noderna inte ska p\u00e5verkas negativt har vi st\u00e4ngt av SWAP<\/b>. Och nu, vid brist p\u00e5 minne, b\u00f6r noden g\u00e5 ner ist\u00e4llet f\u00f6r att skapa l\u00e5nga gc-pauser.<\/p>\n
<\/p>\n
S\u00e5 vi litar inte l\u00e4ngre p\u00e5 logiken i databasen. Applikationsutvecklarna l\u00e4r om sig och b\u00f6rjar aktivt skydda sig i sin egen kod.<\/b> En perfekt och tydlig uppdelning mellan lagring och databehandling.<\/p>\n
<\/p>\n
Vi k\u00f6pte support fr\u00e5n DataStax.<\/b> Den f\u00f6rpackade Cassandra utvecklas inte l\u00e4ngre (senaste commit i februari 2018). Samtidigt erbjuder Datastax en utm\u00e4rkt tj\u00e4nst och ett stort antal f\u00f6rb\u00e4ttrade och anpassade l\u00f6sningar f\u00f6r befintliga informationssystem.<\/p>\n
<\/p>\n
Jag vill ocks\u00e5 n\u00e4mna att Cassandra inte \u00e4r s\u00e4rskilt bekv\u00e4m f\u00f6r urvalsf\u00f6rfr\u00e5gningar. Sj\u00e4lvklart \u00e4r CQL ett stort steg mot anv\u00e4ndarna (j\u00e4mf\u00f6rt med Thrift). Men om ni har hela avdelningar som \u00e4r vana vid s\u00e5dana bekv\u00e4ma joins, fri filtrering p\u00e5 valfritt f\u00e4lt och optimeringsm\u00f6jligheter f\u00f6r fr\u00e5gorna, s\u00e5 verkar en l\u00f6sning baserad p\u00e5 Cassandra b\u00e5de fientlig och dum f\u00f6r dem. Och vi b\u00f6rjade fundera p\u00e5 hur v\u00e5ra kollegor kan g\u00f6ra urval. <\/p>\n
<\/p>\n
Vi \u00f6verv\u00e4gde tv\u00e5 alternativ. I det f\u00f6rsta alternativet skriver vi anrop inte bara till C*, utan ocks\u00e5 till den arkiverade Oracle-databasen. Men till skillnad fr\u00e5n C* lagras endast anrop f\u00f6r den aktuella m\u00e5naden i denna databas (tillr\u00e4cklig lagringsdjup f\u00f6r ompr\u00f6vningsfall). H\u00e4r s\u00e5g vi genast ett problem: om vi skriver synkront f\u00f6rlorar vi alla f\u00f6rdelar med C* kopplade till snabb ins\u00e4ttning, om asynkront \u2013 finns det ingen garanti f\u00f6r att alla n\u00f6dv\u00e4ndiga anrop faktiskt kommer in i Oracle. En f\u00f6rdel fanns, men den var stor: f\u00f6r drift beh\u00f6ver vi forts\u00e4tta anv\u00e4nda det vanliga PL\/SQL Developer, det vill s\u00e4ga vi kan i praktiken implementera m\u00f6nstret \"Fasad\". Alternativt alternativ. Vi implementerar en mekanism som exporterar anrop fr\u00e5n C*, h\u00e4mtar data f\u00f6r berikning fr\u00e5n motsvarande tabeller i Oracle, sammanfogar de erh\u00e5llna urvalen och ger oss det resulterande resultatet, som vi sedan p\u00e5 n\u00e5got s\u00e4tt anv\u00e4nder (\u00e5terkallar, repetera, analyserar, beundrar). Nackdelar: processen blir ganska flerstegad, och dessutom finns det inget gr\u00e4nssnitt f\u00f6r driftpersonalen.<\/p>\n
<\/p>\n
Till slut best\u00e4mde vi oss \u00e4nd\u00e5 f\u00f6r det andra alternativet. F\u00f6r urval fr\u00e5n olika databaser anv\u00e4nde vi Apache Spark.<\/b> Essensen av mekanismen reducerades till Java-kod som h\u00e4mtar data fr\u00e5n C* enligt angivna nycklar (abonnent, tid f\u00f6r samtal \u2013 nycklar f\u00f6r avsnittet) samt de n\u00f6dv\u00e4ndiga data f\u00f6r berikning fr\u00e5n vilken annan databas som helst. D\u00e4refter sammanfogar den dem i sinnet och presenterar resultatet i den resulterande tabellen. \u00d6ver Spark tog vi fram ett webbgr\u00e4nssnitt och det blev helt klart anv\u00e4ndbart f\u00f6r drift.<\/p>\n
\n
Vid hanteringen av uppdateringsuppgiften f\u00f6r data\u00f6verf\u00f6ring har vi \u00e5terigen \u00f6verv\u00e4gt flera l\u00f6sningar. B\u00e5de \u00f6verf\u00f6ring via Sstloader och alternativet att dela klustret i testomr\u00e5det i tv\u00e5 delar har diskuterats, d\u00e4r varje del v\u00e4xelvis g\u00e5r in i ett kluster med produktionen, och p\u00e5 s\u00e5 s\u00e4tt f\u00e5r str\u00f6m fr\u00e5n den. Vid uppdateringen av testet var det planerat att byta deras platser: den del som arbetade i testet skulle rensas och f\u00f6ras in i produktionen, medan den andra skulle b\u00f6rja arbeta med data separat. Men efter att ha t\u00e4nkt igenom det en g\u00e5ng till bed\u00f6mde vi mer rationellt vilka data som egentligen b\u00f6r \u00f6verf\u00f6ras, och ins\u00e5g att sj\u00e4lva anropen \u00e4r en inkonsekvent enhet f\u00f6r tester, snabbt genererad vid behov, och just produktupps\u00e4ttningen av data har inget v\u00e4rde f\u00f6r att \u00f6verf\u00f6ras till testet. Det finns flera objektlagringsenheter som b\u00f6r \u00f6verf\u00f6ras, men det \u00e4r bokstavligen ett par tabeller som inte \u00e4r s\u00e4rskilt tunga. D\u00e4rf\u00f6r... kom vi \u00e5terigen tillbaka till l\u00f6sningen med hj\u00e4lp av Spark, med vilken vi skrev och b\u00f6rjade aktivt anv\u00e4nda ett skript f\u00f6r data\u00f6verf\u00f6ring mellan tabellerna produktion-test.<\/b><\/p>\n
<\/p>\n
V\u00e5r nuvarande policy f\u00f6r distribution till\u00e5ter oss att arbeta utan \u00e5terst\u00e4llningar.<\/b> Innan produktionen sker en obligatorisk uppdatering p\u00e5 testet, d\u00e4r fel kostar mindre. Vid misslyckande kan man alltid ta bort case-space och \u00e5teruppdatera hela schemat fr\u00e5n b\u00f6rjan.<\/p>\n
<\/p>\n
F\u00f6r att s\u00e4kerst\u00e4lla kontinuerlig tillg\u00e5ng till Cassandra beh\u00f6vs en DBA och inte bara han. Alla som arbetar med applikationen m\u00e5ste f\u00f6rst\u00e5 var och hur man ser den aktuella situationen och hur man snabbt diagnostiserar problem.<\/b> F\u00f6r detta anv\u00e4nder vi aktivt DataStax OpsCenter (administration och \u00f6vervakning av arbetsbelastningar), systemmetrik Cassandra Driver (antal tidsgr\u00e4nser f\u00f6r skrivningar i C*, antal tidsgr\u00e4nser f\u00f6r l\u00e4sningar fr\u00e5n C*, maximal latens osv.), vi \u00f6vervakar funktionen hos sj\u00e4lva applikationen som arbetar med Cassandra.\n<\/p>\n
<\/p>\n
N\u00e4r vi funderade \u00f6ver den tidigare fr\u00e5gan ins\u00e5g vi var den st\u00f6rsta risken kan ligga. Det handlar om s\u00e4ttet att visa data som h\u00e4mtar information fr\u00e5n flera oberoende f\u00f6rfr\u00e5gningar till lagringsl\u00f6sningen. P\u00e5 s\u00e5 s\u00e4tt kan vi f\u00e5 ganska inkonsekvent information. Men detta problem skulle ocks\u00e5 vara aktuellt om vi bara arbetade med ett datacenter. Det mest rimliga h\u00e4r \u00e4r f\u00f6rst\u00e5s att skapa en batchfunktion f\u00f6r datal\u00e4sning i en tredjepartsapplikation, som s\u00e4kerst\u00e4ller att vi f\u00e5r data vid en och samma tidpunkt. N\u00e4r det g\u00e4ller separering av l\u00e4sning och skrivning i termer av prestanda, s\u00e5 stoppade oss risken att n\u00e4r vi tappar anslutningen mellan datacentren, kan vi f\u00e5 tv\u00e5 helt inkonsekventa kluster.<\/p>\n
<\/p>\n
S\u00e5ledes, f\u00f6r n\u00e4rvarande har vi landat p\u00e5 niv\u00e5erna av \u00f6verensst\u00e4mmelse f\u00f6r skrivning till EACH_QUORUM, f\u00f6r l\u00e4sning \u2013 LOCAL_QUORUM<\/b><\/p>\n
<\/p>\n
Kortfattade intryck och slutsatser<\/h2>\n <\/p>\n
F\u00f6r att utv\u00e4rdera den l\u00f6sning vi f\u00e5tt ang\u00e5ende operativt st\u00f6d och framtida utveckling, beslutade vi att t\u00e4nka p\u00e5 var vi ytterligare kan till\u00e4mpa en s\u00e5dan utveckling.<\/p>\n
<\/p>\n
Om vi ser det direkt, s\u00e5 po\u00e4ngs\u00e4ttning av data f\u00f6r program som \"Betala n\u00e4r det passar\" (laddar information i S*, ber\u00e4kning p\u00e5 Spark-skript), att hantera klagom\u00e5l med aggregering per inriktning, lagra roller och ber\u00e4kna i en rollmatris f\u00f6r anv\u00e4ndarnas \u00e5tkomstr\u00e4ttigheter. <\/p>\n
<\/p>\n
Som vi ser \u00e4r repertoaren bred och varierad. Och om man ska v\u00e4lja sida mellan anh\u00e4ngare\/motst\u00e5ndare av NoSQL, kommer vi att ansluta oss till anh\u00e4ngarna, eftersom vi f\u00e5tt f\u00f6rdelar, just d\u00e4r var vi f\u00f6rv\u00e4ntade oss det.<\/p>\n
<\/p>\n
\u00c4ven versionen av Cassandra direkt ur l\u00e5dan m\u00f6jligg\u00f6r horisontell skalning i realtid och l\u00f6ser helt utan problem fr\u00e5gan om \u00f6kning av data i systemet. Vi lyckades avgr\u00e4nsa en mycket h\u00f6gbelastad mekanism f\u00f6r ber\u00e4kning av aggregat utifr\u00e5n samtal, samt dela schemat och logiken av applikationen, vilket befriade oss fr\u00e5n den d\u00e5liga vanan att skriva egna jobb och objekt i sj\u00e4lva databasen. Vi fick m\u00f6jlighet att v\u00e4lja och konfigurera, f\u00f6r att \u00f6ka hastigheten, i vilka datacenter vi ska genomf\u00f6ra ber\u00e4kningar och i vilka data ska skrivas, och vi s\u00e4krade oss mot nedg\u00e5ngar i b\u00e5de enskilda noder och datacenter i stort.<\/p>\n
<\/p>\n
N\u00e4r vi till\u00e4mpar v\u00e5r arkitektur p\u00e5 nya projekt, och redan har viss erfarenhet, vill vi omedelbart ta h\u00e4nsyn till de nu n\u00e4mnda nyanserna f\u00f6r att undvika vissa misstag och j\u00e4mna ut de vassa kanter som inte gick att undvika fr\u00e5n b\u00f6rjan.<\/p>\n
<\/p>\n
Till exempel, att i tid f\u00f6lja uppdateringar av sj\u00e4lva Cassandra.<\/b>, eftersom m\u00e5nga av de problem vi har haft redan var k\u00e4nda och \u00e5tg\u00e4rdades.<\/p>\n
<\/p>\n
Att inte placera b\u00e5de databasen och Spark p\u00e5 samma noder.<\/b> (eller strikt dela upp efter till\u00e5tna resursanv\u00e4ndningar), eftersom Spark kan anv\u00e4nda mer RAM \u00e4n till\u00e5tet, vilket snabbt leder till problem nummer 1 p\u00e5 v\u00e5r lista.<\/p>\n
<\/p>\n
Att f\u00f6rb\u00e4ttra \u00f6vervakningen och kompetensen f\u00f6r drift redan under testningen av projektet. <\/b>Att initialt ta h\u00e4nsyn till alla potentiella anv\u00e4ndare av v\u00e5r l\u00f6sning s\u00e5 mycket som m\u00f6jligt,<\/b>eftersom det i slut\u00e4ndan kommer att p\u00e5verka databassens struktur.<\/p>\n
<\/p>\n
Att snurra den resulterande schemat n\u00e5gra g\u00e5nger f\u00f6r att hitta eventuella optimeringsm\u00f6jligheter. Att identifiera vilka f\u00e4lt som kan serialiseras. Att f\u00f6rst\u00e5 vilka ytterligare tabeller vi beh\u00f6ver skapa f\u00f6r att korrekt och optimalt beakta och sedan leverera den beg\u00e4rda informationen (till exempel, genom att anta att vi kan lagra samma data i olika tabeller, med h\u00e4nsyn till olika uppdelningar enligt olika kriterier, kan vi avsev\u00e4rt spara processor tid vid l\u00e4sfr\u00e5gor).<\/p>\n
<\/p>\n
Bra att omedelbart f\u00f6rutse installation av TTL och reng\u00f6ring av f\u00f6r\u00e5ldrad data.<\/b><\/p>\n
<\/p>\n
Vid export av data fr\u00e5n Cassandra b\u00f6r applikationens logik fungera enligt principen FETCH, s\u00e5 att inte alla rader laddas in i minnet p\u00e5 en g\u00e5ng utan v\u00e4ljs i omg\u00e5ngar.<\/b><\/p>\n
<\/p>\n
Det \u00e4r \u00f6nskv\u00e4rt att innan projektet flyttas till den beskrivna l\u00f6sningen kontrollera systemets felresistens genom att utf\u00f6ra en serie krashtester<\/b>, s\u00e5som dataf\u00f6rlust i en datacenter, \u00e5terst\u00e4llning av korrupt data under en viss period, och n\u00e4tverksproblem mellan datacentren. S\u00e5dana tester kommer inte bara att m\u00f6jligg\u00f6ra en bed\u00f6mning av f\u00f6rdelarna och nackdelarna med den f\u00f6reslagna arkitekturen, utan ocks\u00e5 ge en bra \u00f6vning f\u00f6r ingenj\u00f6rerna som genomf\u00f6r dem, och den f\u00e4rdigheten kommer att vara mer \u00e4n anv\u00e4ndbar om systemfel intr\u00e4ffar i produktion.<\/p>\n
<\/p>\n
Om vi arbetar med kritisk information (s\u00e5som data f\u00f6r fakturering, ber\u00e4kning av kundens skuld), b\u00f6r vi ocks\u00e5 uppm\u00e4rksamma verktyg som kan minska de risker som uppst\u00e5r p\u00e5 grund av egenskaperna hos databashanteringssystem. Till exempel, att anv\u00e4nda verktyget nodesync (Datastax) med en v\u00e4l utvecklad strategi f\u00f6r dess anv\u00e4ndning f\u00f6r att inte skapa \u00f6verbelastning p\u00e5 Cassandra f\u00f6r konsistensens skull<\/b> och anv\u00e4nda det endast f\u00f6r specifika tabeller under angiven tid.<\/p>\n
<\/p>\n
N\u00e5v\u00e4l, efter ett halv\u00e5r med Cassandra? \u00d6verlag har det inte funnits n\u00e5gra ol\u00f6sta problem. Vi har inte heller r\u00e5kat ut f\u00f6r allvarliga krascher eller dataf\u00f6rluster. Ja, vi var tvungna att t\u00e4nka p\u00e5 s\u00e4tt att kompensera f\u00f6r vissa problem som inte hade uppst\u00e5tt tidigare, men i slut\u00e4ndan har det inte p\u00e5verkat v\u00e5r arkitektoniska l\u00f6sning negativt. Om du vill prova n\u00e5got nytt och inte \u00e4r r\u00e4dd f\u00f6r att misslyckas, f\u00f6rbered dig p\u00e5 att ingenting \u00e4r gratis. Du m\u00e5ste engagera dig, s\u00e4tta dig in i dokumentationen och samla p\u00e5 dig dina egna misstag mer \u00e4n med de gamla legacy-l\u00f6sningarna, och ingen teori kan i f\u00f6rv\u00e4g ber\u00e4tta f\u00f6r dig vilka misstag just du kommer att st\u00f6ta p\u00e5.<\/p>\n
K\u00e4lla: 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
![\"Hur](\"\/wp-content\/uploads\/2019\/08\/4845d37a9928f888639c4ebeb7807787.jpg\")
![\"Hur](\"\/wp-content\/uploads\/2019\/08\/c7b095dc8879011adb751c96427af512.jpg\")
<\/p>\n