KeyDB kui [potentsiaalne] asendus Redis jaoks

Habrast ei leidunud ülevaateid "kiirematest Redis alternatiividest" — KeyDB. Saades piisavalt värsket kogemust selle kasutamisest, soovin selle puuduse täita.

Eellugu on piisavalt banaalne: ühel päeval, kui liiklus oli suur, fikseeriti rakenduse tõhususe märkimisväärne halvenemine (täpsemalt — vastamise aega). Sel ajal ei õnnestunud kahjuks probleemi korralikult diagnoosida, seega planeerisime hiljem mitmeid koormusteste. Pärast nende läbiviimist suudeti leida kitsaskoht, mis osutus Redis'i andmebaasi vahemikuks. Nagu sageli juhtub, ei saanud probleemi lahendada kohe ja õigesti — arendajate abiga (töölogika muutmise teel). Seetõttu tekkis uudishimu ja soov olukorda ringi ajada. Nii see artikkel sündis.

Probleemistik

Redis'ist üldiselt

Nagu paljudele teada, on Redis ühesuunaline andmebaas. Täpsemalt öeldes on see selline kasutajate andmetega töötamise kontekstis. Alates neljandast versioonist on teenuslikud, sisemised Redis toimingud tõlgitud paralleelselt töötamiseks. Siiski puudutas see muudatus vaid vähest koormust, kuna peamine töö koondub kasutajate andmetele.

Sellel teemal on rikutud lugematul hulgal koopiaid, kuid Redis arendajad ei soovi kategooriliselt täisparalleelsust rakendada, tuues esile, kui keeruliseks see rakendust muudab ja kui palju toob kaasa üleliigseid kulusid ning vigade arvu kasvu. Nende seisukoht on, et kui te leiate, et teil on ühe tuuma probleem — siis probleem on rakenduse arhitektuuris ja peate seda muutma. Siiski on olemas ka 'teine leer' — need, kes on korduvate ühe tuuma probleemide juures ja väidavad, et Redis loob endale pudelikaelad. Reaalselt suurte koormuste korral — varem või hiljem — tuleb selle probleemiga kokku puutuda, mis seab tohutuid piiranguid arhitektuurile ja/või sunnib selle keerukust suurendama.

Ei hakka hindama ühtegi arvamust. Selle asemel jagan meie konkreetset juhtumit ja seda, kuidas me selle lahendasime.

Meie juhtum

Üks meie projektidest seisis silmitsi olukorraga, kus arendusmeeskond seadistas äärmiselt agressiivse andmete vahemälestamise PostgreSQL-ist Redis'i kaudu. See oli ainus viis, mis äkiliste liiklusrünnakute ajal päästis PostgreSQL-i surmast ja seega ka rakenduse.

Pärast rida koormusteste tegime olukorra analüüsi ja avastasime, et Redis jõudis ühe tuumani (nagu öeldakse, "pulk") ning seejärel järgnes suhteliselt kiire rakenduse halvenemine. „Häda“ toimus geomeetrilise progresiooniga: niipea, kui Redis jõudis jõudluse piiri, lakkas kõik toimimast.

See nägi välja umbes nii:

New Relicu poolt tuvastati probleem üheselt:

Aga siin on statistika operaatsiooni get Redises:

Pärast seda, kui probleem arendusteamile üksikasjalikult edastati, selgus, et "praegu probleemi lahendada ei saa". Nii algasid lahenduse otsingud opereerimise poolel, mille vastuseks sai juba mainitud KeyDB.

Kuid enne, kui asume selle ülevaate juurde, on oluline mainida, et projektis kasutatakse standalone Redis'i, kuna klasterpõhine lahendus Sentinel'i peal on oluliselt suuremate latentsustega. Üks ilmne lahendus oleks olnud luua mitu vahemälu koopiat: ja lasta rakendusel igal pool ringi minna tasakaalustamisega! Siiski, arendajatega konsulteerides olime sunnitud selle variandi loobuma, kuna rakendusel on aktiivne ja keeruline vahemälu tühistamise mehhanism. Sama probleem kehtis ka vahemälu jagamise kohta.

Kiire ülevaade KeyDB-st

Otsides võimalikke lahendusi probleemile, avastasime rakenduse nimega KeyDB. See on Redis'i fork, mille on välja töötanud Kanada ettevõte ja mida jagatakse BSD vaba litsentsi alusel. Projekt on üsna noor: see on eksisteerinud alates 2019. aastast. Selle ajaloo kohaselt on autorid samuti kunagi kokku puutunud Redis'i piirangutega... ja otsustasid teha oma forki. Ja see ei lahendanud mitte ainult tuntud probleeme, vaid sai ka lisa omadusi, mis on saadaval ainult Redis'i ettevõtte versioonis.

Need, kes soovivad KeyDB-st rohkem teada saada, saavad lugeda head sissejuhatavat artiklit Mediumis, mis esindab andmebaasi ja lühikesi benchmark'e, võrreldes seda oma «vanemaga» — Redis.

Esiteks, meid tõi KeyDB potentsiaalne lahendus meie probleemidele ning olid huvitavad ka mõned lisafunktsioonid. KeyDB kasutamine lubas järgmisi eeliseid:

• täielik mitme protsessi tugi;
• täielik ja absoluutne ühilduvus Redis'iga (meie jaoks oli see eriti oluline, sest rakenduse poolt muudatuste tegemine polnud võimalik), mis lubas ka probleemideta migratsiooni;
• sisseehitatud varundamismehhanism S3-hoidlas;
• lihtne rakendada aktiivne replikatsioon;
• lihtne rühmamine ja jaotamine ilma Sentinel'i ja muu abiprogrammita.

Rohkem kui 3000 tähte ja palju kaastöötajaid GitHub'is nägid samuti lootustandvad välja. Rakendus areneb ja toetatakse piisavalt aktiivselt, mida on hästi märgata commit'ide, probleemide arutelude ja suletud (vastu võetud) PR'ide põhjal. Peamine hooldaja reageerib alati kõikidel rindel sõbralikult ja kiiresti. Üldiselt osutus argumente olevat küllaga.

Migratsioon ja tulemused

Kuigi migratsiooniprojekt oli omamoodi seiklus (tänu KeyDB uudsusele), polnud meil tegelikult midagi kaotada. Muudatuste tagasivõtmine on piisavalt kiire ja lihtne — õnneks on kogu infrastruktuur üles seatud Kuberneteses ning sisseehitatud mehhanismid Rolling Update lahendavad sellised ülesanded suurepäraselt.

Kokkuvõttes valmisime Helm-mallid, lülitasime rakenduse testkeskkonnas uuele andmebaasile ja tõime selle kõik välja, et anda QA-osakonnale kliendi kätte.

Algas testimine, mis kestis umbes nädala ja mille detailidesse me ei süüvinud. Meil on teada vaid, et tellija kontrollis Redis'e põhifunktsioone PHP-draiveri abil phpredis, samuti teostas kasutajaliidese QA-testimist. Pärast seda sai meilt roheline tuli: uusi tarkvara kasutamisel ei leitud mingeid kõrvaltoimeid. See tähendab, et rakenduse seisukohalt ei muutunud üldse midagi.

Tasub mainida, et me ei teinud ka konfiguratsioonis mingeid muudatusi: lihtsalt — vahetasime kasutatava pildi. Sama kehtib ka jälgimise ja metrikate eksportimise kohta Prometheuses: kõige levinum neist töötab suurepäraselt KeyDB-ga ilma igasuguste muudatusteta. Seega võib rahulikult öelda, et ka kasutusmugavuse seisukohalt on see ideaalne üleminek.

Kõige selle tõttu, pärast rakenduse suunamist uuele andmebaasitarkvarale ei pea midagi muutma ja stabiliseerimise meetmena võib jätta selle kujul töötama mingiks ajaks. Siiski, kui soovite näha jõudluse kasvu (või vähemalt mingit muutust), ärge unustage, et vaikimisi KeyDB parameeter, mis vastutab mitme lõime eest (server-threads), on võrdne ühega, st andmebaas töötab täpselt nagu Redis..

Pärast üleminekut, testimist ja mõningast elu uut rakendust (KeyDB-ga) otsustasime korrata koormustestimist samade parameetritega, mida kasutati Redis'e jaoks. Millised olid selle tulemused?..

CPU tarbimise graafikul oli kohe nähtav ühte tuuma ‘lae’ probleemide kõrvaldamine: protsess hakkas kasutama saadaval olevaid ressursse:

Hiljem proovisin üsna korralikult rakendust ‘piinata’ ja nägin tarbimist kuni kolme tuumani...

New Relici andmete kohaselt käitub veebirakendus kokkuvõttes, olles sama koormuse all, märgatavalt paremini. Mõningast jõudluse halvenemist siiski täheldati, kuid võrreldes ülaltoodud sarnase graafikuga, võite ise hinnata olulist edusammu:

Uue andmebaasi (KeyDB) latentsus on samuti halvenenud, kuid jäi lubatavate väärtuste piiridesse:

Järgmise graafiku põhjal on selgelt näha, et päringute arv KeyDB-le on sarnane:

Kokkuvõttes nende sünteetiliste testide põhjal võib öelda, et nii Redis kui ka KeyDB näitavad märkimisväärset jõudluse halvenemist latentsuse osas (40 ms+) koos oluliselt suureneva paralleelsete ühenduste arvuga (1000+). Meie juhul suudeti veebirakendusel Redis'i latentsust madalamana hoida isegi väiksema ühenduste arvuga (400+), kuigi KeyDB jaoks jäi selline koormus vastuvõetavaks.

Järeldused

Selles näites on suurepäraselt näha Open Source’i kogukonna mõju projektide arengus, milles nad on huvitatud. Internetis olen kohanud toredat ütlust, mille peamine mõte oli järgmine: „Mõni suur ettevõte loob huvitava toote, avab osa selle funktsioonidest, kuid jätab kõige olulisema osa tasuliseks. Kogukond kasutab seda, kuni keegi loob fork'i, rakendades seal need tasulised funktsioonid ja avades need kõigile.” Just niimoodi on KeyDB — see on selline juhtum.

Mis puutub aga migratsiooni, siis see läks üllatavalt lihtsalt ja me ei saanud nii suurt tõusu jõudluses, nagu oleks oodata, vaadates KeyDB autorite graafikuid... Siiski on see vaid meie erijuhtum, kus võivad esineda mitmed kõrvalekalded, sealhulgas ka kurikuulus rakenduse arhitektuur (näiteks tohutu hulk käske get Redis’s, selle asemel, et kasutada paremat aggregeeritud päringute varianti mget…Küll aga on õnnestunud saavutada positiivseid tulemusi, koos nendega ka hulk kasulikke funktsioone, mida me plaanime lähitulevikus rakendada.

Üldiselt näeb KeyDB välja lubav: kui saame praktiseerida selle andmebaasi kasutamist (mida on veel ees!) ning arendada ise projekti, vaatame võimalust selle rakendamiseks ka teistes olukordades.

Kuid ärge käsitage seda artiklit juhisena (veel vähem kutse tegevusele) Redis'i täielikuks loobumiseks KeyDB kasuks. Hoolimata meie positiivsest kogemusest on selge, et see ei ole hõbedane kuul. Juhtum oli väga spetsiifiline: antud juhul, kus lahendus oli vajalik kiiresti ja minimaalseid kulusid silmas pidades, õigustas see ennast. Kas KeyDB on teie puhul kasulik? Vähemalt teate nüüd, et selline potentsiaalne võimalus eksisteerib.

P.S.

Lugege ka meie blogist:

• «Andmebaasid ja Kubernetes (ülevaade ja video ettekandest)»;
• «Cassandra migreerimine Kubernetesesse: eripärad ja lahendused»;
• «Ilma tõrgeteta MongoDB migratsioon Kubernetesesse.»;
• «Ainulaadne RabbitMQ migreerimine Kubernetesesse».

Allikas: habr.com