KeyDB si [zëvendësim potencial] për Redis

Në Habr nuk u gjetën komente për "alternativën më të shpejtë ndaj Redis" — KeyDB. Pas një përvoje të mjaftueshme të përdorimit të tij, do të doja të plotësoj këtë boshllëk.

Historia është mjaft e zakonshme: një herë, në një fluks të madh trafiku, u vërejt një degradim të konsiderueshëm të performances së aplikacionit (pikërisht — kohës së përgjigjes). Në atë kohë, fatkeqësisht, nuk uda të realizohej një diagnostikim normal i situatës, prandaj më vonë u planifikuan një sërë testesh ngarkese. Pas zhvillimit të tyre, u zbulua ngushtica, e cila ishte cache i bazës së të dhënave në Redis. Ashtu siç ndodh shpesh, problemi nuk mund të zgjidhej menjëherë dhe në mënyrën e duhur — nga zhvilluesit (duke ndryshuar logjikën e funksionimit). Kështu ndodhi që tingujt e kuriozitetit dhe dëshira për të zgjidhur situatën me një qasje alternative u aktivizuan. Kjo është historia e këtij artikulli.

Problematika

Rreth Redis në përgjithësi

Siç dihet, Redis është një bazë të dhënash me një thread. Nëse jemi më të saktë, është e tillë në kontekstin e punës me të dhënat e përdoruesve. Që nga versioni i katërt, operacionet e brendshme të Redis kemi përkthyer kanë përparësi ekzekutimi paralel. Megjithatë, kjo ndryshim ndikoi vetëm në një pjesë të vogël të ngarkesës, pasi puna kryesore bie mbi të dhënat e përdoruesve.

Për këtë temë janë thyer pa fund kopje, por zhvilluesit e Redis nuk duan të implementojnë një paralelizëm të plotë, duke përmendur se sa do ta komplikonte aplikacionin dhe do të rrisë kostot e operimit, si dhe do të sjellë më shumë të meta. Pozita e tyre është kjo: nëse përballeni me një problem të një blloku të vetëm — keni probleme me arkitekturën e aplikacionit dhe duhet të bëni ndryshime aty. Megjithatë, në mesin e përdoruesve, ka edhe "kampin tjetër" — ata që janë ngjitur në një bllok dhe pretendojnë se Redis krijon vetë një ngushticë. Në rastin e ngarkesave të vërteta të mëdha — herët ose vonë — përballja me këtë problem është e pashmangshme, e cila vendos kufij të konsiderueshëm mbi arkitekturën dhe/ose detyron për një kompleksitet të detyrueshëm në të.

Nuk do të jap një vlerësim për këtë apo atë opinion. Në vend të kësaj, do të ndaja rastin tonë konkret dhe se si e zgjidhëm atë.

Rasti ynë

Në një prej projekteve tona, u përballëm me faktin se ekipi i zhvillimit kishte vendosur një cache të dhënash mjaft agresiv nga DB (PostgreSQL) përmes Redis. Ky ishte i vetmi mënyrë, e cila gjatë flukseve të papritura të trafikut shpëtonte PostgreSQL nga vdekja dhe, si pasojë, aplikacionin.

Pas një serie testesh ngarkese, ne analizuam situatën dhe zbuluam se Redis kishte ngecur në një bllok (siç thonë, "në raft"), pas së cilës ndodhi një degradim ndjeshëm i aplikacionit. "Mbytja" kishte një progresion geometrik: sa herë që arrihej kufiri i performancës te Redis, gjithçka ndalej.

Duket kështu:

Nga ana e New Relic, problemi u identifikua qartë:

Dhe këtu është statistika për operacionin merr në Redis:

Pas që problemi u paraqit në të gjitha detajet zhvillimit, doli se "në këtë moment problemi nuk mund të zgjidhej". Kështu filluan kërkimet për një zgjidhje në anën e shfrytëzimit, dhe përgjigja ishte vetë KeyDB.

Megjithatë, para se të fillonim me përmbledhjen e saj, është e rëndësishme të përmendet se në projektin përdoret Redis i vetëzhvilluar, pasi zgjidhja klastra mbi bazën e Sentinel del shumë më e ngadaltë (latencija). Një nga zgjidhjet e duhura ishte krijimi i disa replika të cache-it: dhe le ta përdorë aplikacioni kudo me balancim! Por, pas një diskutimi me zhvilluesit, u detyruam të heqim dorë nga kjo mundësi për shkak të një mekanizmi aktiv dhe kompleks të invalidimit të cache-it në aplikacion. E njëjta problemin ndodhte edhe me sharding-in e cache-it.

Një përmbledhje e shpejtë e KeyDB

Në kërkim të një zgjidhje të mundshme të problemit, ne zbuluam një aplikacion të quajtur KeyDB. Ky është një fork i Redis, i zhvilluar nga një kompani kanadeze dhe i shpërndarë nën licencë të lirë BSD. Projekti është mjaft i ri: ekziston qysh në fillim të vitit 2019. Historia e tij është se autorët ndodhi gjithashtu të përballeshin një herë me kufizimet e Redis… dhe vendosën të bëjnë fork-un e tyre. Për më tepër, ai jo vetëm që zgjodhi problemet e njohura, por gjithashtu fitoi mundësi të tjera, që janë në dispozicion vetëm në versionin enterprise të Redis.

Për ata që dëshirojnë të njohin më shumë rreth KeyDB, ka një artikull të mirë hyrës në Medium, i cili prezanton DB-në dhe benchmark-e të shkurtra, duke e krahasuar me "prindin" e saj — Redis.

Para së gjithash, ajo që na tërhoqi në KeyDB ishte zgjidhja e mundshme e problemeve tona, dhe gjithashtu na interesuan disa funksione të tjera. Përdorimi i KeyDB premtonte këto përfitime:

• marrjen e plotë të shumë-threading;
• kompatibilitet i plotë dhe absolut me Redis (për ne kjo ishte veçanërisht e rëndësishme, pasi nuk ishte e mundur të përdoreshin ndonjë ndryshim nga ana e aplikacionit), gjë që gjithashtu premtonte një migrim pa probleme;
• mekanizmi i ndërtuar i backup-it në ruajtjen S3;
• aktive-replikimi i lehtë në implementim;
• klasterizimi dhe shardimi të thjeshta pa Sentinel dhe softuer tjetër ndihmës.

Më shumë se 3 mijë yje dhe shumë kontribues në GitHub gjithashtu dukej inkurajues. Aplikacioni është duke u zhvilluar dhe mbështetur aktivisht, gjë që është dukshme në komitetet, komunikimin në issue, si dhe PR-të e mbyllura (të pranuara). Risia nga mbajtësi kryesor përgjatë të gjitha fronteve është gjithmonë miqësore dhe e shpejtë. Në përgjithësi, kishte shumë argumente.

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. Së fundmi, rikthimi i ndryshimeve ishte mjaft i shpejtë dhe i lehtë — fatmirësisht, të gjithë infrastruktura është e vendosur në Kubernetes, dhe mekanizmat e ndërtuar Rolling Update zgjidhin shkëlqyeshëm këto detyra.

Në përgjithësi, përgatitëm shabllonët e Helm-it, kaluam aplikacionin në ambientin e testimit në DB-në e re dhe e nxorrëm atë, duke ia dorëzuar departamentit QA të klientit.

Testimi filloi, i cili zgjati rreth një javë dhe ne nuk u thelluam në detaje. E dimë vetëm se klienti kontrolloi funksionet standarde të punës me Redis nëpërmjet mjeteve PHP phpredis, si dhe realizoi testimin e QA të ndërfaqes së përdoruesit. Pas kësaj na dhanë dritën e gjelbër: nuk u zbulua asnjë efekt anësor në përdorimin e softuerit të ri. Pra, nga pika e parë e aplikacionit përveç asgjë nuk ndryshoi..

Vlen të përmendet se as në konfigurim nuk e ndryshuam asgjë: marrë thjesht — zëvendësuam imazhin e përdorur. E njëjta gjë vlen për monitorimin dhe eksportimin e metrikave në Prometheus: më i përhapuri prej tyre punon shkëlqyeshëm me KeyDB pa ndonjë ndryshim të nevojshëm. Prandaj, mund të thuhet me siguri se edhe nga pikëpamja e operimit, ky ishte një kalim ideal.

Falë të gjitha kësaj, pas kalimit të aplikacionit në DB-në e re nuk nevojitet asgjë tjetër, dhe si "masë stabilizuese" — mund ta mbani në këtë formë për të punuar në qarkullim për një kohë. Megjithatë, nëse dëshironi të shihni rritje të performancës (ose ndonjë ndryshim), mos harroni se në mënyrë default parametri i KeyDB, që rregullon shumëfishtë (server-threads), është një, që do të thotë DB punon po ashtu si Redis..

Pas kalimit, testimit dhe një kohe të caktuar të qëndrimit në aplikacionin e ri (me KeyDB) ne vendosëm të përsërisim testimin e ngarkesës me parametrat e njëjtë që ishin përdorur për Redis. Si 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:

Dhe më vonë, përpiqesha mjaft për të "mashtruar" aplikacionin dhe pashë konsum deri në tre bërthama...

Sipas New Relic, aplikacioni web, në tërësi, duke pasur ngarkesë të tillë, filloi të sillet dukshëm më normalisht. Disa degradim në performancë gjithsesi u vërejt, megjithatë, duke e krahasuar me grafikun përkatës të mësipërm, mund të vlerësoni përparimin e rëndësishëm:

Të dhënat e vonesës së bazës së dhënave të re (KeyDB) gjithashtu u përkeqësuan, megjithatë mbetën brenda kufijve të pranueshëm:

Nga grafiku i mëposhtëm është e qartë se numri i kërkesave në vetë KeyDB është i ngjashëm:

Duke përfunduar në lidhje me këto teste sintetike, mund të themi se si Redis dhe KeyDB tregojnë një degradim të rëndësishëm në performancën e vonesave (40 ms+) me një rritje të konsiderueshme të numrit të lidhjeve paralel (1000+). Në rastin tonë, aplikacioni web arriti të "dëmtonte" vonesën e Redis dhe me një numër më të ulët lidhjesh (400+), megjithatë për KeyDB, një ngarkesë e tillë mbeti e pranueshme.

Përfundimet

Në këtë shembull duket qartë fuqia e komunitetit Open Source në zhvillimin e projekteve, për të cilat ai është i interesuar. Në hapësirat e internetit kam hasur një thënie të shkëlqyer, ku në përgjithësi nënkuptohej se: "Një kompani e madhe krijon një produkt interesant, bën një pjesë të funksioneve të saj të hapur, por pjesën më të rëndësishme e lë të paguar. Komuniteti përdor, përdor, pastaj dikush e lë një dorë dhe bën një fork, duke realizuar në të ato funksione të paguara dhe duke i hapur ato për të gjithë." Kështu që KeyDB është rasti i tillë.

Dhe duke folur për migrimin, i cili kaloi e gjitha për habi thjesht, nuk morëm aq sa një rritje domethënëse në performancë, e cila mund të pritet kur shikoni grafikun e autorëve të KeyDB... Megjithatë, kjo është thjesht rastin ynë të veçantë, në të cilin mund të ketë shumë variacione, duke përfshirë edhe famin e arkitekturës së aplikacionit (p.sh., një numër të madh komandash merr në Redis në vend të një varianti më produktiv të kërkesave të agreguara mget…). Megjithatë, është arritur të kemi rezultate pozitive, dhe së bashku me to - shumë funksione të dobishme që ne do t'i implementojmë në të ardhmen e afërt.

Në përgjithësi, KeyDB duket premtues: ndërsa po fiton përvojë praktike me këtë DBMS (të cilën ende duhet ta grumbullojmë!) dhe zhvillimin e vet projekti, ne do të shqyrtojmë mundësinë e përdorimit të tij edhe në situata të tjera.

Megjithatë, nuk duhet ta shihni këtë artikull si një udhëzues (dhe aq më tepër - si një thirrje) për të hequr dorë nga Redis në favor të KeyDB. Pavarësisht përvojës sonë pozitive, është e qartë se kjo nuk është një plumb argjendi. Rasti ishte mjaft specifik: konkretisht për të zgjidhur një problem të menjëhershëm në një situatë ku duhej të bëhej shpejt dhe me shpenzime minimale, kjo zgjidhje u justifikua. A do të jetë KeyDB i dobishëm në rastin tuaj? Të paktën, tani e dini se një mundësi e tillë ekziston.

P.S.

Lexoni gjithashtu në blogun tonë:

• «Baza të dhënash dhe Kubernetes (përmbledhje dhe video e prezantimit)»;
• «Migrimi i Cassandra në Kubernetes: veçoritë dhe zgjidhjet»;
• «Migrimi i thjeshtë i MongoDB në Kubernetes»;
• «Migrimi i papërmbajtshëm i RabbitMQ në Kubernetes».

Burimi: habr.com