KeyDB som en [potensiell] erstatning for Redis

Det var ingen anmeldelser av et "raskere alternativ til Redis" på Habré - KeyDB. Etter å ha fått ganske nylig erfaring med å bruke det, vil jeg gjerne fylle dette gapet.

Bakgrunnen er ganske banal: En dag, med stor tilstrømning av trafikk, ble det registrert en betydelig forringelse av applikasjonsytelsen (nemlig responstid). På det tidspunktet var det dessverre ikke mulig å gjennomføre en normal diagnose av hva som skjedde, så det ble i ettertid planlagt en rekke belastningstester. Etter å ha gjennomført dem, kunne vi oppdage en flaskehals, som var databasecachen i Redis. Som ofte skjer, kunne ikke problemet løses med en gang og på riktig måte - av utviklerne (ved å endre arbeidslogikken). Derfor ble nysgjerrigheten og et ønske om å overvinne situasjonen i en rundkjøring slått på. Slik så denne artikkelen ut.

Problemer

Om Redis generelt

Som mange vet, er Redis en enkelt-tråds database. For å være mer presis er det slik i sammenheng med å jobbe med brukerdata. Tross alt, siden den fjerde versjonen, service, intern drift av Redis oversatt for parallell utførelse. Denne endringen påvirket imidlertid bare en liten del av arbeidsmengden, siden hoveddelen av arbeidet gjøres på brukerdata.

Utallige kopier har blitt brutt om dette emnet, men Redis-utviklere nekter hardnakket å implementere full parallellitet, og nevner hvor mye det vil komplisere applikasjonen og øke overheadkostnadene, samt legge til flere feil. Deres posisjon er denne: Hvis du står overfor et enkeltkjerneproblem, har du problemer med applikasjonsarkitekturen, og du må endre noe i den. Blant brukerne er det imidlertid også "en annen leir" - de som sitter fast på en kjerne og hevder at Redis skaper en flaskehals for seg selv. Ved virkelig store belastninger - før eller siden - er det uunngåelig å støte på dette problemet, som legger betydelige begrensninger på arkitekturen og/eller tvungne komplikasjoner i det.

Jeg vil ikke vurdere denne eller den oppfatningen. I stedet vil jeg dele vår konkrete sak og hvordan vi løste den.

Vår sak

I et av prosjektene møtte vi det faktum at utviklingsteamet hadde konfigurert ekstremt aggressiv caching av data fra databasen (PostgreSQL) via Redis. Dette var den eneste måten som, under plutselig tilstrømning av trafikk, reddet selve PostgreSQL og, som et resultat, applikasjonen fra døden.

Etter en rekke belastningstester analyserte vi situasjonen og fant ut at Redis var begrenset til én kjerne (det som kalles en "hylle"), etterfulgt av ganske rask nedbrytning av applikasjonen. "Kvelningen" var eksponentiell: Så snart Redis ytelsesgrense var nådd, sluttet alt å fungere.

Det så omtrent slik ut:

New Relic identifiserte tydelig problemet:

Her er statistikken for operasjonen: get i Redis:

Etter at problemet ble rapportert til utviklingsteamet i detalj, viste det seg at "problemet ikke kan løses akkurat nå." Dermed startet jakten på en løsning på driftssiden, og allerede nevnte KeyDB var svaret.

Men før vi begynner vår gjennomgang, er det verdt å nevne at prosjektet bruker frittstående Redis, siden klyngeløsningen basert på Sentinel er mye dårligere når det gjelder latens. En åpenbar løsning var å lage flere kopier av cachen: og la applikasjonen gå overalt med balansering! Etter å ha rådført seg med utviklerne ble vi imidlertid tvunget til å forkaste dette alternativet på grunn av den aktive og komplekse cache-ugyldiggjøringsmekanismen til applikasjonen. Det samme problemet utvidet til cache-sharding.

En rask titt på KeyDB

Mens vi lette etter en mulig løsning på problemet, oppdaget vi applikasjon kalt KeyDB. Dette er en Redis-gaffel utviklet av kanadisk selskap og distribuert under den gratis BSD-lisensen. Prosjektet er veldig ungt: det har eksistert siden begynnelsen av 2019. Historien er at forfatterne også en gang møtte begrensningene til Redis... og bestemte seg for å lage sin egen gaffel. Dessuten løste den ikke bare kjente problemer, men fikk også tilleggsfunksjoner som bare er tilgjengelige i bedriftsversjonen av Redis.

For de som ønsker å bli nærmere kjent med KeyDB, finnes det en god introduksjonsartikkel om Medium, som presenterer DBMS og korte benchmarks som sammenligner det med dets "foreldre" - Redis.

Først av alt ble vi tiltrukket av KeyDB av den potensielle løsningen på problemene våre, og samtidig var vi interessert i noen tilleggsfunksjoner. Bruk av KeyDB lovet følgende fordeler:

• oppnå full multithreading;
• full og absolutt kompatibilitet med Redis (dette var spesielt viktig for oss, siden det ikke var mulig å gjøre noen endringer på applikasjonssiden), som også lovet problemfri migrering;
• innebygd backup-mekanisme i S3-lagring;
• enkel å implementere aktiv replikering;
• enkel clustering og sharding uten Sentinel og annen støtteprogramvare.

Mer enn 3 tusen stjerner og mange bidragsytere på GitHub så også oppmuntrende ut. Applikasjonen er ganske aktivt utviklet og støttet, noe som er tydelig synlig i commits, kommunikasjon i saker, samt lukkede (aksepterte) PR-er. Responsen fra hovedvedlikeholderen på alle fronter er alltid vennlig og rask. Generelt var det nok av argumenter.

Migrasjon og resultater

Selv om migrasjonsprosjektet var litt av et gamble (på grunn av det nye med KeyDB), var det ikke mye å tape. Tross alt er det ganske raskt og enkelt å rulle tilbake endringer - heldigvis er hele infrastrukturen distribuert i Kubernetes, og de innebygde mekanismene Rullende oppdatering De løser slike problemer veldig bra.

Generelt utarbeidet vi Helm-maler, byttet applikasjonen i testmiljøet til en ny database og rullet alt ut, og overleverte det til kundens QA-avdeling.

Testingen begynte, som varte i omtrent en uke og detaljene vi ikke dykket inn i. Vi vet bare at kunden testet standardfunksjonene for å jobbe med Redis ved hjelp av en PHP-driver phpredis, og gjennomførte også QA-testing av brukergrensesnittet. Etter det fikk vi grønt lys: ingen bivirkninger ble funnet ved bruk av den nye programvaren. Det er Fra et søknadssynspunkt har ingenting endret seg i det hele tatt.

Det er verdt å merke seg at vi ikke endret noe i konfigurasjonen: bokstavelig talt erstattet vi ganske enkelt bildet som ble brukt. Det samme gjelder for overvåking og eksport av beregninger til Prometheus: den vanligste av dem fungerer perfekt med KeyDB og uten noen modifikasjoner. Dermed kan vi trygt si at fra et operasjonelt synspunkt er dette rett og slett et ideelt grep.

Takket være alt dette, etter å ha byttet applikasjonen til et nytt DBMS, kan du ikke endre noe, men som et "stabiliseringstiltak" kan du la det være i denne formen for å jobbe i kamp i noen tid. Men hvis du ønsker å se en ytelsesøkning (eller endringer i det hele tatt), må du ikke glemme det som standard KeyDB parameter ansvarlig for multithreading (server-threads), er lik én, altså DBMS fungerer akkurat det samme som Redis.

Etter bytte, testing og litt levetid på den nye applikasjonen (med KeyDB), bestemte vi oss for å gjenta belastningstesten med de samme parameterne som ble brukt for Redis. Hva var resultatet?...

I følge CPU-forbruksgrafen ble elimineringen av problemer med "taket" til en kjerne umiddelbart merkbar: prosessen begynte å bruke tilgjengelige ressurser:

Og senere prøvde jeg å "torturere" applikasjonen ganske kraftig og så forbruk på opptil tre kjerner ...

I følge New Relic begynte webapplikasjonen som helhet, med samme belastning, å oppføre seg merkbart mer adekvat. Noe ytelsesforringelse ble fortsatt observert, men sammenlignet med en lignende graf ovenfor kan du selv vurdere den betydelige fremgangen:

Latensen til den nye databasen (KeyDB) ble også verre, men holdt seg innenfor akseptable verdier:

Følgende graf viser tydelig at antallet forespørsler til selve KeyDB er likt:

For å oppsummere disse syntetiske testene kan vi si at både Redis og KeyDB viser en betydelig ytelsesforringelse i latens (40 ms+) med en betydelig økning i antall parallelle tilkoblinger (1000+). I vårt tilfelle var nettapplikasjonen i stand til å "kaste bort" Redis' latens selv med et lavere antall tilkoblinger (400+), selv om en slik belastning for KeyDB forble akseptabel.

Funn

Dette eksemplet viser tydelig styrken til Open Source-fellesskapet i utviklingen av prosjekter det er interessert i. Jeg kom over en utmerket uttalelse på Internett, hvis generelle betydning kokte ned til følgende: "Noen store selskaper lager et interessant produkt, gjør noen av funksjonene åpne, men lar den viktigste delen betales. Fellesskapet bruker det og bruker det, og så gir noen opp og gjør en gaffel, implementerer de samme betalte funksjonene i den og åpner dem for alle." Her er KeyDB det samme tilfellet.

Når vi snakker om selve migrasjonen, som var overraskende enkel, mottok vi ikke så mye en betydelig økning i ytelse, som kan forventes ved å se på grafene til forfatterne av KeyDB... Dette er imidlertid bare vårt spesielle tilfelle, der det kan være mange avvik, inkludert den beryktede arkitekturen til applikasjonen (f.eks. , et stort antall kommandoer get i Redis i stedet for det mer effektive alternativet med aggregerte søk mget...). Likevel klarte vi å oppnå positive resultater, og sammen med dem mange nyttige funksjoner som vi vil implementere i nær fremtid.

Generelt ser KeyDB lovende ut: ettersom vi får praktisk erfaring med dette DBMS (og vi fortsatt må få det!) og utvikler selve prosjektet, vil vi vurdere muligheten for å bruke det i andre situasjoner.

Denne artikkelen bør imidlertid ikke betraktes som en veiledning (for ikke å snakke om en oppfordring) til handling for den utbredte forlatelsen av Redis til fordel for KeyDB. Til tross for vår positive erfaring er det klart at dette ikke er en sølvkule. Saken var veldig spesifikk: spesifikt for å løse et kortvarig problem i en situasjon der det var nødvendig å gjøre det raskt og til minimale kostnader, var denne løsningen berettiget. Vil KeyDB være nyttig i ditt tilfelle? Nå vet du i hvert fall at denne potensielle muligheten eksisterer.

PS

Les også på bloggen vår:

• «Databaser og Kubernetes (gjennomgang og videorapport)";
• «Migrering av Cassandra til Kubernetes: funksjoner og løsninger";
• «Sømløs migrering av MongoDB til Kubernetes";
• «Sømløs migrering av RabbitMQ til Kubernetes'.

Kilde: www.habr.com