De sier at alt i livet er verdt å prøve minst en gang. Og hvis du er vant til å jobbe med relasjonelle DBMS-er, så er det verdt å sette seg inn i NoSQL i praksis, først og fremst, i det minste for generell utvikling. Nå, på grunn av den raske utviklingen av denne teknologien, er det mange motstridende meninger og opphetede debatter om dette emnet, noe som spesielt gir interesse.
Hvis du fordyper deg i essensen av alle disse tvistene, kan du se at de oppstår på grunn av feil tilnærming. De som bruker NoSQL-databaser akkurat der de trengs er fornøyde og får alle fordelene med denne løsningen. Og eksperimentere som er avhengige av denne teknologien som et universalmiddel der den ikke er anvendelig i det hele tatt, er skuffet, etter å ha mistet styrken til relasjonsdatabaser uten å oppnå betydelige fordeler.
Jeg vil fortelle deg om vår erfaring med å implementere en løsning basert på Cassandra DBMS: hva vi måtte møte, hvordan vi kom oss ut av vanskelige situasjoner, om vi kunne dra nytte av å bruke NoSQL og hvor vi måtte investere ekstra innsats/midler .
Den første oppgaven er å bygge et system som registrerer samtaler i en slags lagring.
Driftsprinsippet til systemet er som følger. Inndataene inkluderer filer med en bestemt struktur som beskriver strukturen til samtalen. Applikasjonen sørger da for at denne strukturen lagres i de aktuelle kolonnene. I fremtiden brukes de lagrede samtalene til å vise informasjon om trafikkforbruk for abonnenter (avgifter, samtaler, saldohistorikk).
Det er helt klart hvorfor de valgte Cassandra - hun skriver som et maskingevær, er lett skalerbar og feiltolerant.
Så dette er hva erfaring ga oss
Ja, en mislykket node er ikke en tragedie. Dette er essensen av Cassandras feiltoleranse. Men en node kan være i live og samtidig begynne å lide i ytelse. Som det viste seg, påvirker dette umiddelbart ytelsen til hele klyngen.
Cassandra vil ikke beskytte deg der Oracle reddet deg med sine begrensninger. Og hvis forfatteren av applikasjonen ikke forsto dette på forhånd, så er dobbelen som kom til Cassandra ikke verre enn originalen. Når den er ankommet, legger vi den inn.
IB mislikte sterkt den gratis Cassandra ut av esken: Det er ingen logging av brukerhandlinger, ingen differensiering av rettigheter. Informasjon om samtaler regnes som personopplysninger, noe som betyr at alle forsøk på å be om/endre på noen måte skal loggføres med mulighet for etterfølgende revisjon. Du må også være klar over behovet for å skille rettigheter på ulike nivåer for ulike brukere. En enkel operasjonsingeniør og en superadmin som fritt kan slette hele nøkkelområdet er forskjellige roller, forskjellige ansvarsområder og kompetanser. Uten slik differensiering av tilgangsrettigheter vil verdien og integriteten til dataene umiddelbart komme i tvil raskere enn med NOEN konsistensnivå.
Vi tok ikke hensyn til at samtaler krever både seriøse analyser og periodisk prøvetaking for en rekke forhold. Siden de valgte postene da skal slettes og omskrives (som en del av oppgaven, må vi støtte prosessen med å oppdatere data når dataene opprinnelig kom feil inn i loopen vår), er ikke Cassandra vår venn her. Cassandra er som en sparegris - det er praktisk å legge ting i, men du kan ikke regne med det.
Vi oppdaget et problem med å overføre data til testsoner (5 noder i testen mot 20 i skoleballet). I dette tilfellet kan ikke dumpen brukes.
Problemet med å oppdatere dataskjemaet til en applikasjon som skriver til Cassandra. En tilbakerulling vil generere svært mange gravsteiner, noe som kan føre til produktivitetstap på uforutsigbare måter.. Cassandra er optimert for opptak, og tenker ikke så mye før skriving.Enhver operasjon med eksisterende data i er også et opptak. Det vil si at ved å slette det unødvendige vil vi rett og slett produsere enda flere plater, og bare noen av dem vil merkes med gravsteiner.
Tidsavbrudd ved innsetting. Cassandra er vakker i opptaket, men noen ganger kan den innkommende strømmen forvirre henne betydelig. Dette skjer når applikasjonen begynner å sykle rundt flere poster som av en eller annen grunn ikke kan settes inn. Og vi vil trenge en ekte DBA som vil overvåke gc.log, system og feilsøkingslogger for trege spørringer, beregninger for komprimering venter.
Flere datasentre i en klynge. Hvor skal man lese fra og hvor skal man skrive?
Kanskje delt opp i lesing og skriving? Og bør det i så fall være en DC nærmere søknaden om å skrive eller lese? Og vil vi ikke ende opp med en skikkelig splittet hjerne hvis vi velger feil konsistensnivå? Det er mange spørsmål, mange ukjente innstillinger, muligheter som du virkelig ønsker å fikle med.
Hvordan vi bestemte oss
For å forhindre at noden synker, deaktiverte vi SWAP. Og nå, hvis det er mangel på minne, bør noden gå ned og ikke lage store gc-pauser.
Så vi stoler ikke lenger på logikk i databasen. Applikasjonsutviklere omskolerer seg og begynner aktivt å ta forholdsregler i sin egen kode. Ideell klar separasjon av datalagring og behandling.
Vi kjøpte støtte fra DataStax. Utviklingen av boksede Cassandra har allerede opphørt (siste forpliktelse var i februar 2018). Samtidig tilbyr Datastax utmerket service og et stort antall modifiserte og tilpassede løsninger for eksisterende IP-løsninger.
Jeg vil også merke meg at Cassandra ikke er veldig praktisk for utvalgsspørringer. Selvfølgelig er CQL et stort skritt fremover for brukere (sammenlignet med Trift). Men hvis du har hele avdelinger som er vant til slike praktiske sammenføyninger, gratis filtrering etter alle felt- og søkeoptimeringsmuligheter, og disse avdelingene jobber med å løse klager og ulykker, så virker løsningen på Cassandra fiendtlig og dum for dem. Og vi begynte å bestemme hvordan kollegene våre skulle lage prøver.
Vi vurderte to alternativer: I det første alternativet skriver vi samtaler ikke bare i C*, men også i den arkiverte Oracle-databasen. Bare, i motsetning til C*, lagrer denne databasen anrop kun for inneværende måned (tilstrekkelig lagringsdybde for anrop for opplading). Her så vi umiddelbart følgende problem: hvis vi skriver synkront, mister vi alle fordelene med C* knyttet til rask innsetting; hvis vi skriver asynkront, er det ingen garanti for at alle nødvendige anrop kom inn i Oracle i det hele tatt. Det var ett pluss, men et stort: for drift gjenstår den samme kjente PL/SQL-utvikleren, det vil si at vi praktisk talt implementerer "Facade"-mønsteret. Et alternativt alternativ. Vi implementerer en mekanisme som laster ut anrop fra C*, henter noen data for berikelse fra de tilsvarende tabellene i Oracle, slår sammen de resulterende prøvene og gir oss resultatet, som vi så på en eller annen måte bruker (rull tilbake, gjenta, analysere, beundre). Ulemper: prosessen er ganske flertrinn, og i tillegg er det ikke noe grensesnitt for driftsansatte.
Til slutt bestemte vi oss for det andre alternativet. Apache Spark ble brukt til å prøve fra forskjellige krukker. Essensen av mekanismen er redusert til Java-kode, som ved å bruke de spesifiserte nøklene (abonnent, anropstid - seksjonsnøkler), trekker ut data fra C*, samt nødvendige data for berikelse fra enhver annen database. Deretter slår den sammen dem i minnet og viser resultatet i den resulterende tabellen. Vi tegnet et nettflate over gnisten og det viste seg ganske brukbart.
Da vi løste problemet med å oppdatere industrielle testdata, vurderte vi igjen flere løsninger. Både overføring via Sstloader og muligheten til å dele klyngen i testsonen i to deler, som hver vekselvis tilhører samme klynge med kampanjen, og dermed drives av den. Ved oppdatering av testen var det planlagt å bytte dem: delen som fungerte i testen blir slettet og satt i produksjon, og den andre begynner å jobbe med dataene separat. Etter å ha tenkt på nytt vurderte vi imidlertid dataene som var verdt å overføre mer rasjonelt, og innså at samtalene i seg selv er en inkonsekvent enhet for tester, raskt generert om nødvendig, og det er reklamedatasettet som ikke har noen verdi for overføring til test. Det er flere oppbevaringsobjekter som er verdt å flytte, men dette er bokstavelig talt et par bord, og ikke veldig tunge. Derfor vi som en løsning kom Spark igjen til unnsetning, ved hjelp av hvilken vi skrev og begynte å aktivt bruke et skript for å overføre data mellom tabeller, prom-test.
Vår nåværende implementeringspolicy lar oss jobbe uten tilbakeføringer. Før kampanjen er det en obligatorisk testkjøring, hvor en feil ikke er så dyr. Ved feil kan du alltid droppe saksområdet og rulle hele opplegget fra begynnelsen.
For å sikre kontinuerlig tilgjengelighet av Cassandra trenger du en dba og ikke bare ham. Alle som jobber med applikasjonen må forstå hvor og hvordan de skal se på dagens situasjon og hvordan man kan diagnostisere problemer i tide. For å gjøre dette bruker vi aktivt DataStax OpsCenter (Administrasjon og overvåking av arbeidsbelastninger), Cassandra Driver-systemberegninger (antall timeouts for skriving til C*, antall timeouts for lesing fra C*, maksimal latens osv.), overvåker driften av selve applikasjonen, og jobber med Cassandra.
Da vi tenkte på det forrige spørsmålet, innså vi hvor hovedrisikoen vår kan ligge. Dette er datavisningsskjemaer som viser data fra flere uavhengige spørringer til lagringen. På denne måten kan vi få ganske inkonsekvent informasjon. Men dette problemet ville vært like relevant hvis vi jobbet med bare ett datasenter. Så det mest fornuftige her er selvfølgelig å lage en batch-funksjon for å lese data på en tredjepartsapplikasjon, som vil sikre at data mottas i løpet av en enkelt tidsperiode. Når det gjelder ytelsesmessig inndeling i lesing og skriving, ble vi her stoppet av risikoen for at vi med noe tap av forbindelse mellom DC-ene kunne ende opp med to klynger som er helt inkonsistente med hverandre.
Som et resultat, foreløpig stoppet på konsistensnivået for å skrive EACH_QUORUM, for lesing - LOCAL_QUORUM
Korte inntrykk og konklusjoner
For å vurdere den resulterende løsningen med tanke på driftsstøtte og utsikter for videre utvikling, bestemte vi oss for å tenke på hvor ellers en slik utvikling kunne brukes.
Med en gang, deretter datascoring for programmer som "Betal når det er praktisk" (vi laster inn informasjon i C*, beregning ved hjelp av Spark-skript), regnskap for krav med aggregering etter område, lagring av roller og beregning av brukertilgangsrettigheter basert på rollen matrise.
Som du ser er repertoaret bredt og variert. Og hvis vi velger leiren av tilhengere/motstandere av NoSQL, så vil vi slutte oss til supporterne, siden vi fikk våre fordeler, og akkurat der vi forventet.
Selv Cassandra-alternativet ut av esken tillater horisontal skalering i sanntid, og løser helt smertefritt problemet med å øke dataene i systemet. Vi var i stand til å flytte en svært høy belastningsmekanisme for å beregne anropsaggregater inn i en egen krets, og også separere applikasjonsskjemaet og logikken, slik at vi ble kvitt den dårlige praksisen med å skrive tilpassede jobber og objekter i selve databasen. Vi fikk muligheten til å velge og konfigurere, for å øke hastigheten, hvilke DC-er vi skal utføre beregninger på og hvilke vi skal registrere data på, vi forsikret oss mot krasj av både individuelle noder og DC-en som helhet.
Ved å bruke arkitekturen vår på nye prosjekter, og allerede ha litt erfaring, vil jeg umiddelbart ta hensyn til nyansene beskrevet ovenfor, og forhindre noen feil, jevne ut noen skarpe hjørner som ikke kunne unngås i utgangspunktet.
For eksempel, holde styr på Cassandras oppdateringer i tidefordi ganske mange av problemene vi fikk allerede var kjent og fikset.
Ikke plasser både selve databasen og Spark på samme noder (eller strengt delt på mengden tillatt ressursbruk), siden Spark kan spise mer OP enn forventet, og vi vil raskt få problem nummer 1 fra listen vår.
Forbedre overvåking og operativ kompetanse på prosjektteststadiet. Ta i utgangspunktet så mye som mulig i betraktning alle potensielle forbrukere av løsningen vår, fordi det er dette databasestrukturen til slutt vil avhenge av.
Roter den resulterende kretsen flere ganger for mulig optimalisering. Velg hvilke felt som kan serialiseres. Forstå hvilke tilleggstabeller vi bør lage for mest mulig korrekt og optimalt å ta hensyn til, og deretter gi nødvendig informasjon på forespørsel (for eksempel ved å anta at vi kan lagre samme data i ulike tabeller, tatt i betraktning ulike sammenbrudd iht. forskjellige kriterier, kan vi spare betydelig CPU-tid for leseforespørsler).
Ikke dårlig Sørg umiddelbart for å legge ved TTL og rense utdaterte data.
Når du laster ned data fra Cassandra Applikasjonslogikken skal fungere etter FETCH-prinsippet, slik at ikke alle rader lastes inn i minnet samtidig, men velges i batcher.
Det anbefales før du overfører prosjektet til den beskrevne løsningen sjekk systemets feiltoleranse ved å utføre en rekke kollisjonstester, for eksempel tap av data i ett datasenter, restaurering av skadede data over en viss periode, nettverksavbrudd mellom datasentre. Slike tester vil ikke bare tillate en å evaluere fordeler og ulemper med den foreslåtte arkitekturen, men vil også gi god oppvarmingspraksis for ingeniørene som utfører dem, og den ervervede ferdigheten vil være langt fra overflødig hvis systemfeil reproduseres i produksjonen.
Hvis vi jobber med kritisk informasjon (som data for fakturering, beregning av abonnentgjeld), er det også verdt å ta hensyn til verktøy som vil redusere risikoen som oppstår på grunn av funksjonene til DBMS. Bruk for eksempel nodesync-verktøyet (Datastax), etter å ha utviklet en optimal strategi for bruk i rekkefølge for konsistensens skyld, ikke skap en overdreven belastning på Cassandra og bruk den bare for visse bord i en viss periode.
Hva skjer med Cassandra etter seks måneders levetid? Generelt er det ingen uløste problemer. Vi tillot heller ikke alvorlige ulykker eller tap av data. Ja, vi måtte tenke på å kompensere for noen problemer som ikke hadde oppstått tidligere, men til syvende og sist gjorde ikke dette mye uklar på vår arkitektoniske løsning. Hvis du vil og ikke er redd for å prøve noe nytt, og samtidig ikke vil bli for skuffet, så gjør deg klar for det faktum at ingenting er gratis. Du må forstå, fordype deg i dokumentasjonen og sette sammen din egen individuelle rake mer enn i den gamle legacy-løsningen, og ingen teori vil fortelle deg på forhånd hvilken rake som venter på deg.
Kilde: www.habr.com