Redis թե Valkey․ նույն արմատը չի նշանակում նույն արագությունն ու լիցենզիան

|Հեղինակ: QUASA-ի խմբագրական թիմ|6 րոպե ընթերցանություն
Redis թե Valkey․ նույն արմատը չի նշանակում նույն արագությունն ու լիցենզիան

Եթե համակարգն օգտագործում է Redis-ի հիմնական հրամաններն ու տվյալների կառուցվածքները, Valkey-ին անցումը կարող է համեմատաբար ուղիղ լինել։ Եթե այն կախված է Redis-ի նոր հնարավորություններից, հատուկ մոդուլներից կամ ուշացման խիստ շեմից, ընդհանուր ծագումը բավարար չէ տեղափոխում ընտրելու համար։

Որոշումը երեք մաս ունի՝ որ լիցենզիան է ընդունելի, արդյոք անհրաժեշտ գործառույթներն աշխատում են նպատակային տարբերակում, և ինչ արդյունք են տալիս երկու համակարգերը նույն ծանրաբեռնվածության տակ։ Թողունակության հրապարակված թիվը միայն վերջին հարցի մասնակի պատասխանն է. առանց փորձի պայմանների այն չի որոշում, թե որն ավելի արագ կլինի տվյալ ծառայության համար։

Լիցենզիան կախված է Redis-ի տարբերակից

Valkey-ի պաշտոնական նկարագրությունը համակարգը ներկայացնում է որպես BSD լիցենզիայով բաց կոդով հիշողային տվյալների պահոց, որը կարող է ծառայել որպես քեշ, հաղորդագրությունների միջնորդ և տվյալների բազա։ BSD-ի թույլատրող պայմանները կարևոր են հատկապես այն թիմի համար, որը փոփոխում կամ տարածում է սերվերի կոդը և ցանկանում է պահպանել այդ ճկունությունը։ Ծառայությունը պարզապես օգտագործելու և փոփոխված սերվերը ուրիշներին տրամադրելու իրավական հարցերը, սակայն, նույնը չեն։

Redis-ի լիցենզիաների ցանկում մինչև 7.2 տարբերակները նշված են որպես BSD-3-Clause, 7.4–7.8 տարբերակները՝ RSALv2 կամ SSPLv1, իսկ Redis 8-ից հասանելի է նաև AGPLv3 ընտրությունը։ Հետևաբար Redis-ի բոլոր թողարկումներին մեկ լիցենզիա վերագրելը սխալ որոշման կհանգեցնի։ AGPLv3-ը բաց կոդով լիցենզիա է, բայց դրա փոխադարձ բացման պայմանները տարբերվում են Valkey-ի BSD պայմաններից. գնահատման միավորը կոնկրետ թողարկումն ու օգտագործման ձևն են։ Redis-ի առևտրային արտադրանքներն էլ առանձին լիցենզավորման պայմաններ ունեն։

Արձանագրության համատեղելիությունը որտեղ է ավարտվում

Valkey-ի տեղափոխման ուղեցույցը Redis OSS 7.2 և ավելի հին տարբերակների համար նշում է RESP արձանագրության, այդ շրջանի կազմաձևման և RDB/AOF ֆայլերի համատեղելիությունը, բայց Redis Community Edition 7.4 և ավելի նոր տարբերակների ստեղծած տվյալների ֆայլերը համարում է անհամատեղելի։ Առաջին խմբում հաճախորդային առկա գրադարանը կարող է միանալ Valkey-ին առանց կոդի փոփոխության, իսկ պահված տվյալների համար հնարավոր են snapshot-ի պատճենում կամ կրկնօրինակում։ Ընտրությունը կախված է գրառումների ընթացքից և թույլատրելի դադարից. ֆայլի պատճենումը պահանջում է նաև հետևել, որ տեղափոխման պահին նոր գրառումներ չկորչեն։

Ավելի նոր Redis-ից տեղափոխվելիս աշխատող RESP կապը չի նշանակում, որ նրա RDB ֆայլը կբացվի Valkey-ում։ Այդ դեպքի համար տվյալները պետք է փոխանցել այլ եղանակով և առանձին գնահատել դադարի ու վերադարձի պայմանները։ Նույն տարբերությունը կա նաև կիրառության մակարդակում. հաջող միացումը ստուգում է կապն ու արձանագրությունը, մինչդեռ հրամանների արդյունքները, Lua սցենարները, բանալիների ժամկետանցումը և կլաստերի վարքագիծը երևում են միայն համապատասխան աշխատանքային հոսքը գործարկելիս։

Սա բացատրում է, թե երբ տեղափոխումը մոտ է սովորական թարմացմանը։ Եթե քեշը պահում է վերականգնվող տվյալներ, օգտագործում է հիմնական կառուցվածքները և հենվում է համատեղելի Redis OSS տարբերակի վրա, աշխատանքը հիմնականում տեղակայման ու վարքագծի ստուգման խնդիր է։ Եթե տվյալները դժվար է վերակառուցել կամ հավելվածը կախված է նոր սերվերային հնարավորություններից, նույն հաճախորդային գրադարանի պահպանումը տեղափոխման աշխատանքի միայն փոքր մասն է։

Մոդուլը կարող է աշխատել, իսկ հնարավորությունը՝ բացակայել

Valkey-ի տեղափոխման փաստաթղթերում նշված RedisModule_ API-ի համատեղելիությունը վերաբերում է այդ API-ով գրված մոդուլներին։ Այն ինքնաբերաբար չի տալիս Redis-ում հասանելի յուրաքանչյուր մոդուլի նույն իրականացումը, տարբերակը կամ հրամանների ամբողջությունը։ Ուստի մոդուլային կախվածությունը պետք է նկարագրել ըստ կիրառության իրական հարցումների, ոչ թե միայն ըստ այն բանի, որ երկու սերվերն էլ աջակցում են մոդուլներ։

Redis-ի նոր բաց թողարկումներում RedisJSON-ը, RediSearch-ը, RedisTimeSeries-ը և RedisBloom-ը ներառված են հիմնական տարածման կազմում։ JSON դաշտերով որոնում, երկրորդային ինդեքսներ կամ ժամանակային շարքերի հրամաններ օգտագործող ծառայության համար սա գործառութային տարբերություն է։ Valkey-ի միջավայրում այլ մոդուլ գտնելը կարող է լուծել պահանջի մի մասը, բայց համարժեքությունը պետք է հաստատել հրամանների իմաստով, ինդեքսների կառուցմամբ և արդեն պահված տվյալների փոխանցմամբ։ Այդ աշխատանքը կարող է գերազանցել բուն սերվերը փոխելու ծախսը։

Ինչու հրապարակված արագության թվերը տարբեր պատասխաններ են տալիս

Valkey-ի կատարողականության վահանակը իր թողարկումները չափում է AWS c8g.metal-48xl մեքենայի վրա՝ 512 բայթ տվյալներով, pipeline-ի 1 և 10, ինչպես նաև մուտք-ելքի հոսքերի 1 և 9 կարգավորումներով։ Սերվերն ու փորձարկող հաճախորդը բաժանված են NUMA հանգույցների, իսկ ցանցային ընդհատումները կարգավորված են։ Սա օգտակար է Valkey-ի թողարկումների միջև փոփոխությունը դիտելու համար, սակայն վահանակի չափումները Redis-ի հետ նույն պայմաններում կատարված համեմատություն չեն։ Մեծ մեքենայի, խմբաքանակային հարցումների և կարգավորված միջավայրի արդյունքը փոքր ծառայության ուշացման մասին ուղիղ եզրակացություն չի տալիս։

Ումեոյի համալսարանի համեմատական թեզում ընթերցումներով ծանրաբեռնված փորձի ժամանակ Valkey-ի թողունակությունը Redis-ից 39% ցածր էր 200 միաժամանակյա կապի դեպքում, բայց 20% բարձր՝ 1500 կապի դեպքում։ Այս շրջադարձը վերաբերում է հենց այդ փորձի Redis և Valkey տարբերակներին ու պայմաններին, ոչ թե բոլոր տեղակայումներին։ Գրառումներով ավելի ծանրաբեռնված փորձերում Redis-ը առավելություն ուներ միաժամանակության միջին մակարդակների մեծ մասում, իսկ բարձր մակարդակներում տարբերությունը փոքրացավ կամ փոխեց ուղղությունը։ Հետևաբար «ավելի արագ» գնահատականը պետք է ուղեկցվի առնվազն հարցումների խառնուրդով և միաժամանակյա կապերի քանակով։

Այդ փորձը Redis 7.2.7-ը և Valkey 8.0.2-ը տեղակայել էր Kubernetes-ում՝ առանձին սերվերներով, առավելագույնը 2 պրոցեսորային միջուկով և 8 GiB հիշողությամբ։ Նախապես բեռնվել էր մոտ 4,8 միլիոն գրառում՝ 1 KiB արժեքներով. փորձարկվել էին ընթերցման և գրառման 50/50 ու 95/5 հարաբերակցությունները, իսկ յուրաքանչյուր ծանրաբեռնվածությունն ու միաժամանակության մակարդակը կրկնվել էին երեք անգամ և միջինացվել։ Pipeline-ը և կայուն պահպանումը անջատված էին։ Այս պայմանները տարբեր են Valkey-ի վահանակի սարքավորումից, տվյալների չափից ու pipeline-ի կարգավորումից, ուստի դրանց թվերը մեկ ընդհանուր վարկանիշի մեջ միավորել չի կարելի։

Թեզում չափվել են նաև ուշացման բարձր պերսենտիլները։ Դա էական է, երբ ծառայության համար հազվադեպ դանդաղ պատասխանը նույնքան կարևոր է, որքան վայրկյանում կատարվող գործողությունների քանակը։ Արդյունքների սահմանն էլ հստակ է. առանձին տեղակայումը չի նկարագրում կլաստերի բաժանումը կամ կրկնօրինակումը, անջատված պահպանումը չի ցույց տալիս սկավառակի ազդեցությունը, իսկ Helm-ի լռելյայն կարգավորումները կարող էին մասնակցել չափված տարբերություններին։

Որ չափումից հետո ընտրությունը հիմնավոր կլինի

Սեփական փորձի մատրիցան պետք է արտացոլի արտադրական ծանրաբեռնվածությունը՝ հրամանների իրական խառնուրդը, փոքր ու մեծ արժեքները, քիչ ու շատ միաժամանակյա կապերը, pipeline-ով և առանց դրա աշխատանքը։ Եթե ծառայությունը պահպանում է տվյալները RDB-ով կամ AOF-ով, չափումը պետք է ներառի հենց այդ կարգավորումը։ Երկու թեկնածուների համար նույնը պահեք մեքենան, հաճախորդը, նախապես բեռնված տվյալների ծավալը և տաքացման ընթացքը, որպեսզի փոխվող պայմանը սերվերը լինի։

Թողունակության հետ գրանցեք նաև բարձր պերսենտիլների ուշացումը, պրոցեսորի ու հիշողության օգտագործումը և պահպանումից առաջացած տարբերությունը։ Կլաստեր օգտագործող ծառայության համար առանձին սերվերի փորձը բավարար չէ. բաժանման, կրկնօրինակման և հանգույցի խափանման պահվածքը վերաբերում է այլ տեղակայման։ Համեմատության մեջ արտադրական շեմն է որոշիչը. նույնիսկ բարձր թողունակություն ունեցող տարբերակը կարող է անհարմար լինել, եթե նրա դանդաղ հարցումները խախտում են ծառայության ուշացման պահանջը։

Հիմնական հրամաններով աշխատող և BSD պայմաններն առաջնահերթ համարող թիմի համար Valkey-ը իրատեսական թեկնածու է։ Redis-ի ներառված մոդուլներից կամ նոր հնարավորություններից կախված թիմի համար Redis-ում մնալը կարող է խնայել գործառութային տեղափոխման աշխատանքը։ Երբ որոշումը հիմնականում կախված է արագությունից, հրապարակված չափումներն օգնում են ընտրել փորձի պայմանները, իսկ վերջնական ընտրությունը տալիս է սեփական ծանրաբեռնվածությամբ համադրելի արդյունքը։

Կարդացեք նաև:

Կիսվել:

Բաժանորդագրվեք մեր տեղեկագրին

Ստացեք Web3-ի, ԱԲ-ի և կրիպտոյի վերջին լուրերն անմիջապես ձեր էլ. փոստին։

0