Redis üçün [potensial] əvəz kimi KeyDB

Habré-də "Redisə daha sürətli alternativ" haqqında heç bir rəy yox idi - KeyDB. Onun istifadəsində kifayət qədər yaxın təcrübə qazanaraq, bu boşluğu doldurmaq istərdim.

Arxa fon olduqca bayağıdır: bir gün, böyük bir trafik axını ilə tətbiqin performansında (yəni cavab müddəti) əhəmiyyətli dərəcədə pisləşmə qeydə alındı. O zaman, təəssüf ki, baş verənlərin normal diaqnozunu aparmaq mümkün olmadı, buna görə də sonradan bir sıra yük testləri planlaşdırıldı. Onları apardıqdan sonra biz Redis-də verilənlər bazası önbelleği olan bir darboğaz aşkar edə bildik. Tez-tez olduğu kimi, problem dərhal və düzgün şəkildə həll edilə bilmədi - tərtibatçılar (işin məntiqini dəyişdirərək). Buna görə də, maraq və vəziyyəti dairəvi şəkildə aradan qaldırmaq istəyi işə düşdü. Bu məqalə belə ortaya çıxdı.

Məsələlər

Ümumiyyətlə Redis haqqında

Bir çox insanın bildiyi kimi, Redis tək yivli verilənlər bazasıdır. Daha dəqiq desək, istifadəçi məlumatları ilə işləmək kontekstində belədir. Axı, dördüncü versiyadan bəri Redis-in xidməti, daxili əməliyyatları köçürülmüşdür paralel icra üçün. Bununla belə, bu dəyişiklik iş yükünün yalnız kiçik bir hissəsinə təsir etdi, çünki işin əsas hissəsi istifadəçi məlumatlarında aparılır.

Bu mövzuda saysız-hesabsız nüsxələr sındırıldı, lakin Redis tərtibatçıları inadla tam paralellik tətbiq etməkdən imtina edərək, bunun tətbiqi nə qədər çətinləşdirəcəyini və əlavə xərcləri artıracağını, həmçinin daha çox səhv əlavə edəcəyini qeyd edirlər. Onların mövqeyi belədir: bir nüvəli problemlə qarşılaşırsınızsa, tətbiqin arxitekturasında probleminiz var və onda nəyisə dəyişdirmək lazımdır. İstifadəçilər arasında "başqa bir düşərgə" də var - bir nüvədə ilişib qalan və Redisin özü üçün darboğaz yaratdığını iddia edənlər. Həqiqətən böyük yüklər halında - gec-tez - arxitekturaya əhəmiyyətli məhdudiyyətlər və / və ya məcburi ağırlaşmalar qoyan bu problemlə qarşılaşmaq qaçınılmazdır.

Mən bu və ya digər rəyi dəyərləndirməyəcəyəm. Əvəzində konkret işimizi və onu necə həll etdiyimizi paylaşacağam.

Bizim işimiz

Layihələrdən birində biz inkişaf komandasının Redis vasitəsilə verilənlər bazasından (PostgreSQL) məlumatların son dərəcə aqressiv keşləşdirilməsini konfiqurasiya etməsi faktı ilə qarşılaşdıq. Bu, qəfil trafik axını zamanı PostgreSQL-in özünü və nəticədə tətbiqi ölümdən xilas edən yeganə yol idi.

Bir sıra yük testlərindən sonra biz vəziyyəti təhlil etdik və Redis-in bir nüvə ilə ("rəf" adlanan) məhdud olduğunu, ardınca tətbiqin kifayət qədər sürətli deqradasiyaya uğradığını gördük. "Boğulma" eksponent idi: Redisin performans həddinə çatan kimi hər şey işləməyi dayandırdı.

Belə bir şeyə bənzəyirdi:

New Relic problemi aydın şəkildə müəyyənləşdirdi:

Əməliyyatın statistikasını təqdim edirik: get Redisdə:

Problem inkişaf qrupuna ətraflı məlumat verildikdən sonra məlum oldu ki, “problemi indi həll etmək mümkün deyil”. Beləliklə, əməliyyatlar tərəfində bir həll axtarışı başladı və artıq qeyd olunan KeyDB cavab oldu.

Bununla belə, nəzərdən keçirməyə başlamazdan əvvəl, layihənin müstəqil Redis-dən istifadə etdiyini qeyd etmək lazımdır, çünki Sentinel-ə əsaslanan klaster həlli gecikmə baxımından çox aşağıdır. Açıq bir həll yolu keşin bir neçə nüsxəsini yaratmaq idi: və tətbiqi balanslaşdırma ilə hər yerə buraxın! Bununla belə, tərtibatçılarla məsləhətləşdikdən sonra tətbiqin aktiv və mürəkkəb önbelleği etibarsız etmə mexanizmi səbəbindən bu seçimi ləğv etmək məcburiyyətində qaldıq. Eyni problem cache sharding üçün də genişləndi.

KeyDB-yə sürətli baxış

Problemin mümkün həllini axtararkən biz kəşf etdik KeyDB adlı proqram. Bu, Redis tərəfindən hazırlanmış bir çəngəldir Kanada şirkəti və pulsuz BSD lisenziyası altında paylanır. Layihə çox gəncdir: 2019-cu ilin əvvəlindən mövcuddur. Onun tarixi ondan ibarətdir ki, müəlliflər də bir dəfə Redis-in məhdudiyyətləri ilə qarşılaşdılar... və öz çəngəllərini düzəltməyə qərar verdilər. Üstəlik, o, nəinki məlum problemləri həll etdi, həm də yalnız Redis-in müəssisə versiyasında mövcud olan əlavə funksiyalar aldı.

KeyDB ilə daha ətraflı tanış olmaq istəyənlər üçün yaxşı bir şey var Medium-da giriş məqaləsi, DBMS-ni və onu "ana" - Redis ilə müqayisə edən qısa meyarları təqdim edir.

İlk növbədə, problemlərimizin potensial həlli bizi KeyDB-yə cəlb etdi və eyni zamanda bəzi əlavə xüsusiyyətlərlə maraqlandıq. KeyDB-dən istifadə aşağıdakı üstünlükləri vəd etdi:

• tam multithreading əldə etmək;
• Redis ilə tam və mütləq uyğunluq (bu, bizim üçün xüsusilə vacib idi, çünki tətbiq tərəfində heç bir dəyişiklik etmək mümkün deyildi), bu da problemsiz miqrasiya vəd etdi;
• S3 yaddaşında quraşdırılmış ehtiyat mexanizm;
• aktiv replikasiyanın həyata keçirilməsi asan;
• Sentinel və digər dəstəkləyici proqramlar olmadan sadə qruplaşma və parçalanma.

GitHub-da 3 mindən çox ulduz və bir çox iştirakçı da ümidverici görünürdü. Tətbiq kifayət qədər aktiv şəkildə inkişaf etdirilir və dəstəklənir, bu, öhdəliklərdə, məsələlərdə ünsiyyətdə, həmçinin qapalı (qəbul edilmiş) PR-lərdə aydın görünür. Bütün cəbhələrdə əsas baxıcının cavabı həmişə səmimi və operativdir. Ümumiyyətlə, çoxlu mübahisələr var idi.

Miqrasiya və nəticələr

Miqrasiya layihəsi bir az qumar oyunu olsa da (KeyDB-nin yeniliyinə görə), itirəcək çox şey yox idi. Axı, dəyişiklikləri geri qaytarmaq olduqca tez və asandır - xoşbəxtlikdən, bütün infrastruktur Kubernetes-də yerləşdirilib və quraşdırılmış mexanizmlər Rolling Yeniləmə Belə problemləri çox gözəl həll edirlər.

Ümumiyyətlə, biz Helm şablonlarını hazırladıq, test mühitindəki tətbiqi yeni verilənlər bazasına keçirdik və hamısını yayaraq müştərinin QA şöbəsinə təhvil verdik.

Təxminən bir həftə davam edən və təfərrüatlarına girmədiyimiz sınaqlar başladı. Biz yalnız bilirik ki, müştəri PHP sürücüsündən istifadə edərək Redis ilə işləməyin standart funksiyalarını sınaqdan keçirib phpredis, həmçinin istifadəçi interfeysinin QA testini keçirdi. Bundan sonra bizə yaşıl işıq yandırıldı: yeni proqram təminatından istifadə zamanı heç bir yan təsir aşkar edilmədi. Yəni Tətbiq baxımından heç nə dəyişməyib.

Qeyd etmək lazımdır ki, konfiqurasiyada heç bir dəyişiklik etmədik: sözün həqiqi mənasında, sadəcə istifadə olunan şəkli əvəz etdik. Eyni şey Prometheus-a ölçüləri izləmək və ixrac etmək üçün də gedir: onlardan ən çox yayılmışdır KeyDB ilə və heç bir dəyişiklik olmadan mükəmməl işləyir. Beləliklə, əminliklə deyə bilərik ki, əməliyyat baxımından bu, sadəcə olaraq ideal bir hərəkətdir.

Bütün bunların sayəsində tətbiqi yeni DBMS-ə keçirdikdən sonra heç nəyi dəyişə bilməzsiniz, ancaq "sabitləşdirmə tədbiri" olaraq bir müddət döyüşdə işləmək üçün onu bu formada tərk edə bilərsiniz. Bununla belə, performans artımını (və ya ümumiyyətlə hər hansı bir dəyişiklik) görmək istəyirsinizsə, bunu unutmamalısınız default olaraq Çox iş parçacığından məsul olan KeyDB parametri (server-threads), birə bərabərdir, yəni DBMS tamamilə Redis ilə eyni işləyir.

Yeni tətbiqdə (KeyDB ilə) keçid, sınaq və bir müddət istifadə etdikdən sonra, Redis üçün istifadə edilən eyni parametrlərlə yük testini təkrarlamaq qərarına gəldik. Nəticələri nə oldu?..

CPU istehlak qrafikinə görə, bir nüvənin "tavanı" ilə bağlı problemlərin aradan qaldırılması dərhal nəzərə çarpdı: proses mövcud resurslardan istifadə etməyə başladı:

Və sonra mən tətbiqi olduqca güclü şəkildə "işgəncə etməyə" çalışdım və üç nüvəyə qədər istehlak gördüm ...

New Relic-ə görə, bütövlükdə eyni yükə malik olan veb tətbiqi nəzərəçarpacaq dərəcədə daha adekvat davranmağa başladı. Bəzi performans azalması hələ də müşahidə edilmişdir, lakin yuxarıdakı oxşar qrafiklə müqayisə edildikdə, əhəmiyyətli irəliləyişləri özünüz qiymətləndirə bilərsiniz:

Yeni verilənlər bazasının (KeyDB) gecikmə müddəti də pisləşdi, lakin məqbul dəyərlər daxilində qaldı:

Aşağıdakı qrafik açıq şəkildə göstərir ki, KeyDB-yə edilən sorğuların sayı oxşardır:

Bu sintetik testləri ümumiləşdirmək üçün deyə bilərik ki, həm Redis, həm də KeyDB paralel bağlantıların sayında əhəmiyyətli artım (40+) ilə gecikmə müddətində (1000 ms+) əhəmiyyətli performans azalması göstərir. Bizim vəziyyətimizdə veb tətbiqi Redis-in gecikmə müddətini hətta daha az sayda əlaqə ilə (400+) "boşa" bildi, baxmayaraq ki, KeyDB üçün belə bir yük məqbul olaraq qaldı.

Tapıntılar

Bu nümunə Açıq Mənbə cəmiyyətinin maraqlı olduğu layihələrin inkişafındakı gücünü açıq şəkildə göstərir. İnternetdə əla bir ifadəyə rast gəldim, onun ümumi mənası belədir: “Bəzi böyük şirkət maraqlı məhsul yaradır, onun bəzi funksiyalarını açıq edir, amma ən vacib hissəsini ödənişli qoyur. Camaat ondan istifadə edir və istifadə edir, sonra kimsə imtina edib çəngəl düzəldir, orada eyni pullu xüsusiyyətləri həyata keçirir və hamıya açır”. Burada KeyDB eyni vəziyyətdir.

Təəccüblü dərəcədə sadə olan miqrasiyanın özündən danışsaq, almadıq belə ki KeyDB müəlliflərinin qrafiklərinə baxmaqla gözlənilən performansda əhəmiyyətli artım... Bununla belə, bu, yalnız bizim xüsusi halımızdır ki, burada tətbiqin bədnam arxitekturası da daxil olmaqla, çoxlu sapmalar ola bilər (məsələn, , çoxlu sayda əmrlər get məcmu sorğuların daha effektiv variantı əvəzinə Redis-də mget...). Buna baxmayaraq, biz müsbət nəticələrə və onlarla yanaşı, yaxın gələcəkdə həyata keçirəcəyimiz bir çox faydalı funksiyalara nail ola bildik.

Ümumiyyətlə, KeyDB perspektivli görünür: biz bu DBMS ilə praktiki təcrübə qazandıqca (və biz hələ də onu qazanmalıyıq!) və layihənin özünü inkişaf etdirdikcə, biz ondan başqa vəziyyətlərdə istifadə imkanlarını nəzərdən keçirəcəyik.

Bununla belə, bu məqalə KeyDB-nin xeyrinə Redis-dən geniş şəkildə imtina etmək üçün hərəkətə keçmək üçün bir bələdçi (bir çağırış da olsun) kimi qəbul edilməməlidir. Müsbət təcrübəmizə baxmayaraq, bunun gümüş güllə olmadığı aydındır. İş çox spesifik idi: xüsusi olaraq tez və minimum xərclə etmək lazım olan bir vəziyyətdə ani problemi həll etmək üçün bu həll özünü doğrultdu. KeyDB sizin vəziyyətinizdə faydalı olacaqmı? Ən azından indi siz bu potensialın mövcud olduğunu bilirsiniz.

PS

Bloqumuzda da oxuyun:

• «Verilənlər bazaları və Kubernetes (baxış və video hesabat)";
• «Kassandranın Kubernetesə miqrasiyası: xüsusiyyətlər və həllər";
• «MongoDB-nin Kubernetes-ə problemsiz miqrasiyası";
• «Kubernetes miqrasiyasına qüsursuz RabbitMQ.

Mənbə: www.habr.com