Redis или Valkey: лиценца је тек почетак избора кеша

За једноставан кеш и прелазак са старијег Redis-а, Valkey је практичан избор ако је важна BSD лиценца. Redis Open Source је јачи кандидат када апликација користи JSON, временске серије, вероватносне структуре или претрагу. Предност у брзини не следи из имена производа: зависи од команди, броја веза, додељених ресурса и начина чувања података.

Пре поређења брзине треба утврдити услове лиценце, пописати функције које апликација користи и проверити пут миграције. Посебно је важно са које верзије Redis-а се прелази. Клијент који може да се повеже са оба сервера још не значи да нови сервер може да учита постојећу датотеку са подацима.

Лиценца одређује услове употребе

Преглед Redis лиценци наводи да Redis Open Source од верзије 8 нуди избор између AGPLv3, RSALv2 и SSPLv1 и да су RediSearch, RedisJSON, RedisTimeSeries и RedisBloom укључени у то издање под истим избором лиценце. AGPLv3 је лиценца отвореног кода са обавезама које су нарочито важне при изменама серверског кода доступног преко мреже. RSALv2 и SSPLv1 омогућавају приступ изворном коду, али нису лиценце отвореног кода.

Valkey је BSD пројекат под окриљем Linux Foundation-а. Намењен је кеширању, редовима порука и употреби као примарна база. Дозволан модел лиценцирања може да поједностави избор тиму који жели да сам одржава инстанцу или да промени добављача услуге. Лиценца, међутим, не одређује ко пружа оперативну подршку, колико она кошта нити колико брзо добављач реагује на квар.

Иста разлика важи за Redis: право на коришћење Redis Open Source-а није уговор о комерцијалној подршци. Трошак избора обухвата и људе који одржавају систем, надзор, резервне копије и услове управљане услуге ако се она користи. Зато је разумно лиценцу и подршку поредити као одвојене ставке, уместо да се бесплатан приступ коду изједначи са бесплатним радом система.

Функције одређују колико посла доноси замена

За кеш заснован на кључевима, хешевима, листама и скуповима оба система улазе у ужи избор. Разлика расте када апликација над истим подацима извршава упите над JSON документима, претражује садржај, бележи временске серије или користи вероватносне структуре. Те функције су укључене у Redis Open Source; Valkey подржава модуле, али то не значи да сваки Redis модул и свака његова команда имају истоветну замену.

Инвентар стварних команди зато говори више од описа архитектуре. У њега спадају команде које позива апликација, Lua скрипте, зависности од модула и правила приступа. Ако су JSON и претрага већ део пословне логике, прелазак може да захтева измене упита и начина на који се подаци уписују. Ако инстанца само чува краткотрајне вредности по кључу, додатне уграђене функције можда не доносе корист која оправдава њихов избор.

Постоји и разлика између функције коју сервер поседује и функције коју изабрана услуга заиста ставља на располагање. Код управљане понуде важни су подржана верзија, омогућени модули и ограничења конфигурације. За самосталну инстанцу исти посао пада на тим који пакује, ажурира и надзире сервер. То је посебно важно ако кеш временом постане место на ком апликација чува податке које не може лако да обнови.

Компатибилност зависи од полазне верзије и података

Valkey-ово упутство за миграцију наводи компатибилан протокол, конфигурацију и RDB/AOF формате за прелазак са Redis OSS верзије 7.2 и ранијих издања, али упозорава да датотеке које прави Redis Community Edition од верзије 7.4 нису компатибилне са Valkey-ом. Постојећи Redis клијенти могу да се повежу преко RESP протокола. То решава везу са сервером, док команде, скрипте и модуле које апликација користи треба посебно проверити.

За компатибилну полазну верзију могуће је копирати снимак базе или поставити Valkey као реплику пре пребацивања саобраћаја. Копирање снимка подразумева прекид рада док се стари сервер заустави, а нови учита податке. Репликација може да скрати прекид, али захтева контролу уписа током пребацивања да промене не остану само на старом серверу.

Када датотека није компатибилна, њено копирање не може бити план миграције. Тада је потребан други начин преноса, уз проверу да су вредности и рокови истека сачувани како апликација очекује. Разлика у улози података мења и прихватљив ризик: краткотрајан кеш који се поново попуњава може да поднесе другачији прекид него сесије или стање које мора да преживи прелазак.

Пропусност, репна латенција и ресурси причају различите приче

Мерење Ефраина Гараја поредило је Redis 8.10.1 и Valkey 9.1.2 у засебним контејнерима, са једнаким ограничењем процесора за сервере и посебним ресурсима за клијента који шаље захтеве. Мерене су и подразумеване поставке и конфигурације са I/O нитима. То је користан пример како се мења исход када се промени конфигурација, али није рангирање свих могућих начина употребе.

Са четири додељена језгра, без груписања захтева, обе конфигурације са I/O нитима обрадиле су више од 480.000 операција у секунди. Аутор је утврдио да је у том режиму тест достигао границу коју поставља цео пут захтева кроз клијента и мрежу, па блиске бројеве не тумачи као једнак капацитет сервера. Уз груписање по 16 захтева, забележено је око 4,21 милион операција у секунди за Redis и 4,04 милиона за Valkey. То је резултат тог оптерећења и тих подешавања.

При снимању базе током мешовитог оптерећења, латенција најспоријег дела захтева, P99,9, порасла је код Redis-а са 0,97 на 2,11 милисекунди, а код Valkey-а са 1,20 на 3,49 милисекунди када су биле укључене четири I/O нити. У другом режиму Valkey је после укључивања I/O нити користио више процесорског времена без добитка у пропусности. Потрошња меморије по кључу била је блиска у једном учитавању, које аутор третира као оријентацију, а не као прецизну меру предности.

Често помињани рад о Kubernetes поређењу повучен је уз напомену да садржи велике грешке у бројчаним резултатима и закључке које подаци не подржавају. Његове ранг-листе зато не могу бити основ за избор. Мерење у засебним контејнерима такође не обухвата продукциони Kubernetes кластер, реплике и све мрежне услове; показује зашто уз пропусност треба гледати P99 и P99,9 латенцију, CPU и вршну меморију за сопствено оптерећење.

Избор према улози кеша

За нов кеш који користи основне структуре, Valkey је јасан кандидат када тиму одговара BSD лиценца и жели пројекат под окриљем Linux Foundation-а. Прелазак са компатибилног старијег Redis издања додатно му иде у прилог, нарочито ако су подаци обновљиви. Ипак, стварни обим посла одређују коришћене команде, скрипте, начин чувања података и потреба за подршком.

Redis Open Source има предност када су његове уграђене структуре и претрага већ део апликације или би замениле засебне компоненте које тим одржава. AGPLv3 пружа опцију отвореног кода, уз обавезе које организација треба да процени за свој начин измене и употребе сервера. Комерцијална подршка остаје засебан избор, без обзира на производ.

Када је брзина пресудна, меродавна је конфигурација која испуњава захтеве апликације у расположивом процесорском и меморијском буџету. Однос читања и уписа, величина вредности, број истовремених веза, груписање захтева и чување података могу да промене и пропусност и репну латенцију. Зато највећи број операција из једног туђег теста не решава избор ако је цена миграције висока или ако латенција расте баш у режиму који је апликацији важан.

Прочитајте и:

• Redis или Memcached: једноставан cache може да преокрене победника
• Ahrefs или Semrush: јефтинији почетак није и јефтинији тим
• CrewAI или AutoGen: лакши почетак плаћа се другачијом контролом