Redis ili Valkey: veći broj QPS-a ne jamči sigurniju migraciju

Veći broj zahtjeva u sekundi nije dovoljan razlog za prelazak s Redisa na Valkey. Migracija se isplati tek ako Valkey pod stvarnim opterećenjem zadovoljava zahtjeve aplikacije, prihvaća njezine podatke i održava prihvatljivu uslugu tijekom replikacije, promjene primarnog čvora i ponovnog spajanja klijenata.

Usporedba zato treba obuhvatiti rad na jednom čvoru, rad u Kubernetesu i navalu novih veza nakon prekida. Za oba spremnika valja zadržati istu mješavinu naredbi, podatke i raspoložive resurse te uz QPS pratiti latenciju sporijih zahtjeva, pogreške i oporavak. Najveća sintetička propusnost odgovara samo na pitanje koliko zahtjeva određena konfiguracija može obraditi u uvjetima tog testa.

Što znače objavljene brojke i licence

Redisov prikaz izdanja Redis 8 navodi do 87 % nižu latenciju naredbi u usporedbi s Redisom 7.2.5, 35 % manji vršni replikacijski međuspremnik na primarnom čvoru u opisanom testu te do 16 puta veću propusnost Redis Query Enginea pri skaliranju. Riječ je o različitim mjerenjima unutar Redisova proizvoda, a ne o jedinstvenom testu protiv Valkeyja. Rezultat pretraživanja također nije zamjenjiv s QPS-om uobičajenih naredbi za rad s predmemorijom.

Redis 8 nudi AGPLv3 kao licencnu mogućnost uz RSALv2 i SSPLv1. Valkeyjeva dokumentacija opisuje Valkey kao memorijski spremnik pod licencijom BSD, s replikacijom, trajnom pohranom, skriptama Lua te načinima rada Sentinel i Cluster. Licenca može utjecati na izbor distribucije, ali usporedba mogućnosti mora početi od naredbi, skripti i modula koje aplikacija doista koristi. Podudarnost osnovnih naredbi sama po sebi ne govori kako će se ponašati svaka funkcija određene instalacije.

Jednaki uvjeti prije usporedbe QPS-a

Rezultati su usporedivi samo uz jednake procesore, dostupne jezgre, memoriju, mrežnu putanju, broj klijenata i postavke trajne pohrane. Jednaki moraju biti i veličina vrijednosti, raspon ključeva, omjer čitanja i pisanja te dubina ulančavanja zahtjeva. Promjena bilo koje od tih stavki može promijeniti što je usko grlo, pa zapis konfiguracije pripada uz svaki rezultat.

Upute za valkey-benchmark opisuju podešavanje paralelnih veza, veličine podataka, raspona ključeva i ulančavanja zahtjeva; ako generator i poslužitelj rade na istom računalu, preporučuju najmanje dvije niti generatora kako on ne bi ograničio mjerenje. Odvojeni generator olakšava uočavanje njegove zauzetosti procesora, no tada u rezultat ulazi i mrežna putanja. Za oba kandidata treba upotrijebiti isti klijent i jednaku postavku TLS-a, onu koja odgovara predviđenom radu aplikacije.

Jedan čvor pokazuje cijenu aplikacijskih naredbi

Na jednom čvoru najviše vrijedi ponoviti stvarnu mješavinu operacija: čitanja, upise, rokove isteka, skripte i naredbe nad strukturama podataka koje aplikacija redovito poziva. Zatim treba zasebno izmjeriti važne skupine naredbi. Tako postaje vidljivo dolazi li prednost iz operacije bitne za uslugu ili iz većeg udjela brzih čitanja u sintetičkom prometu.

Skup podataka treba približiti produkcijskoj raspodjeli ključeva i zauzeću memorije. Uz najveći QPS korisnije je zabilježiti propusnost pri opterećenju koje aplikacija može trajno održavati, latenciju sporijih zahtjeva, potrošnju procesora te odbijene i istekle zahtjeve. Ako produkcijska postava izrađuje snimke podataka ili potpuno usklađuje replike, mjerenje treba ponoviti tijekom tih postupaka: oni troše resurse koje test na mirnom čvoru ostavlja slobodnima.

Kubernetes dodaje mrežu i oporavak u mjerenje

U Kubernetesu vrijeme koje vidi aplikacija uključuje mrežnu putanju između njezina poda i spremnika. Redis i Valkey zato valja usporediti uz jednak raspored podova, ograničenja procesora i memorije, broj replika, mrežna pravila te položaj generatora prometa. Mjerenje s klijentom i spremnikom na istom čvoru ne treba izravno suprotstaviti mjerenju koje prolazi između čvorova.

Ovaj profil ima smisla izvesti najprije pri stabilnom prometu, a zatim uz kontrolirani prekid, primjerice ponovno pokretanje poda ili gubitak primarnog čvora. Važno je mjeriti trajanje aplikacijskih pogrešaka, povratak uobičajene latencije, zaostatak replike i dodatnu memoriju potrebnu pri oporavku. Spremnik s većim QPS-om u mirnom radu može biti lošiji izbor ako aplikacija nakon promjene čvora predugo čeka valjane odgovore.

Navala veza traži zaseban pokus

Valkeyjev opis navale veza prikazuje kako zajednički kratki prekid može navesti mnogo klijentskih instanci na istodobno ponovno spajanje, uz TCP i TLS rukovanje te autentikaciju. Novi pokušaji tada troše resurse koji su potrebni i postojećim zahtjevima. Mjerenje brzine izvršavanja naredbi sa stabilnim vezama ne zahvaća taj slijed.

Kontrolirani prekid treba provesti dok radi broj aplikacijskih instanci predviđen za stvarnu uslugu. Bilježite stopu uspostave novih veza, pogreške, vrijeme odgovora postojećih veza i vrijeme oporavka; zadržite ista pravila ponavljanja zahtjeva i isti posrednički sloj za oba kandidata. Ako klijentske biblioteke podržavaju ograničavanje ponovnih pokušaja, zasebno izmjerite učinak te postavke. Rezultat tada opisuje ponašanje sustava, uključujući klijente, a ne samo spremnika.

Probna migracija i put povratka

Valkeyjeve upute za migraciju navode kompatibilnost s otvorenim izdanjima Redisa do serije 7.2, dok podatkovne datoteke koje proizvodi Redis Community Edition 7.4 i noviji nisu kompatibilne s opisanim izravnim prijenosom. Upute obrađuju prijenos snimke, replikaciju i migraciju pojedinih ključeva. Stoga točna izvorna verzija i format podataka određuju može li probni prijenos krenuti kopiranjem datoteke ili zahtijeva drukčiji postupak.

Probni prijelaz treba obuhvatiti važne naredbe, skripte, pravila pristupa, rokove isteka i postupak oporavka. Prije preusmjeravanja prometa usporedite stanje ključeva i replikacije te odgovore aplikacije; nakon preusmjeravanja pratite pogreške, latenciju i zaostatak replike. Granice prihvatljivog prekida i gubitka podataka treba odrediti prema zahtjevima usluge, jer ih ciljani QPS ne može zamijeniti.

Za povratak sačuvajte početno stanje i unaprijed odredite što se događa s upisima nastalim nakon preusmjeravanja na Valkey. Stari primarni čvor bez dodatnog usklađivanja neće sadržavati te nove upise, pa jednostavna promjena odredišta klijenata može vratiti zastarjele podatke. Probni povratak mora zato obuhvatiti podatke, veze klijenata i replike. Tek usporedivo opterećenje zajedno s izvedivim oporavkom daje dovoljno čvrstu osnovu za odluku o zamjeni.

Pročitajte i:

• GitBook ili Docusaurus: pretplata zamjenjuje stalni inženjerski rad
• DocuSign ili Acrobat Sign: broj omotnica mijenja skuplji izbor
• RAG ili fine-tuning: znanje i ponašanje traže različita ulaganja