Redis vai Valkey? Lisenssi ratkaisee ennen nopeuseroa

|Kirjoittaja: QUASAn toimitus|5 min lukuaika
Redis vai Valkey? Lisenssi ratkaisee ennen nopeuseroa

Valkey on luonteva valinta, jos salliva lisenssi on ehdoton vaatimus ja sovellus käyttää tuotteiden yhteisiä perustoimintoja. Redis sopii paremmin, jos sovellus tarvitsee sen sisäänrakennettuja tietotyyppejä tai hakua ja valitut lisenssiehdot sopivat organisaatiolle. Suorituskykyä kannattaa vertailla vasta, kun molemmat vaihtoehdot täyttävät nämä ehdot.

Siirtymisen vaikeus riippuu lähtöversiosta ja palvelumallista. Vanhemmasta Redis OSS -asennuksesta voi löytyä suora datatiedostojen siirtopolku Valkeyhin, mutta uudemman Redis-asennuksen tiedostoille ei pidä olettaa samaa yhteensopivuutta. Hallitussa pilvessä myös palveluntarjoajan päivitysmenettely ja tuki kuuluvat päätökseen.

Lisenssi ja hallintamalli asettavat rajat

Redis-yhtiön lisenssi- ja ominaisuusvertailun mukaan Valkey käyttää BSD 3-Clause -lisenssiä, kun Redis 8:ssa voi valita AGPLv3:n, RSALv2:n tai SSPLv1:n. BSD sallii kaupallisen käytön, muutokset ja levityksen vähäisin ehdoin, joihin kuuluu alkuperäisten tekijänoikeus- ja lisenssitietojen säilyttäminen. Jos organisaation sääntö edellyttää juuri sallivaa BSD-lisenssiä, Redis 8:n AGPL-vaihtoehto ei täytä samaa ehtoa, vaikka se on avoimen lähdekoodin lisenssi.

AGPLv3:n verkkokäyttöä koskeva velvoite on olennainen erityisesti silloin, kun Redis-koodia muutetaan ja muokattua ohjelmaa tarjotaan verkon kautta. Muokkaamattoman palvelimen käyttö sovelluksen taustalla on eri tilanne. RSALv2:n ja SSPLv1:n ehdot vaativat oman arvionsa varsinkin silloin, kun liiketoiminta perustuu hallitun tietokantapalvelun tarjoamiseen. Lisenssipäätöksessä ratkaisee siis se, miten ohjelmistoa käytetään ja tarjotaan, eikä pelkkä tieto siitä, että Redisille on valittavissa AGPLv3.

Hallinnassa ero on yhtä konkreettinen: Redis-yhtiö ohjaa Redis-projektia, kun Valkeyta kehitetään Linux Foundationin piirissä usean toimijan hallintamallilla. Tämä vaikuttaa siihen, kuka päättää ohjelmiston kehityssuunnasta. Hallintamalli ei kuitenkaan kerro, minkälaisen vasteajan tai tukisopimuksen yksittäinen käyttöönotto saa; ne määräytyvät valitun toteutuksen ja toimittajan mukaan.

Yhteinen alkuperä ei takaa kaikkien ominaisuuksien yhteensopivuutta

Redis OSS 7.2:n datatiedosto siirtyy Valkeyhin, mutta uudemman Redis-version tiedosto kohtaa yhteensopivuusrajan.

Valkeyn migraatio-ohje kertoo projektin haarautuneen Redis OSS 7.2.4:stä. Sen mukaan Redis OSS 7.2:n ja sitä vanhempien avoimen lähdekoodin versioiden protokolla, asetukset sekä RDB- ja AOF-tiedostot ovat yhteensopivia Valkeyn kanssa. Tavalliset Redis-asiakaskirjastot voivat muodostaa yhteyden RESP-protokollalla. Myös Redis-nimiavaruutta käyttävät Lua-skriptit ja vanhaan moduulirajapintaan perustuvat moduulit kuuluvat ohjeessa kuvattuun yhteensopivuuteen.

Redis Community Edition 7.4 ja sitä uudemmat versiot tuottavat saman ohjeen mukaan datatiedostoja, jotka eivät ole suoraan Valkey-yhteensopivia. Redis 8:sta siirtyvän on siksi suunniteltava datan siirto erikseen sen sijaan, että nykyinen tilannekuva käynnistettäisiin Valkeyssa. On myös erotettava tiedostomuodon yhteensopivuus sovelluksen toiminnallisesta yhteensopivuudesta: onnistunut asiakasyhteys ei vielä kerro, toimivatko kaikki käytetyt komennot, skriptit, moduulit ja klusteriasetukset.

Redis 8 sisältää esimerkiksi JSONin, aikasarjat ja hakuominaisuuksia ydintuotteessaan. Valkeylle on tarjolla erillisiä virallisia moduuleja, muun muassa JSONia ja hakua varten, mutta vastaavan toiminnon olemassaolo ei tarkoita samaa komentovalikoimaa tai kyselykäyttäytymistä. Pelkkää välimuistia käyttävä sovellus ja hakuun tai aikasarjoihin nojaava sovellus kohtaavat siksi hyvin erilaisen muutostyön. Jälkimmäisessä tapauksessa päätös koskee palvelinohjelman lisäksi sovelluskoodia ja sen käyttämää tietomallia.

Kubernetes-tulos riippuu kuormasta, ja lukuihin liittyy varaus

Kubernetes-mittaus vertaa Valkey 8.0.2:ta Redis 7.2.7:ään erillisellä kuormageneraattorilla.

Uumajan yliopistossa julkaistu opinnäyte vertasi Redis 7.2.7:ää, Valkey 8.0.2:ta, KeyDB:tä ja Garnetia Kubernetes-ympäristössä. Sen taulukoissa Valkeyn läpimeno oli 500 samanaikaisella yhteydellä kirjoituspainotteisessa kuormassa 5 prosenttia Redisiä pienempi ja lukupainotteisessa kuormassa 2 prosenttia suurempi. Ero vaihteli yhteysmäärän mukana: kyse ei ollut yksiselitteisestä Valkeyn nopeusedusta. Luonnoksessa esitetyt 32 ja 38 prosentin edut eivät vastaa opinnäytteen näitä taulukkoarvoja.

Kokeessa tuotteet ajettiin erillisinä palvelininstansseina yhden solmun Kubernetes-ympäristössä, ja kuormageneraattori toimi toisessa virtuaalikoneessa samalla fyysisellä palvelimella. Avainkäyttö jakautui epätasaisesti, ja pysyvyys oli poistettu käytöstä. Kokoonpano kertoo muistissa toimivan yksittäisen instanssin käyttäytymisestä juuri näillä kuormilla; se ei mittaa Redis 8:aa, usean solmun klusteria eikä levylle tallentavaa tuotantopalvelua.

Mittauslukujen painoa heikentää vielä se, että samaan työhön liittyvän arXiv-esijulkaisun ensimmäinen kirjoittaja on vetänyt julkaisun pois ja ilmoittanut sen sisältävän merkittäviä virheitä numeerisissa tuloksissa sekä niistä tehdyissä päätelmissä. Opinnäytteen taulukoita voi käyttää kuormakohtaisten erojen ja testiasetelman tarkasteluun, mutta niiden prosenttiluvuista ei voi johtaa luotettavaa kapasiteettilupausta migraatiolle.

Oman kuorman mittaus antaa nopeudelle oikean painon

Jos molemmat tuotteet täyttävät lisenssi- ja ominaisuusvaatimukset, suorituskykyvertailun on vastattava sovelluksen todellista työtä. Lukujen ja kirjoitusten suhde, arvokoot, kuumien avainten osuus ja samanaikaisten yhteyksien määrä voivat muuttaa tulosta. Erityisesti paljon samoja avaimia käyttävä testi mittaa eri asiaa kuin laajaan avainjoukkoon jakautuva palvelu.

Vertailussa sama laitteisto, asiakaskuorma, salaus, pysyvyysasetukset ja klusterin rakenne on pidettävä samoina. Läpimeno kertoo, kuinka monta pyyntöä järjestelmä käsittelee, mutta käyttäjälle näkyvää hitautta kuvaavat myös hitaimpien pyyntöjen vasteajat. Jos sovelluksen palvelutasotavoite koskee vasteajan häntää, pelkkä keskimääräinen pyyntömäärä sekunnissa voi johtaa väärään valintaan. Valmistajien omat nopeusväitteet ovat hyödyllistä taustaa, mutta eri kokoonpanoilla tehtyjä ajoja ei voi asettaa suoraan vastakkain.

Hallittu pilvi on erillinen päätös

Hallitussa palvelussa moottorin lisenssi ei yksin määritä saatavilla olevia versioita, päivitystapaa, hintaa tai tukea. Esimerkiksi AWS:n ElastiCache-ohje kuvaa Redis OSS -palvelusta Valkeyhin tehtävän moottoripäivityksen: mukautettua Redis-parametriryhmää käyttävän on annettava pyynnössä myös Valkeylle sopiva mukautettu parametriryhmä. AWS:n menettely koskee sen omaa hallittua palvelua, eikä se ole yleinen migraatiopolku itse ylläpidetystä Redis 8:sta Valkeyhin.

Palveluntarjoajaa valittaessa on selvitettävä, kuka vastaa päivityksistä, varmistuksista, palautuksesta ja häiriötilanteiden tuesta. Redis Cloudin tai Redis Softwaren kaupallista tukea tarvitsevan vertailukohde on myös sopimus ja sen kattama palvelu, ei vain avoimen lähdekoodin ohjelmiston lisenssi. Valkeyn BSD-lisenssi voi ratkaista ohjelmistovalinnan, mutta hallitun palvelun ehdot voivat edelleen ratkaista toimittajavalinnan.

Valinta käyttötilanteen mukaan

Itse ylläpidetyssä tavallisessa välimuistissa Valkey on vahva vaihtoehto, kun BSD-lisenssi on vaatimus ja käytössä ovat Redis OSS -perinnöstä tutut toiminnot. Redis on perusteltu jatko, kun sen omat haku- tai tietotyyppiominaisuudet ovat sovellukselle olennaisia ja valittu lisenssi sopii käyttötapaan. Redis 8:sta Valkeyhin siirtyvä arvioi lisäksi datan siirtotavan ja mahdolliset sovellusmuutokset; vanhan Redis OSS -asennuksen suoraa tiedostoyhteensopivuutta ei voi siirtää koskemaan tätä tapausta.

Hallitussa pilvessä valinta alkaa palveluntarjoajan tosiasiassa tarjoamista moottoreista, ominaisuuksista ja tukitasosta. Kaupalliseen tukeen nojaavassa ympäristössä sopimuksen vastuut ovat osa samaa päätöstä. Kun nämä rajat on selvitetty, omalla kuormalla mitattu vasteaika ja kapasiteetti voivat ratkaista jäljelle jäävän valinnan ilman, että vanhan Kubernetes-kokeen kiistanalaisille prosenttiluvuille annetaan liikaa painoa.

Lue myös:

Jaa:

Tilaa uutiskirjeemme

Saat tuoreimmat Web3-, tekoäly- ja kryptouutiset suoraan sähköpostiisi.

0