Man sÀger att man bör prova allt minst en gÄng i livet. Och om du Àr van vid att arbeta med relationsdatabaser Àr det vÀrt att bekanta sig med NoSQL i praktiken, Ätminstone för din allmÀnna utveckling. Just nu, pÄ grund av den snabba utvecklingen av denna teknik, finns det mÄnga motstridiga Äsikter och heta debatter om Àmnet, vilket sÀrskilt vÀcker intresse.
Om man gÄr till botten med dessa diskussioner kan man se att de uppstÄr pÄ grund av felaktiga angreppssÀtt. De som anvÀnder NoSQL-databaser dÀr de verkligen behövs Àr nöjda och fÄr alla fördelar av lösningen. De som experimenterar och hoppas pÄ teknologin som en universal lösning dÀr den överhuvudtaget inte Àr tillÀmplig, kÀnner besvikelse och förlorar styrkorna hos relationsdatabaser utan att fÄ nÄgra betydande vinster.
Jag ska berÀtta om vÄr erfarenhet av att implementera en lösning baserad pÄ databasen Cassandra: vad vi stÀlldes inför, hur vi lyckades lösa svÄra situationer, om vi lyckades fÄ vinster frÄn att anvÀnda NoSQL och var vi behövde investera ytterligare anstrÀngningar/medel.
Den ursprungliga uppgiften var att bygga ett system för att registrera samtal i ett visst lagringsutrymme.
Systemets princip Àr följande. In data kommer filer med en viss struktur som beskriver samtalets struktur. DÀrefter ser programmet till att denna struktur sparas i motsvarande kolumner. De sparade samtalen anvÀnds senare för att visa information om trafikförbrukning för abonnenter (debiteringar, samtal, saldohistorik).
Varför vi valde Cassandra Ă€r ganska tydligt â den skriver som en kulspruta, Ă€r lĂ€tt att skala och Ă€r motstĂ„ndskraftig mot fel.
SÄ hÀr har vÄr erfarenhet givit oss.
Ja, en störd nod Àr inte en tragedi. Det Àr just poÀngen med Cassandras motstÄndskraft. Men en nod kan vara aktiv och samtidigt börja fÄ prestandaproblem.. Det visade sig att detta omedelbart pÄverkar hela klustrets prestanda.
Cassandra skyddar inte i de situationerna dÀr Oracle rÀddade med sina begrÀnsningar.. Och om applikationens författare inte förstod detta i förvÀg, sÄ Àr en duplikatpost för Cassandra inte ett dugg sÀmre Àn originalet. Kommit in, sÄ lÄt oss sÀtta in.
Den kostnadsfria Cassandra "ur lÄdan" uppskattades inte av sÀkerhetsavdelningen: det finns ingen loggning av anvÀndarÄtgÀrder, inte heller rÀttighetsindelning.. 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.
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 â it's convenient to store things, but you can't really count on it.
Encountered a problem transferring data to test zones. (5 nodes in test compared to 20 in production). In this case, a dump cannot be used.
The problem of updating the applicationâs data schema that writes to Cassandra. Rolling back will create a great many tombstones, which may unpredictably degrade performance.. Cassandra is optimized for writes, and before writing, it doesnât 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.
Timeouts when inserting. Cassandra is great at writing, but sometimes the incoming stream can significantly puzzle it.. 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.
Several data centers in the cluster. Where to read from and where to write to?
Ăr det möjligt att separera lĂ€sning och skrivning? Och i sĂ„ fall, ska den datacenter som hanterar skrivning eller lĂ€sning vara nĂ€rmare till applikationen? Kommer vi att drabbas av riktig split brain om vi vĂ€ljer fel nivĂ„ av konsistens? Det finns mĂ„nga frĂ„gor och mĂ„nga outforskade instĂ€llningar och möjligheter som vi verkligen vill utforska.
Hur vi löste det
För att noderna inte ska pÄverkas negativt har vi stÀngt av SWAP. Och nu, vid brist pÄ minne, bör noden gÄ ner istÀllet för att skapa lÄnga gc-pauser.
SÄ vi litar inte lÀngre pÄ logiken i databasen. Applikationsutvecklarna lÀr om sig och börjar aktivt skydda sig i sin egen kod. En perfekt och tydlig uppdelning mellan lagring och databehandling.
Vi köpte support frÄn DataStax. Den förpackade Cassandra utvecklas inte lÀngre (senaste commit i februari 2018). Samtidigt erbjuder Datastax en utmÀrkt tjÀnst och ett stort antal förbÀttrade och anpassade lösningar för befintliga informationssystem.
Jag vill ocksÄ nÀmna att Cassandra inte Àr sÀrskilt bekvÀm för urvalsförfrÄgningar. SjÀlvklart Àr CQL ett stort steg mot anvÀndarna (jÀmfört med Thrift). Men om ni har hela avdelningar som Àr vana vid sÄdana bekvÀma joins, fri filtrering pÄ valfritt fÀlt och optimeringsmöjligheter för frÄgorna, sÄ verkar en lösning baserad pÄ Cassandra bÄde fientlig och dum för dem. Och vi började fundera pÄ hur vÄra kollegor kan göra urval.
Vi övervĂ€gde tvĂ„ alternativ. I det första alternativet skriver vi anrop inte bara till C*, utan ocksĂ„ till den arkiverade Oracle-databasen. Men till skillnad frĂ„n C* lagras endast anrop för den aktuella mĂ„naden i denna databas (tillrĂ€cklig lagringsdjup för omprövningsfall). HĂ€r sĂ„g vi genast ett problem: om vi skriver synkront förlorar vi alla fördelar med C* kopplade till snabb insĂ€ttning, om asynkront â finns det ingen garanti för att alla nödvĂ€ndiga anrop faktiskt kommer in i Oracle. En fördel fanns, men den var stor: för drift behöver vi fortsĂ€tta anvĂ€nda det vanliga PL/SQL Developer, det vill sĂ€ga vi kan i praktiken implementera mönstret "Fasad". Alternativt alternativ. Vi implementerar en mekanism som exporterar anrop frĂ„n C*, hĂ€mtar data för berikning frĂ„n motsvarande tabeller i Oracle, sammanfogar de erhĂ„llna urvalen och ger oss det resulterande resultatet, som vi sedan pĂ„ nĂ„got sĂ€tt anvĂ€nder (Ă„terkallar, repetera, analyserar, beundrar). Nackdelar: processen blir ganska flerstegad, och dessutom finns det inget grĂ€nssnitt för driftpersonalen.
Till slut bestĂ€mde vi oss Ă€ndĂ„ för det andra alternativet. För urval frĂ„n olika databaser anvĂ€nde vi Apache Spark. Essensen av mekanismen reducerades till Java-kod som hĂ€mtar data frĂ„n C* enligt angivna nycklar (abonnent, tid för samtal â nycklar för avsnittet) samt de nödvĂ€ndiga data för berikning frĂ„n vilken annan databas som helst. DĂ€refter sammanfogar den dem i sinnet och presenterar resultatet i den resulterande tabellen. Ăver Spark tog vi fram ett webbgrĂ€nssnitt och det blev helt klart anvĂ€ndbart för drift.
Vid hanteringen av uppdateringsuppgiften för dataöverföring har vi Äterigen övervÀgt flera lösningar. BÄde överföring via Sstloader och alternativet att dela klustret i testomrÄdet i tvÄ delar har diskuterats, dÀr varje del vÀxelvis gÄr in i ett kluster med produktionen, och pÄ sÄ sÀtt fÄr ström frÄn den. Vid uppdateringen av testet var det planerat att byta deras platser: den del som arbetade i testet skulle rensas och föras in i produktionen, medan den andra skulle börja arbeta med data separat. Men efter att ha tÀnkt igenom det en gÄng till bedömde vi mer rationellt vilka data som egentligen bör överföras, och insÄg att sjÀlva anropen Àr en inkonsekvent enhet för tester, snabbt genererad vid behov, och just produktuppsÀttningen av data har inget vÀrde för att överföras till testet. Det finns flera objektlagringsenheter som bör överföras, men det Àr bokstavligen ett par tabeller som inte Àr sÀrskilt tunga. DÀrför... kom vi Äterigen tillbaka till lösningen med hjÀlp av Spark, med vilken vi skrev och började aktivt anvÀnda ett skript för dataöverföring mellan tabellerna produktion-test.
VÄr nuvarande policy för distribution tillÄter oss att arbeta utan ÄterstÀllningar. Innan produktionen sker en obligatorisk uppdatering pÄ testet, dÀr fel kostar mindre. Vid misslyckande kan man alltid ta bort case-space och Äteruppdatera hela schemat frÄn början.
För att sÀkerstÀlla kontinuerlig tillgÄng till Cassandra behövs en DBA och inte bara han. Alla som arbetar med applikationen mÄste förstÄ var och hur man ser den aktuella situationen och hur man snabbt diagnostiserar problem. För detta anvÀnder vi aktivt DataStax OpsCenter (administration och övervakning av arbetsbelastningar), systemmetrik Cassandra Driver (antal tidsgrÀnser för skrivningar i C*, antal tidsgrÀnser för lÀsningar frÄn C*, maximal latens osv.), vi övervakar funktionen hos sjÀlva applikationen som arbetar med Cassandra.
NÀr vi funderade över den tidigare frÄgan insÄg vi var den största risken kan ligga. Det handlar om sÀttet att visa data som hÀmtar information frÄn flera oberoende förfrÄgningar till lagringslösningen. PÄ sÄ sÀtt kan vi fÄ ganska inkonsekvent information. Men detta problem skulle ocksÄ vara aktuellt om vi bara arbetade med ett datacenter. Det mest rimliga hÀr Àr förstÄs att skapa en batchfunktion för datalÀsning i en tredjepartsapplikation, som sÀkerstÀller att vi fÄr data vid en och samma tidpunkt. NÀr det gÀller separering av lÀsning och skrivning i termer av prestanda, sÄ stoppade oss risken att nÀr vi tappar anslutningen mellan datacentren, kan vi fÄ tvÄ helt inkonsekventa kluster.
SĂ„ledes, för nĂ€rvarande har vi landat pĂ„ nivĂ„erna av överensstĂ€mmelse för skrivning till EACH_QUORUM, för lĂ€sning â LOCAL_QUORUM
Kortfattade intryck och slutsatser
För att utvÀrdera den lösning vi fÄtt angÄende operativt stöd och framtida utveckling, beslutade vi att tÀnka pÄ var vi ytterligare kan tillÀmpa en sÄdan utveckling.
Om vi ser det direkt, sÄ poÀngsÀttning av data för program som "Betala nÀr det passar" (laddar information i S*, berÀkning pÄ Spark-skript), att hantera klagomÄl med aggregering per inriktning, lagra roller och berÀkna i en rollmatris för anvÀndarnas ÄtkomstrÀttigheter.
Som vi ser Àr repertoaren bred och varierad. Och om man ska vÀlja sida mellan anhÀngare/motstÄndare av NoSQL, kommer vi att ansluta oss till anhÀngarna, eftersom vi fÄtt fördelar, just dÀr var vi förvÀntade oss det.
Ăven versionen av Cassandra direkt ur lĂ„dan möjliggör horisontell skalning i realtid och löser helt utan problem frĂ„gan om ökning av data i systemet. Vi lyckades avgrĂ€nsa en mycket högbelastad mekanism för berĂ€kning av aggregat utifrĂ„n samtal, samt dela schemat och logiken av applikationen, vilket befriade oss frĂ„n den dĂ„liga vanan att skriva egna jobb och objekt i sjĂ€lva databasen. Vi fick möjlighet att vĂ€lja och konfigurera, för att öka hastigheten, i vilka datacenter vi ska genomföra berĂ€kningar och i vilka data ska skrivas, och vi sĂ€krade oss mot nedgĂ„ngar i bĂ„de enskilda noder och datacenter i stort.
NÀr vi tillÀmpar vÄr arkitektur pÄ nya projekt, och redan har viss erfarenhet, vill vi omedelbart ta hÀnsyn till de nu nÀmnda nyanserna för att undvika vissa misstag och jÀmna ut de vassa kanter som inte gick att undvika frÄn början.
Till exempel, att i tid följa uppdateringar av sjÀlva Cassandra., eftersom mÄnga av de problem vi har haft redan var kÀnda och ÄtgÀrdades.
Att inte placera bÄde databasen och Spark pÄ samma noder. (eller strikt dela upp efter tillÄtna resursanvÀndningar), eftersom Spark kan anvÀnda mer RAM Àn tillÄtet, vilket snabbt leder till problem nummer 1 pÄ vÄr lista.
Att förbÀttra övervakningen och kompetensen för drift redan under testningen av projektet. Att initialt ta hÀnsyn till alla potentiella anvÀndare av vÄr lösning sÄ mycket som möjligt,eftersom det i slutÀndan kommer att pÄverka databassens struktur.
Att snurra den resulterande schemat nÄgra gÄnger för att hitta eventuella optimeringsmöjligheter. Att identifiera vilka fÀlt som kan serialiseras. Att förstÄ vilka ytterligare tabeller vi behöver skapa för att korrekt och optimalt beakta och sedan leverera den begÀrda informationen (till exempel, genom att anta att vi kan lagra samma data i olika tabeller, med hÀnsyn till olika uppdelningar enligt olika kriterier, kan vi avsevÀrt spara processor tid vid lÀsfrÄgor).
Bra att omedelbart förutse installation av TTL och rengöring av förÄldrad data.
Vid export av data frÄn Cassandra bör applikationens logik fungera enligt principen FETCH, sÄ att inte alla rader laddas in i minnet pÄ en gÄng utan vÀljs i omgÄngar.
Det Àr önskvÀrt att innan projektet flyttas till den beskrivna lösningen kontrollera systemets felresistens genom att utföra en serie krashtester, sÄsom dataförlust i en datacenter, ÄterstÀllning av korrupt data under en viss period, och nÀtverksproblem mellan datacentren. SÄdana tester kommer inte bara att möjliggöra en bedömning av fördelarna och nackdelarna med den föreslagna arkitekturen, utan ocksÄ ge en bra övning för ingenjörerna som genomför dem, och den fÀrdigheten kommer att vara mer Àn anvÀndbar om systemfel intrÀffar i produktion.
Om vi arbetar med kritisk information (sÄsom data för fakturering, berÀkning av kundens skuld), bör vi ocksÄ uppmÀrksamma verktyg som kan minska de risker som uppstÄr pÄ grund av egenskaperna hos databashanteringssystem. Till exempel, att anvÀnda verktyget nodesync (Datastax) med en vÀl utvecklad strategi för dess anvÀndning för att inte skapa överbelastning pÄ Cassandra för konsistensens skull och anvÀnda det endast för specifika tabeller under angiven tid.
NĂ„vĂ€l, efter ett halvĂ„r med Cassandra? Ăverlag har det inte funnits nĂ„gra olösta problem. Vi har inte heller rĂ„kat ut för allvarliga krascher eller dataförluster. Ja, vi var tvungna att tĂ€nka pĂ„ sĂ€tt att kompensera för vissa problem som inte hade uppstĂ„tt tidigare, men i slutĂ€ndan har det inte pĂ„verkat vĂ„r arkitektoniska lösning negativt. Om du vill prova nĂ„got nytt och inte Ă€r rĂ€dd för att misslyckas, förbered dig pĂ„ att ingenting Ă€r gratis. Du mĂ„ste engagera dig, sĂ€tta dig in i dokumentationen och samla pĂ„ dig dina egna misstag mer Ă€n med de gamla legacy-lösningarna, och ingen teori kan i förvĂ€g berĂ€tta för dig vilka misstag just du kommer att stöta pĂ„.
KĂ€lla: habr.com
