KeyDB kui [potentsiaalne] asendus Redis'ile

Habr's reviews of "a faster alternative to Redis" are missing — KeyDB. After gaining sufficient recent experience with its use, I wanted to fill this gap.

The backstory is quite mundane: once, during a surge in traffic, significant application performance degradation was recorded (specifically — response times). At that time, unfortunately, it was not possible to conduct a proper diagnosis of what was happening, so we subsequently planned a series of load tests. After conducting these tests, we were able to identify the bottleneck, which was the database cache in Redis. As is often the case, the problem could not be solved instantly and correctly — by the developers (by changing the working logic). This sparked curiosity and a desire to tackle the situation through alternative means. Thus, this article came to be.

Problemaatika

About Redis in general

As many know, Redis is a single-threaded database. To be precise, it is in this context when dealing with user data. Since version four, Redis has moved internal operations to parallel execution. However, this change has only affected a small portion of the load, as most operations are related to user data.

Countless opinions have been formed on this topic, but Redis developers stubbornly do not want to implement full parallelism, citing how much it complicates the application and increases overhead costs, as well as introducing more bugs. Their stance is: if you are facing a single-core issue — then you have problems with your application architecture and something needs to change in it. Among users, however, there is also "another camp" — those who have hit a wall with a single core and assert that Redis themselves create a bottleneck. In the case of really high loads — sooner or later — you will inevitably encounter this issue, which imposes significant limitations on the architecture and/or forces complications within it.

I will not evaluate any opinion. Instead, I will share our specific case and how we resolved it.

Our case

Ühes meie projektidest kohtasime olukorda, kus arendustiim seadistas andmebaasi (PostgreSQL) andmete jaoks äärmiselt agressiivse vahemälu (cache) Redis'i kaudu. See oli ainus viis, mille abil teravate liiklusvoogude ajal päästeti PostgreSQL ise ja seega ka rakendus eluga.

Pärast järjestikuseid koormusteste viisime läbi olukorra analüüsi ja avastasime, et Redis töötas ühes tuumas (nagu öeldakse, "puuri sees"), misjärel järgnes üsna kiire rakenduse halvenemine. "Uputamine" toimus geomeetrilise progresiooniga: niipea, kui Redis'i jõudluse limiit saavutati, lakkas kõik olemast.

See nägi välja umbes nii:

New Relici poolt tuvastati probleem üheselt:

Ja siin on statistika operatsiooni get Redis'is:

Pärast seda, kui probleem detaliseeritult arendustiimile edastati, selgus, et "hetkel ei saa probleemi lahendada". Nii algasid lahenduse otsingud halduspoolel ja vastusena leidus juba mainitud KeyDB.

Kuid enne, kui asume selle ülevaate juurde, tasub mainida, et projektis kasutatakse iseseisvat Redis't, kuna klastrilahendus Sentinel'i põhjal on latentsuse osas oluliselt kehvem. Üks ilmne lahendus oleks olnud luua mitu vahemälu koopiat: ja lasta rakendusel liikuda igal pool koormuse tasakaalustamisega! Kuid pärast arendajatega arutlemist pidime selle variandi kõrvale heitma arvestades rakenduse aktiivset ja keerukat vahemälu kehtetuks kuulutamise mehhanismi. Sama probleem ulatus ka vahemälu jagamisele.

KeyDB kiire ülevaade

Otsides võimalikke lahendusi probleemile, avastasime rakenduse nimega KeyDB. See on Redis'e fork, mille on arendanud Kanada ettevõtte ja see on vabalt levitatav BSD litsentsi alusel. Projekt on üsna noor: see on eksisteerinud alates 2019. aastast. Selle ajalugu on selline, et autorid kohtasid omal ajal ka Redis'i piiranguid... ja otsustasid teha oma forki. Ning see ei lahendanud mitte ainult tuntud probleeme, vaid omandas ka lisafunktsioone, mis on saadaval ainult Redis'e ettevõtteversioonis.

Neile, kes soovivad rohkem teada saada KeyDB-st, on olemas hea alustav artikkel Medium'is, mis tutvustab andmebaasi ja lühikesi benchmark'e, mis võrdlevad seda selle "vanemaga" — Redis'iga.

Esiteks köitis meid KeyDB potentsiaalne lahendus meie probleemidele, samuti huvitusid meid mõned lisafunktsioonid. KeyDB kasutamine lubas järgmisi eeliseid:

• täisväärtuslik multithreading;
• täielik ja absoluutne ühilduvus Redisiga (meie jaoks oli see eriti oluline, kuna rakenduse poolel mingeid kohandusi teha ei olnud võimalik), mis tõotas ka probleemideta migratsiooni;
• sisseehitatud varundusmehhanism S3 salvestusse;
• lihtne rakendada active-replikatsioon;
• lihtne klasterdamine ja sharding ilma Sentinel'i ja muu abivahendita.

Rohkem kui 3000 tähte ja palju koostööpartnereid GitHubis nägid samuti lootustandvad välja. Rakendus arendatakse ja toetatakse aktiivselt, mida on hästi näha commit'ide, suhtluse issues ja samuti suletud (aktsepteeritud) PR-idest. Põhihalduri tagasiside on alati sõbralik ja kiire. Üldiselt oli argumente piisavalt.

Migratsioon ja tulemused

Kuigi migratsiooniprojekt oli omamoodi riskialti ettevõtmine (KDB uudsuse tõttu), ei olnud meil eriti midagi kaotada. Lõppude lõpuks oli muudatusi üsna lihtne ja kiire tagasi tagasi rullida — kuna kogu infrastruktuur on üles ehitatud Kuberneteses ning sisseehitatud mehhanismid Rolling Update lahendavad sellised ülesanded suurepäraselt.

Valmistame ette Helm-malle, lülitasime rakenduse testkeskkonnas uuele andmebaasile ja viisime kõik välja, andes üle kliendi QA-osakonnale.

Alustati testimist, mis kestis umbes nädal ja mille detailidesse me ei süvenenud. Meile on teada, et klient testis Redisiga töötamiseks standardseid funktsioone PHP draiveri phpredis, samuti viis läbi kasutajaliidese QA testimise. Pärast seda anti meile roheline tuli: uusi tarkvarasid kasutades ei leitud mingeid kõrvaltoimeid. Nii et rakenduse seisukohalt ei ole üldse midagi muutunud.

Tuleb märkida, et ka konfiguratsioonis me midagi ei muutnud: lihtsalt — asendasime kasutatava pildi. Sama kehtib ka monitorimise ja metrikate ekspordi kohta Prometheuses: kõige levinum neist töötas suurepäraselt KeyDB-ga ja ilma igasuguste täiendusteta. Seega võib julgelt öelda, et ka töökeskkonna seisukohalt on see lihtsalt ideaalne üleminek.

Tänu sellele saab rakendust uue andmebaasi süsteemi (SUS) korralikku tööle jätta ilma muudatusteta, ning kui soovite seda kasutada "stabiliseerimise meetmena", võite jätta selle selliseks ja lasta tal mõnda aega tootmisrežiimis töötada. Siiski, kui soovite näha jõudluse paranemist (või üldse mingeid muudatusi), tuleb meeles pidada, et vaikimisi KeyDB parameeter, mis vastutab mitme lõime eest (server-threads), on üks, mis tähendab, et SUS töötab täpselt samamoodi nagu Redis..

Pärast üleminekut, testimist ja teatud aega uue rakendusega (KeyDB) otsustasime korrata koormustestimist samade parameetritega, mida kasutati Redis’e jaoks. Millised olid tulemused?..

CPU tarbimise graafikult oli kohe näha, et probleem "ühe tuuma lae" elimineerimisega on lahendatud: protsess hakkas kasutama saadaval olevaid ressursse:

Ja hiljem proovisin ma rakendust üsna intensiivselt "piinata" ja nägin tarbimist kuni kolme tuuma ulatuses...

New Relici näitude kohaselt käitus veebirakendus kogu koormuse juures mõistlikumalt. Teatud jõudluse langust siiski täheldati, kuid võrreldes eespool toodud graafikuga saate ise hinnata olulisi edusamme:

Uue andmebaasi (KeyDB) latentsuse näitaja halvenes samuti, kuid jäi vastuvõetavate piiride sisse:

Järgmise graafiku põhjal on hästi näha, et päringute arv KeyDB-s on sarnane:

Kokkuvõtteks nende sünteetiliste testide põhjal võib öelda, et nii Redis kui KeyDB näitavad oluliselt halvenenud jõudlust latentsuses (40 ms+) suure paralleelsete ühenduste arvu (1000+) juures. Meie juhul suutis veebirakendus "langetada" Redis'e latentsust madalama ühenduste arvuga (400+), kuigi KeyDB selline koormus jääb endiselt vastuvõetavaks.

Järeldused

Antud näites on selgelt näha Open Source kogukonna jõud projektide arengus, milles see on huvitatud. Internetis olen kohanud suurepärast väidet, mille üldine mõte oli järgmine: "Mõni suur ettevõte loob huvitava toote, teeb osa selle funktsioone avatuks, kuid kõige olulisema osa jätab tasuliseks. Kogukond kasutab ja kasutab, kuni keegi ei viitsi enam ning teeb fork'i, rakendades seal need tasulised funktsioonid ja avades need kõigile." Siin on KeyDB - see on täpselt see juhtum.

Rääkides aga ise migreerimisest, mis toimus üllatavalt lihtsalt, ei saanud me niivõrd olulist jõudluse kasvu, mida oleks oodata autori KeyDB graafikute vaatamise põhjal... Siiski, see on vaid meie erijuhtum, kus võib olla palju kõrvalekaldeid, sealhulgas kurikuulus rakenduse arhitektuur (näiteks tohutult palju käske get Redis, mitte rohkem jõudlusele suunatud kogutud päringute variandi juures mget…). Siiski, positiivsete tulemuste saavutamine õnnestus ning koos nendega - palju kasulikke funktsioone, mida me alles kavandame lähitulevikus rakendada.

Üldiselt paistab KeyDB lubav: praktilise kogemuse saamisel selle andmebaasi kasutamisel (mida peab veel omandama!) ja projekti arendamise käigus kaalume selle rakendamise võimalust ka teistes olukordades.

Kuid seda artiklit ei peaks pidama juhendiks (ja veel vähem - kutseks) tegevusele Redisest KeyDB-le ülemineku osas. Vaatamata meie positiivsele kokemusele on selge, et see ei ole hõbepadrun. Juhtum oli väga spetsiifiline: konkreetselt kiire lahenduse leidmiseks olukorras, kus tuli toimida kiiresti ja minimaalsete kuludega, õigustas see lahendust. Kas KeyDB on teie puhul kasulik? Igatahes te now, et see potentsiaalne võimalus olemas on.

P.S.

Lugege ka meie blogist:

• «Andmebaasid ja Kubernetes (ülevaade ja video ettekandest)»;
• «Cassandra migratsioon Kubernetesesse: eripärad ja lahendused»;
• «Aeganõudev MongoDB migreerimine Kubernetesesse»;
• «Kompleksne RabbitMQ migratsioon Kubernetesesse».

Allikas: habr.com