KeyDB kiel [ebla] anstataŭaĵo por Redis

Ne estis recenzoj pri "pli rapida alternativo al Redis" ĉe Habré - KeyDB. Akirinte sufiĉe lastatempan sperton en uzado de ĝi, mi ŝatus plenigi ĉi tiun mankon.

La fono estas sufiĉe banala: unu tagon, kun granda enfluo de trafiko, estis registrita grava degenero en la aplikaĵo (nome, respondtempo). Tiutempe, bedaŭrinde, ne eblis fari normalan diagnozon pri tio, kio okazis, tial serio da ŝarĝtestoj estis poste planitaj. Farinte ilin, ni povis malkovri botelon, kiu estis la datumbaza kaŝmemoro en Redis. Kiel ofte okazas, la problemo ne povus esti solvita tuj kaj en la ĝusta maniero - de la programistoj (ŝanĝante la logikon de laboro). Sekve, scivolemo kaj deziro venki la situacion en cirklamaniere ŝaltis. Jen kiel ĉi tiu artikolo aperis.

Temoj

Pri Redis ĝenerale

Kiel multaj homoj scias, Redis estas unufadena datumbazo. Por esti pli preciza, ĝi estas tiel en la kunteksto de laboro kun uzantdatenoj. Post ĉio, ekde la kvara versio, servo, internaj operacioj de Redis tradukita por paralela ekzekuto. Tamen, ĉi tiu ŝanĝo nur influis malgrandan parton de la laborkvanto, ĉar la plejparto de la laboro estas farita sur uzantdatenoj.

Sennombraj kopioj estis rompitaj pri ĉi tiu temo, sed la programistoj de Redis obstine rifuzas efektivigi plenan paralelecon, menciante kiom ĝi malfaciligos la aplikaĵon kaj pliigos superkostojn, kaj aldonos pli da eraroj. Ilia pozicio estas jena: se vi alfrontas unu-kernan problemon, vi havas problemojn kun la aplika arkitekturo kaj io devas esti ŝanĝita en ĝi. Inter uzantoj, tamen, estas ankaŭ "alia tendaro" - tiuj, kiuj estas blokitaj sur unu kerno kaj asertas, ke Redis kreas botelon por si mem. En la kazo de vere grandaj ŝarĝoj - frue aŭ malfrue - estas neeviteble renkonti ĉi tiun problemon, kiu trudas signifajn limigojn al la arkitekturo kaj/aŭ devigajn komplikaĵojn en ĝi.

Mi ne taksos tiun aŭ alian opinion. Anstataŭe, mi dividos nian specifan kazon kaj kiel ni solvis ĝin.

Nia kazo

En unu el la projektoj, ni renkontis la fakton, ke la evolua teamo agordis ekstreme agreseman kaŝmemoron de datumoj de la datumbazo (PostgreSQL) per Redis. Ĉi tio estis la nura maniero, kiu, dum subitaj enfluoj de trafiko, savis PostgreSQL mem kaj, kiel rezulto, la aplikaĵon de morto.

Post serio da ŝarĝtestoj, ni analizis la situacion kaj trovis, ke Redis estis limigita al unu kerno (kio nomiĝas "breto"), sekvita de sufiĉe rapida degenero de la aplikaĵo. La "sufokado" estis eksponenta: tuj kiam la limo de rendimento de Redis estis atingita, ĉio ĉesis funkcii.

Ĝi aspektis tiel:

New Relic klare identigis la problemon:

Jen la statistiko por la operacio: get en Redis:

Post kiam la problemo estis raportita al la disvolva teamo detale, montriĝis, ke "la problemo ne povas esti solvita nun." Tiel komenciĝis la serĉado de solvo sur la operacia flanko, kaj la jam menciita KeyDB estis la respondo.

Tamen, antaŭ ol ni komencu nian revizion, indas mencii, ke la projekto uzas memstaran Redis, ĉar la cluster-solvo bazita sur Sentinel estas multe malsupera laŭ latenteco. Unu evidenta solvo estis krei plurajn kopiojn de la kaŝmemoro: kaj lasu la aplikaĵon iri ĉien kun ekvilibro! Tamen, post konsultado kun la programistoj, ni estis devigitaj forĵeti ĉi tiun opcion pro la aktiva kaj kompleksa kaŝmemoro-malvalidiga mekanismo de la aplikaĵo. La sama problemo etendiĝis al kaŝmemoro sharding.

Rapida Rigardo al KeyDB

Serĉante eblan solvon al la problemo, ni malkovris aplikaĵo nomata KeyDB. Ĉi tio estas Redis-forko evoluigita de Kanada kompanio kaj distribuita sub la libera BSD-licenco. La projekto estas tre juna: ĝi ekzistas ekde la komenco de 2019. Ĝia historio estas, ke la aŭtoroj ankaŭ iam renkontis la limojn de Redis... kaj decidis fari sian propran forkon. Krome, ĝi ne nur solvis konatajn problemojn, sed ankaŭ ricevis pliajn funkciojn, kiuj estas nur disponeblaj en la entreprena versio de Redis.

Por tiuj, kiuj volas pli detale konatiĝi kun KeyDB, estas bona enkonduka artikolo pri Medium, kiu prezentas la DBMS kaj mallongajn komparnormojn komparantaj ĝin kun ĝia "gepatro" - Redis.

Antaŭ ĉio, nin allogis KeyDB la ebla solvo de niaj problemoj, kaj samtempe ni interesiĝis pri kelkaj pliaj funkcioj. Uzi KeyDB promesis la sekvajn avantaĝojn:

• akiri plenan multifadenadon;
• plena kaj absoluta kongruo kun Redis (ĉi tio estis precipe grava por ni, ĉar ne eblis fari ajnajn modifojn ĉe la aplikaĵo), kiu ankaŭ promesis senpagan migradon;
• enkonstruita rezerva mekanismo en S3-stokado;
• facile efektivigi aktivan reproduktadon;
• simpla clustering kaj sharding sen Sentinel kaj alia subtena programaro.

Pli ol 3 mil steloj kaj multaj kontribuantoj en GitHub ankaŭ aspektis kuraĝige. La aplikaĵo estas sufiĉe aktive evoluigita kaj subtenata, kio estas klare videbla en la komitoj, komunikado en aferoj, kaj ankaŭ fermitaj (akceptitaj) PR-oj. La respondo de la ĉefa prizorganto en ĉiuj frontoj estas ĉiam amika kaj rapida. Ĝenerale, estis multe da argumentoj.

Migrado kaj rezultoj

Kvankam la migra projekto estis iom hazarda (pro la noveco de KeyDB), ne estis multo por perdi. Post ĉio, restarigi ŝanĝojn estas sufiĉe rapida kaj facila - feliĉe, la tuta infrastrukturo estas deplojita en Kubernetes, kaj la enkonstruitaj mekanismoj. Ruliĝanta Ĝisdatigo Ili tre bone solvas tiajn problemojn.

Ĝenerale, ni preparis Helm-ŝablonojn, ŝanĝis la aplikaĵon en la testa medio al nova datumbazo kaj eligis ĉion, transdonante ĝin al la QA-fako de la kliento.

Testado komenciĝis, kiu daŭris proksimume semajnon kaj kies detalojn ni ne plonĝis. Ni nur scias, ke la kliento testis la normajn funkciojn labori kun Redis uzante PHP-ŝoforon phpredis, kaj ankaŭ faris QA-testadon de la uzantinterfaco. Post tio, ni ricevis la verdan lumon: neniuj kromefikoj estis trovitaj en uzado de la nova programaro. Tio estas De la aplika vidpunkto, nenio ŝanĝiĝis.

Indas noti, ke ni ŝanĝis nenion en la agordo: laŭvorte, ni simple anstataŭigis la uzitan bildon. La sama validas por monitorado kaj eksportado de metrikoj al Prometheus: la plej ofta el ili funkcias perfekte kun KeyDB kaj sen iuj modifoj. Tiel, ni povas sekure diri, ke de operacia vidpunkto, ĉi tio estas simple ideala movo.

Danke al ĉio ĉi, post ŝanĝi la aplikaĵon al nova DBMS, vi ne povas ŝanĝi ion ajn, sed kiel "stabiligizo" vi povas lasi ĝin en ĉi tiu formo por labori en batalo dum iom da tempo. Tamen, se vi volas vidi rendimenton pliiĝon (aŭ ajnajn ŝanĝojn entute), vi ne devas forgesi tion implicite KeyDB-parametro respondeca pri multfadenado (server-threads), estas egala al unu, tio estas La DBMS funkcias ekzakte same kiel Redis.

Post ŝanĝado, testado kaj iom da tempo de vivo sur la nova aplikaĵo (kun KeyDB), ni decidis ripeti la ŝarĝtestadon kun la samaj parametroj, kiuj estis uzataj por Redis. Kiuj estis ĝiaj rezultoj?...

Laŭ la CPU-konsuma grafiko, la elimino de problemoj kun la "plafono" de unu kerno tuj fariĝis videbla: la procezo komencis uzi disponeblajn rimedojn:

Kaj poste mi provis "torturi" la aplikaĵon sufiĉe forte kaj vidis konsumadon de ĝis tri kernoj...

Laŭ New Relic, la retejo entute, havanta la saman ŝarĝon, komencis konduti rimarkeble pli adekvate. Iu rendimento degenero ankoraŭ estis observita, tamen, kompare kun simila grafikaĵo supre, vi povas taksi la gravan progreson por vi mem:

La latenteco de la nova datumbazo (KeyDB) ankaŭ plimalboniĝis, sed restis ene de akcepteblaj valoroj:

La sekva grafikaĵo klare montras, ke la nombro da petoj al KeyDB mem estas simila:

Por resumi ĉi tiujn sintezajn provojn, ni povas diri, ke kaj Redis kaj KeyDB montras signifan rendimentan degeneron en latenteco (40 ms+) kun signifa pliiĝo en la nombro da paralelaj konektoj (1000+). En nia kazo, la retejo-aplikaĵo povis "malŝpari" la latentecon de Redis eĉ kun pli malalta nombro da konektoj (400+), kvankam por KeyDB tia ŝarĝo restis akceptebla.

trovoj

Ĉi tiu ekzemplo klare montras la forton de la Open Source komunumo en la disvolviĝo de projektoj pri kiuj ĝi interesiĝas. Mi trovis bonegan deklaron en la Interreto, kies ĝenerala signifo resumiĝis al la jena: “Iu granda firmao kreas interesan produkton, malfermas kelkajn el ĝiaj funkcioj, sed lasas la plej gravan parton pagata. La komunumo uzas ĝin kaj uzas ĝin, kaj tiam iu rezignas kaj faras forkon, efektivigante la samajn pagitajn funkciojn en ĝi kaj malfermante ilin al ĉiuj." Ĉi tie KeyDB estas la sama kazo.

Parolante pri la migrado mem, kiu estis surprize simpla, ni ne ricevis do grava pliiĝo de rendimento, kiun oni povas atendi rigardante la grafikaĵojn de la aŭtoroj de KeyDB... Tamen ĉi tio estas nur nia speciala kazo, en kiu povas esti multaj devioj, inkluzive de la konata arkitekturo de la aplikaĵo (ekzemple , grandega nombro da komandoj get en Redis anstataŭ la pli efika opcio de entutaj demandoj mget...). Tamen ni sukcesis atingi pozitivajn rezultojn, kaj kune kun ili multajn utilajn funkciojn, kiujn ni efektivigos en proksima estonteco.

Ĝenerale, KeyDB aspektas promesplena: ĉar ni akiras praktikan sperton kun ĉi tiu DBMS (kaj ni ankoraŭ devas akiri ĝin!) kaj evoluigas la projekton mem, ni konsideros la eblecon uzi ĝin en aliaj situacioj.

Tamen, ĉi tiu artikolo ne devus esti konsiderata kiel gvidilo (ne nur voko) al agado por la ĝeneraligita forlaso de Redis favore al KeyDB. Malgraŭ nia pozitiva sperto, estas klare, ke ĉi tio ne estas arĝenta kuglo. La kazo estis tre specifa: specife por solvi momentan problemon en situacio, kie necesis fari ĝin rapide kaj je minimuma kosto, tiu solvo estis pravigita. Ĉu KeyDB estos utila en via kazo? Almenaŭ nun vi scias, ke ĉi tiu ebla ebleco ekzistas.

PS

Legu ankaŭ en nia blogo:

• «Datumbazoj kaj Kubernetes (recenzo kaj videoraporto)»;
• «Migrado de Cassandra al Kubernetes: trajtoj kaj solvoj»;
• «Senjunta migrado de MongoDB al Kubernetes»;
• «Senjunta migrado de RabbitMQ al Kubernetes".

fonto: www.habr.com