KeyDB kao [potencijalna] zamjena za Redis

Na Habréu nije bilo recenzija „brže alternative za Redis“ - KeyDB. Pošto sam stekao relativno nedavno iskustvo u njegovom korištenju, želio bih popuniti ovu prazninu.

Pozadina je prilično banalna: jednog dana, uz veliki priliv saobraćaja, zabilježena je značajna degradacija performansi aplikacije (naime, vrijeme odziva). U to vrijeme, nažalost, nije bilo moguće izvršiti normalnu dijagnozu dešavanja, pa je naknadno planiran niz testova opterećenja. Nakon što smo ih sproveli, uspjeli smo otkriti usko grlo, a to je bila keš baze podataka u Redis-u. Kao što se često dešava, problem nije mogao da se reši odmah i na pravi način - od strane programera (promenom logike rada). Stoga se upalila radoznalost i želja da se situacija prevaziđe na zaobilazni način. Ovako se pojavio ovaj članak.

Problemi

O Redisu općenito

Kao što mnogi ljudi znaju, Redis je baza podataka s jednim niti. Tačnije, ovako je u kontekstu rada sa korisničkim podacima. Uostalom, od četvrte verzije, servis, interno poslovanje Redisa prevedeno za paralelno izvođenje. Međutim, ova promjena je utjecala samo na mali dio posla, budući da najveći dio posla dolazi od korisničkih podataka.

Nebrojene kopije su razbijene na ovu temu, ali Redis programeri tvrdoglavo odbijaju implementirati potpuni paralelizam, pominjući koliko će to zakomplikovati aplikaciju i povećati režijske troškove, kao i dodati još grešaka. Njihov stav je sljedeći: ako ste suočeni s jednojezgrenim problemom, imate problema sa arhitekturom aplikacije i nešto treba promijeniti u njoj. Među korisnicima, međutim, postoji i “drugi tabor” - oni koji su zaglavljeni na jednom jezgru i tvrde da Redis sam sebi stvara usko grlo. U slučaju zaista velikih opterećenja - prije ili kasnije - neizbježno je naići na ovaj problem, koji nameće značajna ograničenja arhitekturi i/ili prisilne komplikacije u njoj.

Neću ocjenjivati ​​ovo ili ono mišljenje. Umjesto toga, podijelit ću naš konkretan slučaj i kako smo ga riješili.

Naš slučaj

U jednom od projekata naišli smo na činjenicu da je razvojni tim konfigurisao izuzetno agresivno keširanje podataka iz baze podataka (PostgreSQL) preko Redisa. Ovo je bio jedini način koji je, tokom iznenadnih priliva saobraćaja, spasio sam PostgreSQL i, kao rezultat, aplikaciju od smrti.

Nakon niza testova opterećenja, analizirali smo situaciju i otkrili da je Redis ograničen na jedno jezgro (ono što se zove “polica”), nakon čega je uslijedila prilično brza degradacija aplikacije. „Gušenje“ je bilo eksponencijalno: čim je Redisova granica performansi dostignuta, sve je prestalo da radi.

Izgledalo je otprilike ovako:

Novi Relic je jasno identifikovao problem:

Evo statistike za operaciju: get u Redisu:

Nakon što je problem detaljno prijavljen razvojnom timu, pokazalo se da se „problem trenutno ne može riješiti“. Tako je počela potraga za rješenjem na operativnoj strani, a već spomenuti KeyDB je bio odgovor.

Međutim, prije nego što započnemo naš pregled, vrijedi napomenuti da projekat koristi samostalni Redis, budući da je cluster rješenje bazirano na Sentinelu mnogo inferiornije u smislu latencije. Jedno očigledno rešenje bilo je kreiranje nekoliko replika keša: i pustiti aplikaciju da ide svuda sa balansiranjem! Međutim, nakon konsultacija sa programerima, bili smo primorani da odbacimo ovu opciju zbog aktivnog i složenog mehanizma za poništavanje predmemorije aplikacije. Isti problem se proširio i na dijeljenje keša.

Brzi pogled na KeyDB

Dok smo tražili moguće rješenje problema, otkrili smo aplikacija pod nazivom KeyDB. Ovo je Redis fork koji je razvio Kanadska kompanija i distribuira se pod besplatnom BSD licencom. Projekat je veoma mlad: postoji od početka 2019. Njegova istorija je da su se autori takođe jednom susreli sa ograničenjima Redisa... i odlučili da naprave sopstvenu viljušku. Štaviše, ne samo da je riješio poznate probleme, već je dobio i dodatne funkcije koje su dostupne samo u Enterprise verziji Redisa.

Za one koji žele detaljnije da se upoznaju sa KeyDB-om, postoji dobar uvodni članak o Medium, koji predstavlja DBMS i kratke benchmarkove upoređujući ga sa njegovim “roditeljem” - Redis-om.

Prije svega, KeyDB nas je privuklo potencijalno rješenje naših problema, a ujedno su nas zanimale i neke dodatne mogućnosti. Korištenje KeyDB obećava sljedeće prednosti:

• dobivanje punog višenitnog rada;
• puna i apsolutna kompatibilnost sa Redis-om (ovo je bilo posebno važno za nas, jer nije bilo moguće napraviti nikakve modifikacije na strani aplikacije), što je takođe obećavalo migraciju bez problema;
• ugrađeni backup mehanizam u S3 skladište;
• lako implementirati aktivnu replikaciju;
• jednostavno grupisanje i dijeljenje bez Sentinela i drugog pratećeg softvera.

Više od 3 hiljade zvjezdica i mnogi saradnici na GitHubu također su izgledali ohrabrujuće. Aplikacija je prilično aktivno razvijena i podržana, što je jasno vidljivo u commitima, komunikaciji u pitanjima, kao i zatvorenim (prihvaćenim) PR-ovima. Odgovor glavnog održavaoca na svim frontovima je uvijek prijateljski i brz. Generalno, bilo je dosta argumenata.

Migracije i rezultati

Iako je projekat migracije bio malo kockanje (zbog novine KeyDB-a), nije se moglo mnogo izgubiti. Na kraju krajeva, vraćanje promjena je prilično brzo i jednostavno - na sreću, cjelokupna infrastruktura je raspoređena u Kubernetes-u, a ugrađeni mehanizmi Rolling Update Vrlo dobro rješavaju takve probleme.

Općenito, pripremili smo Helm šablone, prebacili aplikaciju u testnom okruženju na novu bazu podataka i sve to uveli, predavši je klijentovom QA odjelu.

Počelo je testiranje koje je trajalo oko nedelju dana i u čije detalje nismo ulazili. Znamo samo da je korisnik testirao standardne funkcije rada sa Redis-om koristeći PHP drajver phpredis, a također je sprovedeno QA testiranje korisničkog interfejsa. Nakon toga smo dobili zeleno svjetlo: nuspojave u korištenju novog softvera nisu pronađene. To je Sa stanovišta primjene, ništa se nije promijenilo.

Vrijedi napomenuti da nismo ništa mijenjali u konfiguraciji: doslovno, jednostavno smo zamijenili korištenu sliku. Isto važi i za praćenje i izvoz metrike u Prometheus: najčešći od njih radi savršeno sa KeyDB i bez ikakvih modifikacija. Dakle, možemo sa sigurnošću reći da je sa operativne tačke gledišta ovo jednostavno idealan potez.

Zahvaljujući svemu tome, nakon prebacivanja aplikacije na novi DBMS, ne možete ništa promijeniti, ali kao “mjeru stabilizacije” možete je ostaviti u ovom obliku da radi u borbi neko vrijeme. Međutim, ako želite vidjeti povećanje performansi (ili bilo kakve promjene uopće), ne smijete to zaboraviti po defaultu KeyDB parametar odgovoran za višenitnost (server-threads), jednak je jedan, tj DBMS radi potpuno isto kao Redis.

Nakon prebacivanja, testiranja i određenog vremena života na novoj aplikaciji (sa KeyDB), odlučili smo da ponovimo testiranje opterećenja sa istim parametrima koji su korišteni za Redis. Kakvi su bili njeni rezultati?..

Prema grafikonu potrošnje CPU-a, eliminacija problema sa "plafonom" jedne jezgre odmah je postala primjetna: proces je počeo koristiti dostupne resurse:

A kasnije sam pokušao prilično snažno da "mučim" aplikaciju i vidio sam potrošnju do tri jezgre...

Prema New Reliću, web aplikacija u cjelini, sa istim opterećenjem, počela je da se ponaša primjetno adekvatnije. Još uvijek je uočena određena degradacija performansi, međutim, u poređenju sa sličnim grafikonom iznad, možete sami procijeniti značajan napredak:

Latencija nove baze podataka (KeyDB) se također pogoršala, ali je ostala unutar prihvatljivih vrijednosti:

Sljedeći grafikon jasno pokazuje da je broj zahtjeva za sam KeyDB sličan:

Da sumiramo ove sintetičke testove, možemo reći da i Redis i KeyDB pokazuju značajnu degradaciju performansi u kašnjenju (40 ms+) uz značajno povećanje broja paralelnih veza (1000+). U našem slučaju, web aplikacija je uspjela „protraćiti“ Redisovo kašnjenje čak i uz manji broj konekcija (400+), iako je za KeyDB takvo opterećenje ostalo prihvatljivo.

nalazi

Ovaj primjer jasno pokazuje snagu Open Source zajednice u razvoju projekata za koje je zainteresirana. Na internetu sam naišao na odličnu izjavu čije se opšte značenje svodilo na sljedeće: „Neka velika kompanija napravi zanimljiv proizvod, otvori neke od svojih funkcija, ali ostavi najvažniji dio plaćenim. Zajednica to koristi i koristi, a onda neko odustane i napravi viljušku, implementirajući iste plaćene funkcije u nju i otvarajući ih svima.” Ovdje je KeyDB isti slučaj.

Što se tiče same migracije, koja je bila iznenađujuće jednostavna, nismo dobili toliko značajno povećanje performansi, što se može očekivati ​​gledajući grafikone autora KeyDB-a... Međutim, ovo je samo naš poseban slučaj, u kojem može biti mnogo odstupanja, uključujući i ozloglašenu arhitekturu aplikacije (npr. ogroman broj komandi get u Redis-u umjesto učinkovitije opcije skupnih upita mget...). Ipak, uspjeli smo postići pozitivne rezultate, a uz njih i mnoge korisne funkcije koje ćemo implementirati u bliskoj budućnosti.

Generalno, KeyDB izgleda obećavajuće: kako budemo stekli praktično iskustvo sa ovim DBMS-om (a još ga moramo steći!) i razvijamo sam projekat, razmotrićemo mogućnost da ga koristimo u drugim situacijama.

Međutim, ovaj članak ne treba smatrati vodičem (a kamoli pozivom) na akciju za široko rasprostranjeno napuštanje Redisa u korist KeyDB-a. Uprkos našem pozitivnom iskustvu, jasno je da ovo nije srebrni metak. Slučaj je bio vrlo specifičan: upravo za rješavanje trenutnog problema u situaciji kada je to bilo potrebno učiniti brzo i uz minimalne troškove, ovo rješenje je bilo opravdano. Hoće li KeyDB biti koristan u vašem slučaju? Sada barem znate da ova potencijalna mogućnost postoji.

PS

Pročitajte i na našem blogu:

• «Baze podataka i Kubernetes (pregled i video izvještaj)»;
• «Migracija Cassandre na Kubernetes: karakteristike i rješenja»;
• «Besprekorna migracija MongoDB-a na Kubernetes»;
• «Besprekorna migracija RabbitMQ-a na Kubernetes".

izvor: www.habr.com