KeyDB Redis-ren ordezko [potentzial] gisa

Ez zegoen Habré-n "Redis alternatiba azkarrago" baten berrikuspenik - KeyDB. Erabiltzeko esperientzia berri samarra lortuta, hutsune hori bete nahiko nuke.

Aurrekariak nahiko hutsalak dira: egun batean, trafiko ugarirekin, aplikazioaren errendimenduan (hots, erantzun denboran) degradazio nabarmena erregistratu zen. Garai hartan, tamalez, ezin izan zen gertatzen ari zenaren diagnostiko normal bat egin, eta, beraz, karga-proba batzuk aurreikusi ziren gero. Horiek egin ondoren, botila-lepo bat aurkitu ahal izan genuen, hau da, Redis-en datu-basearen cachea zen. Askotan gertatzen den bezala, arazoa ezin izan da berehala eta modu egokian konpondu - garatzaileek (lanaren logika aldatuz). Hori dela eta, jakin-mina eta egoera modu borobil batean gainditzeko gogoa piztu ziren. Honela agertu da artikulu hau.

Gaiak

Redisi buruz, oro har

Jende askok dakienez, Redis hari bakarreko datu-base bat da. Zehatzago esateko, horrela gertatzen da erabiltzailearen datuekin lan egiteko testuinguruan. Azken finean, laugarren bertsiotik, zerbitzua, Redis-en barne-eragiketak itzulita exekuzio paralelorako. Dena den, aldaketa honek lan-kargaren zati txiki batean bakarrik eragin zuen, lanaren zatirik handiena erabiltzailearen datuetan egiten baita.

Gai honen inguruan hainbat kopia hautsi dira, baina Redis-eko garatzaileek paralelismo osoa ezartzeari uko egiten diote burugogor, aplikazioa zenbat zaildu eta kostu orokorrak handituko dituen aipatuz, baita akats gehiago gehituko ere. Hauen jarrera hau da: nukleo bakarreko arazo baten aurrean bazaude, aplikazioen arkitekturarekin arazoak dituzu eta bertan zerbait aldatu behar da. Erabiltzaileen artean, ordea, "beste kanpamentu bat" ere badago: nukleo batean itsatsita daudenak eta Redis bere buruari botila-lepo bat sortzen ari zaiola diote. Benetan zama handien kasuan -lehenago edo beranduago- ezinbestekoa da arazo honekin topatzea, arkitekturan murrizketa handiak eta/edo behartutako konplikazioak ezartzen dituena.

Ez dut iritzi hau edo beste baloratuko. Horren ordez, gure kasu zehatza eta nola konpondu genuen partekatuko dut.

Gure kasua

Proiektuetako batean, garapen-taldeak datu-baseko (PostgreSQL) datuen cache oso oldarkorra konfiguratu zuela Redis bidez aurkitu genuen. Hau izan zen, bat-bateko trafiko-fluxuetan, PostgreSQL bera eta, ondorioz, aplikazioa heriotzatik salbatu zuen modu bakarra.

Karga-proba batzuen ondoren, egoera aztertu genuen eta Redis nukleo batera mugatuta zegoela ikusi genuen («apala» deitzen dena), eta ondoren aplikazioa nahiko azkar degradatu zen. "Itostea" esponentziala izan zen: Redis-en errendimendu mugara iritsi bezain laster, dena gelditu zen funtzionatzea.

Honelako zerbait zirudien:

New Relic-ek argi eta garbi identifikatu zuen arazoa:

Hona hemen operazioaren estatistikak: get Redis-en:

Garapen-taldeari arazoa zehatz-mehatz jakinarazi ondoren, "arazoa ezin dela konpondu oraintxe" ondorioztatu zen. Horrela, operazioen aldetik irtenbide baten bilaketa hasi zen, eta lehen aipatutako KeyDB izan zen erantzuna.

Hala ere, gure berrikuspena hasi aurretik, aipatzekoa da proiektuak Redis autonomoa erabiltzen duela, Sentinel-en oinarritutako kluster-soluzioa latentziari dagokionez askoz txikiagoa baita. Irtenbide ageriko bat cachearen hainbat erreplika sortzea izan zen: eta utz ezazu aplikazioa noranahi orekatzeko! Hala ere, garatzaileekin kontsultatu ondoren, aukera hau baztertzera behartuta egon ginen aplikazioaren cache baliogabetzeko mekanismo aktibo eta konplexuagatik. Arazo bera cache zatiketara zabaldu zen.

KeyDB-ri begirada azkarra

Arazoari irtenbide posible bat bilatzen ari ginenean, aurkitu genuen KeyDB izeneko aplikazioa. Hauek garatutako Redis fork bat da Kanadako konpainia eta doako BSD lizentziapean banatuta. Proiektua oso gaztea da: 2019 hasieratik dago. Bere historia da egileek ere behin Redis-en mugekin topo egin zutela... eta euren sardexka egitea erabaki zutela. Gainera, ezagunak diren arazoak konpondu ez ezik, Redis-en enterpise bertsioan soilik eskuragarri dauden funtzio osagarriak ere jaso ditu.

KeyDB xehetasun gehiagorekin ezagutu nahi dutenentzat, ona dago Medium-en sarrera artikulua, DBMS eta erreferentzia laburrak aurkezten dituena bere "gurasoarekin" - Redis.

Lehenik eta behin, KeyDBra erakarri gintuen gure arazoen konponbide potentzialak, eta, aldi berean, ezaugarri gehigarri batzuk interesatzen zitzaizkigun. KeyDB erabiltzeak abantaila hauek agintzen zituen:

• multithreading osoa lortzea;
• Redis-ekin bateragarritasun osoa eta erabatekoa (hau bereziki garrantzitsua zen guretzat, ezin izan baitzen aplikazioaren aldetik aldaketarik egin), eta horrek arazorik gabeko migrazioa ere agintzen zuen;
• S3 biltegian babeskopia mekanismoa;
• erreplikazio aktiboa ezartzeko erraza;
• clustering eta sharding sinplea Sentinel eta beste software osagarririk gabe.

3 mila izar baino gehiagok eta GitHub-eko kolaboratzaile askok ere pozgarriak izan ziren. Aplikazioa nahiko aktiboki garatu eta onartzen da, eta hori garbi ikusten da konpromisoetan, gaietan komunikazioan eta PR itxietan (onartutakoetan). Fronte guztietan zaintzaile nagusiaren erantzuna beti atsegina eta azkarra da. Oro har, argudio ugari egon ziren.

Migrazioa eta emaitzak

Nahiz eta migrazio proiektua apustu pixka bat izan (KeyDBren berritasuna dela eta), ez zegoen asko galtzeko. Azken finean, aldaketak atzera botatzea nahiko azkarra eta erraza da - zorionez, azpiegitura osoa Kubernetes-en zabaltzen da, eta integratutako mekanismoak. Eguneraketa iraunkorra Horrelako arazoak oso ondo konpontzen dituzte.

Oro har, Helm txantiloiak prestatu genituen, proba-inguruneko aplikazioa datu-base berri batera aldatu eta dena zabaldu genuen, bezeroaren QA sailari emanez.

Probak hasi ziren, astebete inguru iraun zuten eta xehetasunetan murgildu ez ginen. Bakarrik dakigu bezeroak Redis-ekin lan egiteko funtzio estandarrak probatu zituela PHP kontrolatzaile bat erabiliz phpredis, eta erabiltzailearen interfazearen QA probak ere egin zituen. Horren ostean, argi berdea eman ziguten: ez zen bigarren mailako efekturik aurkitu software berria erabiltzean. Hori da Aplikazioaren ikuspuntutik, ez da ezer aldatu.

Aipatzekoa da konfigurazioan ez dugula ezer aldatu: literalki, erabilitako irudia ordezkatu dugu. Gauza bera gertatzen da neurketak Prometheus-era monitorizatzeko eta esportatzeko: horietako ohikoena ezin hobeto funtzionatzen du KeyDB-rekin eta inolako aldaketarik gabe. Beraz, modu seguruan esan dezakegu operazio-ikuspegitik hau mugimendu aproposa besterik ez dela.

Horri guztiari esker, aplikazioa DBMS berri batera aldatu ondoren, ezin duzu ezer aldatu, baina "egonkortze-neurri" gisa utzi dezakezu denbora pixka batean borrokan lan egiteko. Hala ere, errendimenduaren igoera (edo aldaketaren bat) ikusi nahi baduzu, ez duzu hori ahaztu behar lehenespenez Hari anitzeko ardura duen KeyDB parametroa (server-threads), baten berdina da, hau da DBMSak Redis-en berdin funtzionatzen du.

Aplikazio berrian aldatu, probatu eta bizitza denbora pixka bat igaro ondoren (KeyDBrekin), karga-probak Redis-erako erabili ziren parametro berdinekin errepikatzea erabaki genuen. Zeintzuk izan ziren bere emaitzak?...

PUZaren kontsumo grafikoaren arabera, berehala nabaritu zen nukleo baten "sabaiarekin" arazoak ezabatzea: prozesua eskuragarri dauden baliabideak erabiltzen hasi zen:

Eta geroago aplikazioa "torturatzen" nahiko indarrez saiatu nintzen eta hiru nukleoren kontsumoa ikusi nuen...

New Relic-en arabera, web-aplikazioa bere osotasunean, karga bera zuela, nabarmen hobeto jokatzen hasi zen. Errendimenduaren narriaduraren bat ikusi zen oraindik, hala ere, goiko antzeko grafiko batekin alderatuta, aurrerapen esanguratsua zuk zeuk ebalua dezakezu:

Datu-base berriaren (KeyDB) latentzia ere okerrera egin zen, baina balio onargarrietan mantendu zen:

Ondorengo grafikoak argi erakusten du KeyDB-ri berari egindako eskaera kopurua antzekoa dela:

Proba sintetiko hauek laburbiltzeko, esan dezakegu bai Redis-ek bai KeyDB-k latentzian errendimenduaren degradazio nabarmena erakusten dutela (40 ms+), konexio paraleloen kopurua nabarmen handituz (1000+). Gure kasuan, web-aplikazioak Redis-en latentzia "xahutu" ahal izan zuen, nahiz eta konexio-kopuru txikiagoa izan (400+), nahiz eta KeyDBrako karga hori onargarria izan.

Findings

Adibide honek argi erakusten du Open Source komunitatearen indarra interesatzen zaizkion proiektuen garapenean. Adierazpen bikain batekin egin nuen topo Interneten, eta horren esanahi orokorra honela laburtzen zen: “Enpresa handi batzuek produktu interesgarri bat sortzen dute, bere funtzio batzuk irekitzen ditu, baina zati garrantzitsuena ordainduta uzten du. Komunitateak erabiltzen du eta erabiltzen du, eta gero norbaitek amore eman eta sardexka bat egiten du, bertan ordaindutako funtzio berdinak ezarriz eta guztientzako irekiz». Hemen KeyDB kasu bera da.

Migrazioari berari buruz hitz egitean, harrigarriro sinplea zena, ez genuen jaso hainbeste errendimenduaren igoera nabarmena, KeyDB-ren egileen grafikoak ikusita espero daitekeena... Hala ere, hau gure kasu berezia baino ez da, zeinetan desbideratze asko egon daitezkeen, aplikazioaren arkitektura sonatua barne (adibidez. , komando kopuru handi bat get Redis-en kontsulta agregatuen aukera eraginkorragoa izan beharrean mget...). Hala ere, emaitza positiboak lortzea lortu dugu, eta horiekin batera etorkizun hurbilean ezarriko ditugun funtzio baliagarri asko.

Oro har, KeyDB-k itxaropentsua dirudi: DBMS honekin esperientzia praktikoa lortzen dugun heinean (eta oraindik lortu behar dugu!) eta proiektua bera garatzen dugun heinean, beste egoera batzuetan erabiltzeko aukera aztertuko dugu.

Hala ere, artikulu hau ez da hartu behar gida gisa (are gutxiago dei gisa) KeyDBren alde Redis-en abandonu zabalaren alde egiteko. Gure esperientzia positiboa izan arren, argi dago hau ez dela zilarrezko bala bat. Kasua oso zehatza zen: zehazki, azkar eta kostu minimoarekin egin behar zen egoera batean momentuko arazo bat konpontzeko, konponbide hori justifikatuta zegoen. KeyDB erabilgarria izango al da zure kasuan? Orain, behintzat, badakizu aukera potentzial hori existitzen dela.

PS

Irakurri ere gure blogean:

• «Datu-baseak eta Kubernetes (berrikuspena eta bideo-txostena)»;
• «Cassandra Migrazioa Kubernetesera: ezaugarriak eta irtenbideak»;
• «MongoDB-ren migraziorik gabeko Kubernetesera»;
• «RabbitMQ-ren migrazioa Kubernetesera'.

Iturria: www.habr.com