NĂ« HabrĂ« nuk u gjetĂ«n rishikime tĂ« "alternativĂ«s mĂ« tĂ« shpejtĂ« tĂ« Redis" â . Pas pĂ«rvojĂ«s sĂ« mjaftueshme tĂ« pĂ«rdorimit tĂ« tij, dĂ«shiroj tĂ« plotĂ«soj kĂ«tĂ« boshllĂ«k.
![KeyDB si [zëvendësuese potenciale] për Redis](/wp-content/uploads/2020/02/9642ef3dc712ad2e6304104facb464b7.jpeg)
E kaluara Ă«shtĂ« mjaft e zakonshme: njĂ« herĂ«, me njĂ« fluks tĂ« madh trafiku, u vĂ«rejt njĂ« degradim tĂ« konsiderueshĂ«m tĂ« performancĂ«s sĂ« aplikacionit (pikĂ«risht â kohĂ«n e pĂ«rgjigjes). NĂ« atĂ« moment, fatkeqĂ«sisht, nuk arritĂ«m tĂ« kryejmĂ« njĂ« diagnostikim tĂ« duhur tĂ« asaj qĂ« po ndodhte, prandaj mĂ« pas planifikuam njĂ« sĂ«rĂ« testimesh tĂ« ngarkesĂ«s. Pas kryerjes sĂ« tyre, arritĂ«m tĂ« zbulojmĂ« pikĂ«n e ngushtĂ«, e cila ishte cache i bazĂ«s sĂ« tĂ« dhĂ«nave nĂ« Redis. Ashtu siç ndodh shpesh, problemi nuk mund tĂ« ishte zgjidhur nĂ« atĂ« moment dhe nĂ« mĂ«nyrĂ«n e duhur â me forcat e zhvilluesve (duke ndryshuar logjikĂ«n e punĂ«s). Prandaj, kureshtja dhe dĂ«shira pĂ«r tĂ« luftuar situatĂ«n pĂ«rmes njĂ« rruge alternative u aktivizuan. KĂ«shtu lindi ky artikull.
Problematika
Për Redis në përgjithësi
Siç e dinë shumë, Redis është një bazë të dhënash me një thread. Nëse duhet të jemi më të saktë, është e tillë në kontekstin e punës me të dhëna përdoruesish. Në fakt, që nga versioni i katërt, operacionet e brendshme dhe shërbimi të Redis kanë kaluar në ekzekutimin paralel. Megjithatë, ky ndryshim preku vetëm një pjesë të vogël të ngarkesës, për shkak se puna kryesore përqendrohet te të dhënat e përdoruesve.
PĂ«r kĂ«tĂ« temĂ« janĂ« thyer njĂ« numĂ«r i pafund kopjesh, por zhvilluesit e Redis me insistim nuk duan tĂ« implementojnĂ« njĂ« paralelizĂ«m tĂ« plotĂ«, duke theksuar sa e komplikuar do ta bĂ«nte aplikacionin dhe do tĂ« rritnin kostot, si dhe do tĂ« shtonin numrin e defekteve. QĂ«ndrimi i tyre Ă«shtĂ« se nĂ«se e hasni problemin e njĂ« bĂ«rthame â keni probleme me arkitekturĂ«n e aplikacionit dhe diçka duhet tĂ« ndryshohet nĂ« tĂ«. MegjithatĂ«, nĂ« mesin e pĂ«rdoruesve, ekziston edhe njĂ« "kamp tjetĂ«r" â nga ata qĂ« janĂ« pĂ«rballur me njĂ« bĂ«rthamĂ« dhe pretendojnĂ« se vetĂ« Redis krijojnĂ« njĂ« ngushticĂ«. NĂ« rastin e ngarkesave tĂ« mĂ«dha â herĂ«t apo vonĂ« â pĂ«rballja me kĂ«tĂ« problem Ă«shtĂ« e pashmangshme, gjĂ« qĂ« imponon kufizime tĂ« rĂ«ndĂ«sishme nĂ« arkitekturĂ« dhe/ose komplikime tĂ« detyruar nĂ« tĂ«.
Nuk do të jap një vlerësim për mendimin e ndonjë secili. Në vend të kësaj, do të ndaj rastin tonë të saktë dhe se si e zgjodhëm atë.
Rasti ynë
Në një nga projektet tona, u përballëm me faktin që ekipi i zhvillimit kishte konfiguruar një caching jashtëzakonisht agresiv të të dhënave nga baza e të dhënave (PostgreSQL) përmes Redis. Ky ishte rruga e vetme që gjatë fluksve të papritura të trafikut shpëtonte PostgreSQL-në nga vdekja dhe, si pasojë, aplikacionin.
Pas një serie testesh ngarkese, ne kryem një analizë të situatës dhe zbuluam se Redis po mbështetej në një bërthamë (siç quhet, "në raft"), pas së cilës pasonte një degradim mjaft i shpejtë i aplikacionit. "Asfiksimi" kishte një progresion gjeometrik: sapo arrihej kufiri i performancës së Redis, gjithçka ndalonte së funksionuari.
It looked something like this:
![KeyDB si [zëvendësuese potenciale] për Redis](/wp-content/uploads/2020/02/c0f55ca1d9f28f8c305bb74cdc77a84a.jpeg)
Nga ana e New Relic, problemi identifikohej qartë:
![KeyDB si [zëvendësuese potenciale] për Redis](/wp-content/uploads/2020/02/ce72e290f84560d143f2d6c128358477.jpeg)
Dhe ja statistika për operacionin merr në Redis:
![KeyDB si [zëvendësuese potenciale] për Redis](/wp-content/uploads/2020/02/31d98a6bb2985cfbe391976e24b8a8a6.jpeg)
Pas transmetimit të problemit me të gjitha detajet te ekipi i zhvillimit, doli se "nuk mund të zgjidhet problemi tani për tani". Kështu filluan kërkimet për një zgjidhje nga anët e operacionit, dhe përgjigjja ishte KeyDB, e përmendur më parë.
Megjithatë, para se të fillonim shqyrtimin e saj, duhet të përmendim se në projekt përdoret Redis standalone, pasi zgjidhja e klasterit mbi bazën e Sentinel-i është shumë inferiore në vonesa (latency). Një nga zgjidhjet e dukshme ishte krijimi i disa replika të caches: dhe le të shkojë aplikacioni kudo me balancim! Megjithatë, pas një diskutimi me zhvilluesit, u detyruam ta heqim këtë variant për shkak të mekanizmit aktiv dhe të komplikuar të invalidimit të caches në aplikacion. Të njëjtin problem kishte edhe sharding-un e caches.
Një shqyrtim i shpejtë i KeyDB
Në kërkim të një zgjidhjeje potenciale për problemin, ne zbuluam . Ky është një fork i Redis, i zhvilluar nga dhe shpërndahet nën licencë të lirë BSD. Projekti është mjaft i ri: ai egziston që nga fillimi i vitit 2019. Historia e tij është e tillë, që autorët gjithashtu një herë u përballën me kufizimet e Redis dhe vendosën të bëjnë fork-un e tyre. Në fakt, ai jo vetëm që zgjidhi problemet e njohura, por gjithashtu fitoi mundësi shtesë, të cilat janë të disponueshme vetëm në versionin enterprise të Redis.
PĂ«r ata qĂ« dĂ«shirojnĂ« tĂ« njohin nĂ« detaje KeyDB, ka njĂ« , i cili paraqet DBMS dhe benchmark tĂ« shkurtra, qĂ« e krahasojnĂ« atĂ« me "prindin" e tij â Redis.
Para fill, na KeyDB na tërheqëm zgjidhjen potenciale për problemet tona, njëkohësisht ishin tërheqëse edhe disa funksionalitete shtesë. Përdorimi i KeyDB premtonte përfitime të mëposhtme:
- marrjen e një shumëllojshmërie të plotë në shumë procese;
- përputhshmëri e plotë dhe e absolutë me Redis (për ne kjo ishte sidomos e rëndësishme, pasi nuk ishte e mundur të bënim ndonjë modifikim nga ana e aplikacionit), çka gjithashtu premtonte një migrim të pa probleme;
- mekanizmi i integruar i backup në magazinën S3;
- replikimi aktiv i thjeshtë për tu implementuar;
- klasterizimi dhe sharding i thjeshtë pa Sentinel dhe softuer të ndihmës.
Më shumë se 3 mijë yje dhe shumë kontribues në GitHub gjithashtu duken premtuese. Aplikacioni zhvillohet dhe mbështetet mjaft aktivisht, gjë që është e dukshme nga komitetet, komunikimi në issues, si dhe PR-të e mbyllura (të pranuara). Pjesëmarrja nga mbajtësi kryesor gjithmonë është miqësore dhe e shpejtë ndaj përgjigjeve. Në përgjithësi, argumentet ishin të mjaftueshme.
Migrimi dhe rezultatet
Edhe pse projekti i migrimit ishte njĂ« aventurĂ« e veçantĂ« (pĂ«r shkak tĂ« novitetit tĂ« KeyDB), nuk kishim shumĂ« pĂ«r tĂ« humbur. Sepse rikthimi i ndryshimeve Ă«shtĂ« mjaft i shpejtĂ« dhe i lehtĂ« â falĂ«, tĂ« gjithĂ« infrastruktura e ndĂ«rtuar nĂ« Kubernetes, dhe mekanizmat e integruar zgjidhin mjaft mirĂ« kĂ«to detyra.
Në përgjithësi, kemi përgatitur shabllonët Helm, kemi kalur aplikacionin në mjedisin e testimit në bazën e dhënash të re dhe e kemi lançuar këtë gjithçka, duke ia dorëzuar departamentit të QA të klientit.
Filloi testimi, i cili vazhdoi për rreth një javë dhe nuk u thelluam në detaje. Mësojmë vetëm se klienti verifikoi funksionet standarde të punës me Redis duke përdorur driver-in PHP , si dhe realizoi testim të QA për ndërfaqen e përdoruesit. Pas kësaj, na dhanë dritën e gjelbër: nuk u gjetën efekte anësore në përdorimin e softuerit të ri. Kështu që nga pikëpamja e aplikacionit, nuk ka ndryshuar asgjë me të vërtetë.
Duhet theksuar se as nĂ« konfigurim nuk kemi bĂ«rĂ« ndonjĂ« ndryshim: tĂ« vĂ«rtetĂ« â thjesht ndĂ«rruam imazhin e pĂ«rdorur. E njĂ«jta gjĂ« vlen pĂ«r monitorimin dhe eksportimin e metrikeve nĂ« Prometheus: funkcionon shkĂ«lqyeshĂ«m me KeyDB dhe pa ndonjĂ« modifikim. KĂ«shtu, mund tĂ« themi me siguri se nga ana e operimit, kjo Ă«shtĂ« thjesht njĂ« kalim ideal.
Falë gjithë kësaj, pas kalimit të aplikacionit në një DBMS të re, nuk ka nevojë të ndryshoni asgjë, dhe si një "masë stabilizuese" - mund ta lini të funksionojë në atë formë një kohë të caktuar. Megjithatë, nëse dëshironi të shihni një rritje të performancës (ose ndonjë ndryshim tjetër), mos harroni se si parazgjedhje parametri i KeyDB që merret me shumëfjalëshmëri (server-threads), është baraz 1, do të thotë se DBMS funksionon përpikërisht ashtu si Redis..
Pas kalimit, testimit dhe një kohe të caktuar funksionimi të aplikacionit të ri (me KeyDB), ne vendosëm të përsërisim testimin e ngarkesës me të njëjtat parametra që janë përdorur për Redis. Cilat ishin rezultatet e tij?..
Nga grafiku i konsumit të CPU, menjëherë u vërejt eliminimi i problemeve me "tavanin" në një bërthamë: procesi filloi të përdorë burimet e disponueshme.
![KeyDB si [zëvendësuese potenciale] për Redis](/wp-content/uploads/2020/02/8a3a168507ef75a8e1cdf69e1d30d996.jpeg)
Dhe më vonë, provova të "torturoj" mjaftueshëm aplikacionin dhe pashë konsum deri në tre bërthama...
Sipas treguesve të New Relic, aplikacioni web në përgjithësi, duke pasur të njëjtën ngarkesë, dukej ndjeshëm më i përshtatshëm. Disa degradim i performancës ende u vërejt, megjithatë, duke krahasuar me grafikun homolog më lart, mund të vlerësoni vetë përparimin e dukshëm:
![KeyDB si [zëvendësuese potenciale] për Redis](/wp-content/uploads/2020/02/f46bf41bd6b8d190f5117d049ed2dce5.jpeg)
Treguesi i vonesës në bazën e dhënash të re (KeyDB) gjithashtu u përkeqësua, megjithatë mbeti brenda kufijve të pranueshëm:
![KeyDB si [zëvendësuese potenciale] për Redis](/wp-content/uploads/2020/02/b9e0a3103a51707628a9f500dfdd53ad.jpeg)
Nga grafiku i mëposhtëm, është e qartë se numri i kërkesave në vetë KeyDB është i ngjashëm:
![KeyDB si [zëvendësuese potenciale] për Redis](/wp-content/uploads/2020/02/0a067239194adb39eb3c3738fa73860e.jpeg)
Duke përmbledhur këto teste sintetike, mund të themi se si Redis ashtu edhe KeyDB tregojnë një degradim të konsiderueshëm të performancës në latencë (40 ms+) me një rritje të konsiderueshme të numrit të lidhjeve të parallelizuar (1000+). Në rastin tonë, aplikacioni web ishte në gjendje "të ulte" latencën e Redis edhe me një numër më të ulët lidhjesh (400+), edhe pse për KeyDB një ngarkesë e tillë mbeti e pranueshme.
PĂ«rfundimet
Ky këtë shembull duket qartë fuqia e komunitetit Open Source në zhvillimin e projekteve në të cilat është i interesuar. Në hapësirën e internetit kam hasur një citat të shkëlqyer, ku shprehja e përbashkët ishte: "Një kompani e madhe krijon një produkt interesant, bën pjesën e funksioneve të tij të hapura, por pjesën më të rëndësishme e lë me pagesë. Komuniteti përdor, përdor, dhe pastaj dikush merr guximin dhe bën një fork, duke realizuar ato funksione të paguara dhe duke i hapur ato për të gjithë." KeyDB është një rast i tillë.
Duke folur pĂ«r migrimin vetĂ«, i cili kaloi pĂ«r çudi mjaft lehtĂ«, nuk kemi marrĂ« sa shumĂ« rritje tĂ« konsiderueshme nĂ« performancĂ«, sa mund tĂ« pritej duke parĂ« grafikĂ«t e autorĂ«ve tĂ« KeyDB⊠MegjithatĂ«, ky Ă«shtĂ« vetĂ«m rasti ynĂ« i veçantĂ«, nĂ« tĂ« cilin mund tĂ« ketĂ« shumĂ« devijime, duke pĂ«rfshirĂ« edhe arkitekturĂ«n e famshme tĂ« aplikacionit (pĂ«r shembull, numri i madh i komandave merr nĂ« Redis nĂ« vend tĂ« variantit mĂ« tĂ« performuar tĂ« kĂ«rkesave tĂ« agreguara mgetâŠ). MegjithatĂ«, arritĂ«m rezultate pozitive dhe gjithashtu shumĂ« funksione tĂ« dobishme qĂ« ne do t'i implementojmĂ« nĂ« tĂ« ardhmen e afĂ«rt.
Në përgjithësi, KeyDB duket premtues: me përmirësimin e përvojës praktike të punës me këtë SGBD (dhe ky proces ende na pret!) dhe zhvillimin e vetë projektit, ne do të shqyrtojmë mundësinë e përdorimit të tij edhe në situata të tjera.
MegjithatĂ«, nuk duhet ta konsideroni kĂ«tĂ« artikull si njĂ« udhĂ«zues (dhe aq mĂ« shumĂ« â si njĂ« thirrje) pĂ«r t'u hequr nga Redis nĂ« favor tĂ« KeyDB. PavarĂ«sisht nga pĂ«rvoja jonĂ« pozitive, Ă«shtĂ« e qartĂ« se ky nuk Ă«shtĂ« njĂ« plumb argjendi. Rasti ishte mjaft specifik: konkretisht pĂ«r zgjidhjen e njĂ« problemi tĂ« menjĂ«hershĂ«m nĂ« njĂ« situatĂ« kur duhej ta bĂ«nim kĂ«tĂ« shpejt dhe me kosto minimale, kjo zgjidhje u justifikua. A do tĂ« jetĂ« e dobishme KeyDB nĂ« rastin tuaj? TĂ« paktĂ«n tani e dini se njĂ« mundĂ«si e tillĂ« ekziston.
P.S.
Lexoni gjithashtu në blogun tonë:
- «»;
- «»;
- «»;
- «».
Burimi: habr.com
