KeyDB որպես [հնարավոր] փոխարինում Redis-ի

Հաբրում «Redis-ի ավելի արագ այլընտրանքի» մասին կարծիքներ չկային՝ KeyDB. Կստանանք բավականին նոր փորձ այն օգտագործելուց, ցանկանում ենք լրացնել այս բացը:

Նախապատմությունը բավականին սովորական է. մի անգամ, մեծ տրաֆիկի ճնշման արդյունքում, նկատվեց նշանակալի մարամասնության անկում (ինքնին՝ պատասխանման ժամանակի): Այդ պահին, դժբախտաբար, հաջողվեց իրական հաշվարկ անցկացնելու, հետեւաբար, հետագայում պլանավորվեց մի շարք բեռնման փորձարկումներ: Փորձարկումներից հետո հաջողվեց հայտնաբերել բարակ մոտեցումը, որը դարձավ Redis-ի տվյալների բազայի կաշառքը: Ինչպես հաճախ бывает, խնդիրը չէր հնարավոր լուծել այս պահին և ճիշտ ուղով՝ ծրագրավորողների (աշխատանքի տրամաբանության փոփոխությամբ): Ուստի սկսվեց հետաքրքրություն և ցանկություն հաղթահարելու իրավիճակը շրջանցիկ ճանապարհով: Այսպես անվանվեց այդ հոդվածը:

Մասնագիտական խնդիրը

Redis-ի մասին ընդհանուր առմամբ

Չնայած, որ շատերին հայտնի է, Redis-ը միակողմանի տվյալների բազա է: Դժվար է լինել ավելի ճշգրիտ, սակայն նա այդպիսին է օգտատերերի տվյալների հետ աշխատելիս: Ուսումնասիրողական, ներքին գործընթացները Redis-ն անցած են հետևյալ բաղկացուցիչ որոնցով: Հետաքրքիր է, որ այս փոփոխությունը ազդել է միայն բեռնվածության փոքր մասի վրա, քանի որ հիմնական աշխատանքը վերաբերում է օգտատերերի տվյալներին:

Այս թեմայի շուրջ շատ ակնարկներ են արվել, սակայն Redis-ի ծրագրավորողները վիճակի առաջ չէին փորձում իրականացնել լիարժեք համաժամացություն, նշելով, թե որքանով դա դժվարացնի ծրագիրը և կբարձրացնի ծախսերը, ինչպես նաև կավելացնի տեղեկությունների քանակը: Նրանց դիրքորոշումը այն է, որ եթե դուք հանդիպում եք մեկ ճյուղի խնդիրներին՝ դուք ունեք խնդիր ծրագրավորման արշավին և պետք է փոխեք այդ արշավում: Այնուամենայնիվ, օգտատերերի շրջանում կան նաև «այլ ճամբարի» մարդիկ՝ ովքեր բախվել են մեկ միջուկի ու հաստատում են, որ Redis-ը ինքնին ստեղծում է շիշը: Ցավոք, իրական մեծ բեռի դեպքում՝ վաղ թե ուշ կարող է հանդիպել այս խնդրին, ինչը տեղադրում է նշանակալի սահմանափակումներ ծրագրի արշավի վրա կամ ստիպում է բարդացման:

Ես մտադրություն չունեմ գնահատել այն կամ այլ կարծիքներ: Նրան փոխարեն, ես կհամաձայնակցեմ մեր կոնկրետ դեպքով և նշեմ, թե ինչպես լուծեցինք այն:

Մեր դեպքը

Մեր նախագծերից մեկում մենք հանդիպեցինք այն, որ ծրագրավորողների թիմը սահմանափակեց շատ ագրեսիվ տվյալների կաշառք PostgreSQL-ից Redis-ի միջոցով: Սա միակ ճանապարհն էր, որը խելահեղ ծանրաբեռնվածության ժամանակներից փրկեց PostgreSQL-ը և վերջապես՝ ծրագիրը:

Բեռնման փորձարկումների շարքից հետո մենք անցկացրեցինք իրավիճակի վերլուծություն և հայտնաբերեցինք, որ Redis-ը բախվում էր մեկ միջուկի (ինչպես կոչվում է 'միջտեղ՝'), այնուհետև տեղի ունեցավ բավականին արագ անկում ծրագրի աշխատանքի մեջ: «Կճիթավորումը» ուներ երկրաչափական прогрессիա. երբ հասնում էր Redis-ի արտադրողականության սահմանին, ամեն ինչ կանգ էր առնում:

Այսպիսով, դա մոտավորապես այս կերպ էր.

New Relic-ն հստակորեն հայտնաբերել է խնդիրը․

Բայց ահա վիճակագրությունը գործողության վերաբերյալ `get` Redis-ում․

Այն բանից հետո, երբ խնդիրը մանրամասն ներկայացվեց զարգացման ჯგუფին, պարզվեց, որ «այժմ խնդիրը լուծել հնարավոր չէ»։ Հետեւաբար սկսեցինք լուծումների որոնումը շահագործման կողմից, և պատասխանն արդեն նշված KeyDB-ն էր։

Այո, սակայն մինչև դրա վերանայման մեկնարկը, անհրաժեշտ է նշել, որ նախագծում օգտագործվում է standalone Redis, քանի որ Sentinel-ի հիման վրա կլաստերային լուծումը զգալիորեն զիջում է ինչպես հապաղումների (latency) հարցում։ Ա evidente լուծումն էր բազմաթիվ կոշտեր ստեղծելը՝ և թող հավելվածը շրջեր ամենուր, բալանսային թողնի։ Սակայն, քննարկելով ծրագրավորողների հետ, մենք ստիպված էինք այս տարբերակը մերժել՝ հաշվի առնելով հավելվածի ակտիվ և բարդ կոշտերի invalidate մեխանիզմը։ Այդ же խնդիրը տարածվում էր նաև կոշտի շարդավորման վրա։

KeyDB-ի արագ վերանայում

Մեր խնդրի հնարավոր լուծումը որոնելիս մենք հայտնաբերեցինք KeyDB կոչվող հավելվածը․Ադրբեջանական Redis-ի ֆորկ է, որը մշակվել է Կանադական ընկերության կողմից և տարածվում է BSD ազատ լիցենզիայի ներքո։ Նախագիծը չափազանց երիտասարդ է՝ գոյություն ունի 2019-ի սկզբից։ Հիմքը հետևյալն է, որ հեղինակները նույնպես մի ժամանակ հանդիպել են Redis-ի սահմանափակումներին… և որոշել են ստեղծել իրենց ֆորկը։ Հարկ է նշել, որ այն ոչ միայն լուծել է հայտնի խնդիրները, այլև ստացել է հավելյալ հնարավորություններ, որոնք հասանելի են բացառապես Redis-ի.enterprise տարբերակում։

KeyDB-ի մասին ավելի մանրամասն ծանոթանալու ցանկացողներին առաջարկվում է լավ մտավոր հոդված Medium-ում,որը ներկայացնում է տվյալ բազան և ընդհանրական benchmark-ները, որոնք համեմատում են այն իր «ծնողի»՝ Redis-ի հետ։

Առաջին հերթին, KeyDB-ում մեզ գրավել է մեր խնդիրների հնարավոր լուծումը, ինչպես նաև որոշ լրացուցիչ ֆիթերներ։ KeyDB-ի օգտագործումը խոստանում էր հետևյալ առավելությունները․

• իրական բազմաթղթայնության ստացում․
• Redis-ի լիակատար և լիովին համատեղելիություն (մեր համար սա հատկապես կարևոր էր, քանի որ հավելվածի կողմից որևէ փոփոխություն իրականացելը չէր հնարավոր), ինչը նաև ենթադրում էր անցկացնել մայիսի գործընթացը առանց դժվարությունների․
• S3 պահպանման մեջ встроенный бэкп ап-механизм․
• դյուրին внедրումներ ունեցող active-репликация․
• ապահովում простая кластеризация և шардирование без Sentinel и других дополнительных программ․

GitHub-ում ավելի քան 3000 աստղեր և մեծ թվով ներդրողներ նույնպես հուսադրող տեսք ունեին։ Ապառիկն ակտիվորեն զարգանում է և աջակցվում, ինչը լավ նկատվում է հանձնաձողերում, issues-ի քննարկումներում, ինչպես նաև փակված (ընդունված) PR-ների մեջ։ Էկոլոգիական մենեջերի արձագանքը բոլոր ոլորտներում միշտ բարեկամական և արագ է։ Ամեն դեպքում, փաստարկները բավարար էին։

Միգրացիա և արդյունքներ

Թեև միգրացիայի նախագիծն իր տեսակով այցելո՞նդ էր (KeyDB-ի նորության պատճառով), սնուցել շատ բան չկար: Վերջապես, փոփոխություններն վերադարձրելու համար շատ արագ և հեշտ է — բարեբախտաբար, ամբողջ ենթակառուցվածքը տեղադրված է Kubernetes-ում, իսկ ներմուծված մեխանիզմները Rolling Update իրականացնում են այսպիսի խնդիրները:

Ընդհանրապես, մենք պատրաստեցինք Helm ձևանմուշներ, փոխեցինք ծրագիրը փորձարկման միջավայրում դեպի նոր DB և ներկայացրինք ամենը, հանձնելով QA բաժնին:

Ստեղծվեց փորձաքննություն, որը շարունակվեց մոտ մեկ շաբաթ, և որի մանրամասներին մենք չգնացինք: Իմանալու համար, պատվիրատուն ստուգեց Redis-ի ստանդարտ գործառույթները PHP վարորդի միջոցով phpredis, ինչպես նաև անցկացրեց QA փորձարկում օգտագործողի ամպային միջավայրի: Այնուհետև մեզ տրամադրեցին zeleny boite կանաչ լույս: Ոչ մի կողմնակի ազդեցություն նոր ծրագրի օգտագործման մեջ չնկատվեց: Բայց գործացրած ծրագրի օգտագործման տեսանկյունից ընդհանրապես ոչինչ չի փոխվել.

Պետք է նշել, որ մենք նաև config-ում որևէ բան չենք փոխել: Գլխապտույտ — պարզապես փոխել ենք օգտագործվող կերպարը: Նույնը վերաբերում է մոնիտորինգին և մետրիքի արտահանմանը Prometheus-ում: ոչսի նորմալ գործառույթներով հիանալի աշխատում է KeyDB-ի հետ և առանց որևէ փոփոխության: Таким образом, կարող են վստահորեն ասել, որ օգտվելով այդ առկայությամբ, սա պարզապես իդեալական հանգումն էր:

Բ thanks արդեն, հետո ծրագիրը նոր DB-ին պատրաստելուց հետո կարող են բաներ չճիշտել, իսկ `աստիճանական միջոց` — թողնել այն այդպես, որպեսզի մի քանի ժամանակ մարտում աշխատի: Բայց եթե ուզում եք տեսնել կատարողականի ավելացումներ (կամ ընդհանրապես որևէ փոփոխություններ), ապա մի մոռացեք, որ առաջարկությամբ KeyDB-ի պարամետր, որը պատասխանատու է մոլորակների (server-threads), հավասար է մեկի, այսինքն DB-ն գործում է նույն ձևով, ինչպես Redis.

Տեղափոխությունից, փորձարկումից և որոշ ժամանակ անց նոր ծրագրի վրա (KeyDB-ով) մենք որոշեցինք կրկնել բեռնման փորձարկումը նույն պարամետրերով, որոնք օգտագործվում էին Redis-ի համար: Ինչպիսիք էին դրա արդյունքները?..

CPU օգտագործման գծապատկերում անմիջապայլ դարձան «երես կտրելու» խնդիրները՝ մի միջինում: Ապրանքը սկսեց օգտագործել գրեթե մատչելի ռեսուրսները:

Հետագայում ես փորձեցի բավականին ուժեղ «ոտնհասություն» ծրագրում և տեսա օգտագործման մինչ երեք միջինների...

New Relic-ի ցուցումներով, վեբ ծրագրումը որպես ընդհանուր, կապված նման բեռնվածություն, սկսեց հայտնվել ավելի ադեկվատ: Որոշ կատարողականի անկում հեշտությամբ նկատվեց, սակայն, համեմատելով նույն գծի հետ՝ կարող եք ինքներդ գնահատել մեծ առաջընթաց:

Նոր DB (KeyDB) ուշացման ցուցանիշը նույնպես վատացավ, բայց մնում էր թույլատրելի արժեքների շրջանակներում:

Հաջորդ գծանկարում լավ կարելի է տեսնել, որ հարցումների քանակը KeyDB-ի նկատմամբ համախառն է:

Լրացուցիչ գիտելիքների վերաբերյալ, կարելի է ասել, որ թե Redis-ը, թե KeyDB-ն նկատելիորեն նվազեցնում են արդյունավետությունը latency-ում (40 մս+), երբ չափազանց շատ են զուգահեռ կապերը (1000+): Մեր դեպքում, սակայն, վեբ հավելվածը կարողանում էր «նվազեցնել» Redis-ի latency-ն անգամ 400 զուգահեռ կապերի ժամանակ, մինչդեռ KeyDB-ի համար այդ ծանրաբեռնվածությունը մնում էր ընդունելի։

Արդուկները

Այս օրինակով շատ լավ երևում է բաց աղբյուրների համայնքի ուժն այն նախագծերի զարգացման հարցում, որոնցում նրանք հետաքրքրված են: Ինտերնետում հանդիպել եմ բացառիկ արտահայտության, որի ընդհանուր իմաստը կարելի է տալ հետևյալ կերպ. «Մեկ մեծ ընկերություն ստեղծում է հետաքրքիր ապրանք, որոշ ֆունկցիաներ բաց է անում, բայց ամենակարևոր հատվածը թողնում է վճարովի: Համայնքը օգտագործում է, և հետո ինչ-որ մեկը ձեռքը բարձրացնում է և ստեղծում է fork, որն իրականացնում է այն վճարովի ֆունկցիաները և բացում է դրանք բոլորի համար»: Вот KeyDB-ը՝ հենց այդպիսի դեպք է։

ԱյսMigration-ի մասին բանավեճ թվականին անցավ անսպասելիորեն հեշտ, մենք չեն ստացել նմանապես նշանակալի ավելացում արդյունավետության, ինչը կարելի էր ակնկալել, տեսնելով KeyDB հեղինակների գրաֆիկաները... Սակայն դա ընդամենը մեր մասնավոր դեպքն է, ուր կարող են լինել բազմաթիվ շեղումներ, որոնք վերաբերում են նաև հայտնի ծրագրերի ճարտարապետությանը (օրինակ, մեծ թվով հրամաններ `get` Redis-ում փոխարեն ավելի արդյունավետ միասնական հարցումների տարբերակի mget...) Կոճով, դրական արդյունքների հասել ենք, և նրանց հետ` շատ օգտակար ֆունկցիաներ, որոնք մենք դեռ պետք է ներդնենք մոտ ապագայում։

Ընդհանուր առմամբ, KeyDB-ն ​​դիտվում է խոստումնալից. օգտագործման պրակտիկ փորձ ավելի ստանալու և նախագծի ինքնակառավարման ընթացքում կհամարենք դրա կիրառման հնարավորությունը և այլ իրավիճակներում։

Բայց մի մոռացեք, որ այս հոդվածը պետք չէ դիտարկել որպես ուղեցույց (և առավել ևս՝ կոչ) գործողությունների՝ Redis-ից KeyDB-ին զանգվածային կերպով հրաժարվելու համար: Չ despite մեր դրական փորձը, ակնհայտ է, որ դա չէ արծաթե օղակը: Այս իրավիճակը շատ հատուկ էր: Կոնկրետ այս՝ ժամանակավոր խնդիրը լուծելու համար, երբ դա արագ և նվազագույն ծախսերով պետք է անել, այդպիսի լուծումը оправдилось: KeyDB-ը արդիական կլինի ձեր դեպքում՞: Վստահաբար, հիմա դուք գիտեք, որ նման հնարավորությունը կա։

P.S.

Նաեւ կարդացեք մեր բլոգում:

• «Վիճակագրական տվյալներ և Kubernetes (նայման և զեկուցման տեսանյութ)»;
• «Cassandra-ի փոխանցումը Kubernetes-ում: առանձնահատկություններ և լուծումներ»;
• «Դժվարությունների հետ կապված MongoDB-ի տեղափոխումը Kubernetes մոնտաժում»;
• «RabbitMQ-ի առանց անհանգստության տեղափոխումը Kubernetes».

Ընտանիք: habr.com