De säger att allt i livet är värt att prova minst en gång. Och om du är van vid att arbeta med relationella DBMS, så är det värt att bekanta dig med NoSQL i praktiken, först och främst, åtminstone för allmän utveckling. Nu, på grund av den snabba utvecklingen av denna teknik, finns det många motstridiga åsikter och heta debatter om detta ämne, vilket särskilt väcker intresse.
Om du fördjupar dig i kärnan i alla dessa tvister kan du se att de uppstår på grund av fel tillvägagångssätt. De som använder NoSQL-databaser precis där de behövs är nöjda och får alla fördelar med denna lösning. Och experimenterare som förlitar sig på denna teknik som ett universalmedel där den inte alls är tillämplig är besvikna, efter att ha förlorat styrkorna i relationsdatabaser utan att få betydande fördelar.
Jag kommer att berätta om vår erfarenhet av att implementera en lösning baserad på Cassandra DBMS: vad vi hade att möta, hur vi tog oss ur svåra situationer, om vi kunde dra nytta av att använda NoSQL och var vi var tvungna att investera ytterligare ansträngningar/medel .
Den initiala uppgiften är att bygga ett system som registrerar samtal i någon form av lagring.
Funktionsprincipen för systemet är som följer. Inmatningen innehåller filer med en specifik struktur som beskriver strukturen för samtalet. Applikationen säkerställer sedan att denna struktur lagras i lämpliga kolumner. I framtiden används de sparade samtalen för att visa information om trafikförbrukning för abonnenter (avgifter, samtal, saldohistorik).
Det är ganska tydligt varför de valde Cassandra - hon skriver som ett maskingevär, är lätt skalbar och feltolerant.
Så, detta är vad erfarenheten gav oss
Ja, en misslyckad nod är ingen tragedi. Detta är kärnan i Cassandras feltolerans. Men en nod kan vara vid liv och samtidigt börja lida i prestanda. Som det visade sig påverkar detta omedelbart prestandan för hela klustret.
Cassandra kommer inte att skydda dig där Oracle räddade dig med sina begränsningar. Och om författaren till applikationen inte förstod detta i förväg, så är dubbeln som kom till Cassandra inte värre än originalet. När den väl har anlänt lägger vi in den.
IB ogillade starkt den gratis Cassandra ur lådan: Det finns ingen loggning av användaråtgärder, ingen differentiering av rättigheter. Uppgifter om samtal betraktas som personuppgifter, vilket innebär att alla försök att begära/ändra på något sätt ska loggas med möjlighet till efterföljande granskning. Du måste också vara medveten om behovet av att separera rättigheter på olika nivåer för olika användare. En enkel driftingenjör och en superadministratör som fritt kan ta bort hela nyckelutrymmet är olika roller, olika ansvarsområden och kompetenser. Utan sådan åtskillnad av åtkomsträttigheter kommer värdet och integriteten av data omedelbart att ifrågasättas snabbare än med NÅGON konsistensnivå.
Vi tog inte hänsyn till att samtal kräver både seriös analys och periodisk provtagning för en mängd olika tillstånd. Eftersom de valda posterna sedan är tänkta att raderas och skrivas om (som en del av uppgiften måste vi stödja processen att uppdatera data när data initialt kom in i vår loop felaktigt), är Cassandra inte vår vän här. Cassandra är som en spargris - det är bekvämt att lägga saker i, men du kan inte räkna med det.
Vi stötte på ett problem med att överföra data till testzoner (5 noder i testet mot 20 i balen). I det här fallet kan soptippen inte användas.
Problemet med att uppdatera dataschemat för en applikation som skriver till Cassandra. En rollback kommer att generera väldigt många gravstenar, vilket kan leda till produktivitetsförluster på oförutsägbara sätt.. Cassandra är optimerad för inspelning, och tänker inte så mycket innan man skriver.Alla operationer med befintlig data i är också en inspelning. Det vill säga, genom att radera det onödiga kommer vi helt enkelt att producera ännu fler skivor, och bara några av dem kommer att markeras med gravstenar.
Timeouts vid insättning. Cassandra är vacker i inspelningen, men ibland kan det inkommande flödet förbrylla henne avsevärt. Detta händer när applikationen börjar cykla runt flera poster som inte kan infogas av någon anledning. Och vi kommer att behöva en riktig DBA som kommer att övervaka gc.log, system och felsökningsloggar för långsamma frågor, mätvärden om komprimering väntar.
Flera datacenter i ett kluster. Var ska man läsa och var ska man skriva?
Kanske delas upp i att läsa och skriva? Och i så fall, borde det finnas en DC närmare applikationen för att skriva eller läsa? Och kommer vi inte att få en riktig splittrad hjärna om vi väljer fel konsistensnivå? Det finns många frågor, många okända inställningar, möjligheter som du verkligen vill mixtra med.
Hur vi bestämde oss
För att förhindra att noden sjunker inaktiverades SWAP. Och nu, om det är brist på minne, bör noden gå ner och inte skapa stora gc-pauser.
Så vi förlitar oss inte längre på logik i databasen. Applikationsutvecklare tränar om sig själva och börjar aktivt vidta försiktighetsåtgärder i sin egen kod. Idealisk tydlig separation av datalagring och bearbetning.
Vi köpte support från DataStax. Utvecklingen av boxade Cassandra har redan upphört (det senaste åtagandet var i februari 2018). Samtidigt erbjuder Datastax utmärkt service och ett stort antal modifierade och anpassade lösningar för befintliga IP-lösningar.
Jag vill också notera att Cassandra inte är särskilt bekväm för urvalsfrågor. Naturligtvis är CQL ett stort steg framåt för användarna (jämfört med Trift). Men om du har hela avdelningar som är vana vid sådana bekväma kopplingar, fri filtrering efter alla fält och frågeoptimeringsmöjligheter, och dessa avdelningar arbetar med att lösa klagomål och olyckor, så verkar lösningen på Cassandra fientlig och dum mot dem. Och vi började bestämma hur våra kollegor skulle göra prover.
Vi övervägde två alternativ: I det första alternativet skriver vi samtal inte bara i C*, utan också i den arkiverade Oracle-databasen. Endast, till skillnad från C*, lagrar denna databas samtal endast för den aktuella månaden (tillräckligt samtalslagringsdjup för laddningsfodral). Här såg vi omedelbart följande problem: om vi skriver synkront förlorar vi alla fördelar med C* som är förknippade med snabb infogning; om vi skriver asynkront finns det ingen garanti för att alla nödvändiga anrop överhuvudtaget kom in i Oracle. Det fanns ett plus, men ett stort: för drift finns samma välbekanta PL/SQL-utvecklare kvar, det vill säga vi implementerar praktiskt taget "Fasad"-mönstret. Ett alternativt alternativ. Vi implementerar en mekanism som avlastar samtal från C*, hämtar en del data för anrikning från motsvarande tabeller i Oracle, sammanfogar de resulterande proverna och ger oss resultatet, som vi sedan på något sätt använder (rulla tillbaka, upprepa, analysera, beundra). Nackdelar: processen är ganska flerstegs, och dessutom finns det inget gränssnitt för driftanställda.
Till slut bestämde vi oss för det andra alternativet. Apache Spark användes för att prova från olika burkar. Kärnan i mekanismen har reducerats till Java-kod, som, med hjälp av de angivna nycklarna (abonnent, tid för samtal - sektionsnycklar), drar ut data från C*, såväl som nödvändig data för anrikning från vilken annan databas som helst. Därefter sammanfogar den dem i sitt minne och visar resultatet i den resulterande tabellen. Vi ritade ett webbansikte över gnistan och det blev ganska användbart.
När vi löste problemet med att uppdatera industriella testdata övervägde vi återigen flera lösningar. Både överföring via Sstloader och möjligheten att dela upp klustret i testzonen i två delar, som var och en växelvis tillhör samma kluster som den säljfrämjande, och därmed drivs av den. Vid uppdatering av testet var det planerat att byta dem: den del som fungerade i testet rensas och sätts i produktion, och den andra börjar arbeta med data separat. Men efter att ha tänkt igen, bedömde vi mer rationellt de data som var värda att överföra, och insåg att samtalen i sig är en inkonsekvent enhet för tester, snabbt genererade vid behov, och det är reklamdatauppsättningen som inte har något värde för överföring till testa. Det finns flera förvaringsobjekt som är värda att flytta, men dessa är bokstavligen ett par bord, och inte särskilt tunga. Därför vi som en lösning kom Spark igen till undsättning, med hjälp av vilken vi skrev och började aktivt använda ett skript för att överföra data mellan tabeller, prom-test.
Vår nuvarande implementeringspolicy tillåter oss att arbeta utan återställningar. Innan kampanjen är det en obligatorisk testkörning, där ett misstag inte är så dyrt. I händelse av misslyckande kan du alltid släppa ärendeutrymmet och rulla hela schemat från början.
För att säkerställa kontinuerlig tillgänglighet av Cassandra behöver du en dba och inte bara honom. Alla som arbetar med applikationen måste förstå var och hur man ser på den aktuella situationen och hur man kan diagnostisera problem i tid. För att göra detta använder vi aktivt DataStax OpsCenter (Administration och övervakning av arbetsbelastningar), Cassandra Driver-systemstatistik (antal timeouts för skrivning till C*, antal timeouts för läsning från C*, maximal latens etc.), övervakar driften av själva applikationen och arbetar med Cassandra.
När vi tänkte på den föregående frågan insåg vi var vår största risk kan ligga. Dessa är datavisningsformulär som visar data från flera oberoende frågor till lagringen. På så sätt kan vi få ganska inkonsekvent information. Men det här problemet skulle vara lika relevant om vi bara arbetade med ett datacenter. Så det rimligaste här är förstås att skapa en batchfunktion för att läsa data på en tredjepartsapplikation, som säkerställer att data tas emot under en enda tidsperiod. När det gäller uppdelningen i läs- och skrivningsmässigt sett stoppades vi här av risken att vi med viss förlust av kopplingen mellan DC:erna kunde hamna i två kluster som är helt inkonsekventa med varandra.
Som ett resultat, för nu stoppade på konsistensnivån för att skriva EACH_QUORUM, för läsning - LOCAL_QUORUM
Korta intryck och slutsatser
För att utvärdera den resulterande lösningen ur synvinkel av verksamhetsstöd och möjligheter till vidareutveckling, bestämde vi oss för att fundera över var en sådan utveckling annars skulle kunna tillämpas.
Direkt, sedan datapoäng för program som "Betala när det är bekvämt" (vi laddar in information i C*, beräkning med Spark-skript), redogör för anspråk med aggregering efter område, lagra roller och beräkna användarrättigheter baserat på rollen matris.
Som ni ser är repertoaren bred och varierad. Och om vi väljer lägret av anhängare/motståndare till NoSQL, kommer vi att ansluta oss till supportrarna, eftersom vi fick våra fördelar, och precis där vi förväntade oss.
Till och med Cassandra-alternativet ur lådan tillåter horisontell skalning i realtid, vilket helt smärtfritt löser problemet med att öka data i systemet. Vi kunde flytta en mycket hög belastningsmekanism för att beräkna anropsaggregat till en separat krets, och även separera applikationsschemat och logiken, för att bli av med den dåliga praxisen att skriva anpassade jobb och objekt i själva databasen. Vi fick möjlighet att välja och konfigurera, för att snabba upp, vilka DC:er vi ska utföra beräkningar på och vilka vi ska registrera data på, vi försäkrade oss mot krascher av både enskilda noder och DC som helhet.
Genom att tillämpa vår arkitektur på nya projekt, och redan ha lite erfarenhet, vill jag omedelbart ta hänsyn till nyanserna som beskrivs ovan, och förhindra vissa misstag, jämna ut några skarpa hörn som inte kunde undvikas från början.
Till exempel, hålla reda på Cassandras uppdateringar i tideftersom en hel del av problemen vi fick var redan kända och åtgärdade.
Placera inte både själva databasen och Spark på samma noder (eller dela strikt med mängden tillåten resursanvändning), eftersom Spark kan äta mer OP än förväntat, och vi kommer snabbt att få problem nummer 1 från vår lista.
Förbättra övervakning och operativ kompetens vid projekttestningsstadiet. Ta inledningsvis hänsyn till så mycket som möjligt alla potentiella konsumenter av vår lösning, eftersom det är detta som databasstrukturen i slutändan kommer att bero på.
Vrid den resulterande kretsen flera gånger för möjlig optimering. Välj vilka fält som kan serialiseras. Förstå vilka ytterligare tabeller vi bör göra för att mest korrekt och optimalt ta hänsyn, och lämna sedan den information som krävs på begäran (till exempel genom att anta att vi kan lagra samma data i olika tabeller, med hänsyn till olika uppdelningar enl. olika kriterier kan vi spara avsevärt CPU-tid för läsbegäranden).
Inte dåligt Sörj omedelbart för att bifoga TTL och rensa föråldrade data.
När du laddar ner data från Cassandra Applikationslogiken bör fungera enligt FETCH-principen, så att inte alla rader laddas in i minnet på en gång, utan väljs i batcher.
Det är tillrådligt innan du överför projektet till den beskrivna lösningen kontrollera systemets feltolerans genom att utföra en serie krocktester, såsom dataförlust i ett datacenter, restaurering av skadad data under en viss period, nätverksavbrott mellan datacenter. Sådana tester kommer inte bara att tillåta en att utvärdera för- och nackdelarna med den föreslagna arkitekturen, utan kommer också att ge bra uppvärmningsövningar för ingenjörerna som utför dem, och den förvärvade skickligheten kommer att vara långt ifrån överflödig om systemfel reproduceras i produktionen.
Om vi arbetar med kritisk information (som data för fakturering, beräkning av abonnentskulder), så är det också värt att uppmärksamma verktyg som kommer att minska riskerna som uppstår på grund av funktionerna i DBMS. Använd till exempel verktyget nodesync (Datastax), efter att ha utvecklat en optimal strategi för dess användning i ordning för konsekvensens skull, skapa inte en överdriven belastning på Cassandra och använd den endast för vissa bord under en viss period.
Vad händer med Cassandra efter sex månaders liv? I allmänhet finns det inga olösta problem. Vi tillät inte heller några allvarliga olyckor eller dataförlust. Ja, vi var tvungna att tänka på att kompensera för några problem som inte hade uppstått tidigare, men i slutändan grumlade detta inte vår arkitektoniska lösning nämnvärt. Om du vill och inte är rädd för att prova något nytt, och samtidigt inte vill bli för besviken, gör dig redo för det faktum att ingenting är gratis. Du kommer att behöva förstå, fördjupa dig i dokumentationen och sätta ihop din egen individuella rake mer än i den gamla äldre lösningen, och ingen teori kommer att säga dig i förväg vilken rake som väntar på dig.
Källa: will.com