KeyDB [potensial] Redis əvəzi kimi

Habrda «Redis'tən daha sürətli alternativ» haqqında heç bir icmal tapılmadı — KeyDB. Tətbiqinin istifadə edilməsi ilə bağlı kifayət qədər yeni təcrübə əldə etdikdən sonra, bu boşluğu doldurmaq istəyirəm.

Tarixi kifayət qədər sadədir: bir gün trafikdə kəskin artım zamanı tətbiqin performansında (daha doğrusu — cavab vaxtında) əhəmiyyətli bir degradasiya qeydə alındı. O vaxt, təəssüf ki, baş verən hadisələrin normal diaqnostikasını aparmaq mümkün olmadı, buna görə də sonradan bir sıra yük testləri planlaşdırdıq. Onların keçirilməsindən sonra Redis'də verilənlər bazasının keşi dar yer olduğunu aşkar etdik. Adətən olduğu kimi, problemi dərhal həll etmək — inkişaf etdiricilərin (iş prinsiplərini dəyişməklə) gücü ilə mümkün olmadı. Buna görə də, vəziyyətlə mübarizə aparmaq istəyimiz və marağımız başladı. Bu məqalə də elə belə ortaya çıxdı.

Problematikalar

Redis haqqında ümumilikdə

Bir çox insana məlumdur ki, Redis — bir iplikli verilənlər bazasıdır. Dəqiq desək, istifadəçi verilənləri ilə iş kontekstində belədir. Çünki dördüncü versiyadan etibarən, Redis'in xidməti, daxili əməliyyatları paralel icraya keçirildi. Lakin, bu dəyişiklik yalnız yükün kiçik bir hissəsinə təsir etdi, çünki əsas iş istifadəçi verilənlərinə aiddir.

Bu mövzuda saysız-hesabsız müzakirələr aparılıb, lakin Redis'in inkişaf etdiriciləri tam paralellik tətbiq etmək istəmirlər, çünki bunun tətbiqi çətinləşdirəcəyini və əlavə xərcləri artıracağını, həm də proqramdakı səhv sayını artıracağını qeyd edirlər. Onların mövqeyi budur: bir nüvənin problemi ilə qarşılaşsanız — tətbiq arxitekturasında problemlər var, ona görə də nəsə dəyişməlisiniz. İstifadəçilər arasında isə «başqa bir düşərgə» var — bir nüvəyə bağlı qalanlar və Redis'in özlərinin butulkalı boğulma yarattığını iddia edənlərdir. Gerçəkdən böyük yük vəziyyətində — gec-tez — bu məsələ ilə qarşılaşmaq qaçılmazdır ki, bu da arxitektura və ya məcburi mürəkkəbliklər üzərində əhəmiyyətli məhdudiyyətlər qoyur.

Hər hansı bir fikrə qiymət vermək istəmirəm. Bunun əvəzinə konkret halımızla və onu necə həll etdiyimizlə bölüşəcəyəm.

Bizim iş nümunəmiz

Layihələrimizdən birində, inkişaf etdirici komandası PostgreSQL-dan Redis vasitəsilə verilənlərin çox aqressiv bir şəkildə keşkarladığını gördük. Bu, kəskin trafik hücumları zamanı PostgreSQL-in ölümdən qurtulması üçün yeganə yol idi və bunun nəticəsində tətbiqi də xilas edirdi.

Yük testlərindən sonra vəziyyəti analiz etdik və Redis-in bir nüvəyə bağlı olduğunu (başqa sözlə, «maximuma çatdığını») aşkar etdik, ardınca tətbiqdə olduqca sürətli bir degradasiya baş verdi. Redis-in performans limitinə çatdığı an, hər şey dayanırdı.

Bu, belə görünürdü:

New Relic tərəfindən problem açıqca müəyyən edildi:

Amma əməliyyat statistikası get Redis-də:

Problemi inkişaf etdirməyə bütün təfərrüatları ilə çatdırdıqdan sonra, «indiki zamanda problemi həll etmək mümkün deyil» olduğu aydın oldu. Beləcə qaynaq istismarı tərəfdə həll axtarışlarına başladıq və cavab artıq qeyd edilən KeyDB oldu.

Ancaq onun icmalı ilə başlamaqdan əvvəl, layihədə standalone Redis istifadə edildiyini qeyd etmək lazımdır, çünki Sentinel əsaslı klaster həlli gecikmələrdə (latency) çox geri qalır. Aydındır ki, bir neçə keş nüsxəsinin yaradılması bir qeydə alınmış həll idi: istifadəçi burada-buradadır, balanslaşdırma ilə! Lakin, inkişaf etdiricilərlə məsləhətləşdikdən sonra, proqramın aktiv və mürəkkəb keş invalidasiya mexanizmi səbəbindən bu variantı rədd etmək məcburiyyətində qaldıq. Eyni problem keşi şardlaşdırmağa da aiddir.

KeyDB-yə qısa baxış

Problemin mümkün həllini axtararkən KeyDB adlı bir tətbiq tapdıq. Bu, Redis-in forkudur, Kanadalı şirkət tərəfindən hazırlanmışdır və BSD lisenziyası altında yayılır. Layihə olduqca gəncdir: 2019-cu ilin əvvəlindən mövcuddur. Tarixi belədir ki, müəlliflər də bir vaxtlar Redis-in məhdudiyyətləri ilə üzləşmişdilər... və öz forklarını yaratmağa qərar vermişlər. Üstəlik, bu, yalnız məlum problemləri həll etməklə qalmayıb, həm də yalnız Redis-in enterprise versiyasında olan əlavə imkanları əldə edib.

KeyDB ilə daha yaxından tanış olmaq istəyənlər üçün Medium-da yaxşı bir giriş yazısı var, bu, DB-ni təqdim edir və onun «doğma»sı olan Redis ilə müqayisədə qısa benchmark-lar təqdim edir.

Birincisi, biz KeyDB-də potensial problemlərimizin həllini cəlb etdik, eyni zamanda bəzi əlavə xüsusiyyətlər də maraqlıdır. KeyDB-nin istifadəsi aşağıdakı üstünlükləri vəd edir:

• tamamilə çoxsahəliq əldə etmək;
• Redis ilə tam və mütləq uyğunluq (bu bizim üçün xüsusilə əhəmiyyətlidir, çünki proqram tərəfində hər hansı dəyişikliklər etmək mümkün olmurdu), bu da problemsiz migrasiyanı vəd edirdi;
• S3 anbarında inteqrasiya olunmuş yedekləmə mexanizmi;
• asan tətbiq olunan aktiv replikasiya;
• Sentinel və digər əlavə proqram təminatı olmadan sadə klasterləşdirmə və şardlaşdırma.

GitHub-da 3000-dən çox ulduz və bir çox töhfəçi də ümidverici görünürdü. Tətbiq kifayət qədər aktiv inkişaf edir və dəstəklənir, bu da kommitlər, məsələlərdə ünsiyyət və bağlanmış (qəbul edilən) PR-lərdə yaxşı görünür. Əsas saxlayıcıdan bütün cəbhələrdə cavab həmişə mehriban və operativdir. Ümumiyyətlə, sübutların sayı kifayət qədər idi.

Miqrasiya və nəticələr

Hətta KeyDB-nin yeniliyi səbəbindən köçürmə layihəsinin qeyri-adi bir risk olduğu halda, itirəcək bir şeyimiz yox idi. Çünki dəyişiklikləri geri qaytarmaq olduqca sürətli və asandır — şükür, bütün infrastruktur Kubernetes-də yerləşdirilib və daxili mexanizmlər Rolling Update belə məsələləri mükəmməl şəkildə həll edir.

Ümumiyyətlə, biz Helm şablonlarını hazırladıq, tətbiqi test mühitində yeni DB-yə keçirdik və bunu QA mütəxəssisinə təqdim etdik.

Test prosesi başlayıb və bir həftədən çox davam etdi, lakin detallarına girmədik. Bizə yalnız müştərinin PHP sürücüsü ilə Redis-in standart funksiyalarını yoxladığı məlumdur phpredis, habelə istifadəçi interfeysinin QA testini keçirdi. Bunun ardınca bizə yaşıl işıq verildi: yeni proqram təminatını istifadə edərkən heç bir yan təsir aşkar edilmədi. Yəni tətbiq baxımından heç bir şey dəyişmədi.

Qeyd etmək lazımdır ki, konfiqurasiyada da heç nəyi dəyişməmişik: faktiki olaraq — yalnız istifadə olunan görüntünü əvəz etdik. Eynilə, Prometheus-da monitorinq və metriklərin ixracına da aiddir: onların ən yaygın olanı KeyDB ilə mükəmməl işləyir və heç bir əlavəyə ehtiyac duymadan. Beləliklə, istənilən baxımdan mükəmməl bir köçürmə olduğunu rahatlıqla deyə bilərik.

Bütün bunlara görə, tətbiqi yeni DB-yə keçirdikdən sonra heç bir şey dəyişdirmək lazım deyil, və "stabilizasiya tədbiri" olaraq onu müəyyən bir müddət ərzində uçuşda buraxmaq olar. Bununla belə, əgər siz performans artımını görmək istəyirsinizsə (və ya hətta hər hansı bir dəyişiklik), unutmamalısınız ki, başlanğıc olaraq KeyDB-nin çoxzəriflik üçün nəzərdə tutulmuş parametri (server-threads) birə bərabərdir, yəni DB, Redis-in eynisi kimi işləyir.

Tətbiqdəki KeyDB-yə keçid, test və müəyyən müddət yeni tətbiqdə yaşadıdıqdan sonra (KeyDB ilə) eyni parametrlərlə yük testi təkrarlamağa qərar verdik. Nəticələr nə oldu?..

CPU istehlakı qrafiğinə əsasən, bir nüvədəki "sədd" probleminin aradan qaldırılması dərhal nəzərə çarpırdı: proses mövcud resurslardan istifadə etməyə başladı:

Sonrasında tətbiqi kifayət qədər "əsaslı" şəkildə sınamağa çalışdım və üç nüvəyə qədər istehlak gördüm...

New Relic-in göstəricilərinə görə, web tətbiqi eyni yük altında daha normal davrandı. Bəzi performans pisləşməsi hələ də müşahidə olundu, lakin yuxarıda göstərilən eyni qrafiklə müqayisədə, siz əhəmiyyətli irəliləyişi qiymətləndirin:

Yeni verilənlər bazası (KeyDB) üçün gecikmə göstəricisi də pisləşdi, lakin qəbul olunan hədlər daxilində qaldı:

Son qrafikdə KeyDB-ə edilən sorğuların sayı ilə bağlı vəziyyət də yaxşı görünür:

Bu sintetik testlərin yekununda deyə bilərik ki, həm Redis, həm də KeyDB, paralel bağlantıların sayında əhəmiyyətli artım (1000+) olduqda latency-də (40 ms+) əhəmiyyətli performans azalması nümayiş etdirir. Bizim nümunəmizdə isə veb tətbiqi Redis-in latency-ni daha az bağlantı sayı (400+) ilə "qaldıra" bildi, halbuki KeyDB üçün bu yük hələ də qəbulolunandır.

Sonuçlar

Bu nümunədə Açıq Mənbə cəmiyyətinin layihələrin inkişafı ilə bağlı gücü aydın görünür. İntternetdə qarşıma çıxan maraqlı bir ifadə vardı ki, onun ümumi mənası belədir: "Böyük bir şirkət maraqlı bir məhsul hazırlayır, onun bəzi funksiyalarını açıq edir, amma ən vacib hissəsini pullu saxlayır. Cəmiyyət istifadə edir, istifadə edir, sonra kimsə əlini yelləyib forq edir, həmin pullu funksiyaları reallaşdırıb hər kəs üçün açır". İşte KeyDB — bu cür bir haldır.

Miqrasiyaya gəldikdə, dəhşətli dərəcədə asan keçmiş olsa da, biz almamışıq o qədər mühüm performans artımı, KeyDB-yə baxdığımızda yazarların qrafiklərinə əsasən gözlənilirdi... Lakin bu, yalnız bizim spesifik nümunəmizdir, burada bir çox dəyişiklik ola bilər, o cümlədən məşhur tətbiq arxitekturası (məsələn, çox sayda komandalar get Redis-də daha məhsuldar toplanmış sorğuların variantı olan mget…). Yenə də müsbət nəticələr əldə edilib, bununla yanaşı, yaxın gələcəkdə tətbiq edəcəyimiz bir çox faydalı funksiyalar var.

Ümumilikdə, KeyDB perspektivli görünür: bu SGBD ilə praktiki iş təcrübəsi əldə etdikcə (hələ onu qazanmaq lazım!) və layihənin özü inkişaf etdikcə, onun digər situasiyalarda tətbiqini nəzərdən keçirəcəyik.

Ancaq bu məqaləni Redis-dən KeyDB-yə tamamilə keçmək üçün bir rəhbərlik (və ya daha da çox — hərəkətə çağırış) kimi görməmək lazımdır. Müsbət təcrübəmizə baxmayaraq, aydındır ki, bu, gümüş güllə deyil. Hal spesifik idi: konkret olaraq müvəqqəti problemin həlli üçün sürətli və minimum xərclərlə bu cür bir həll özünü doğruldurdu. KeyDB sizin halda faydalı olacaqmı? Ən azından, indi belə bir potensialın mövcud olduğunu bilirsiniz.

P.S.

Blogumuzda oxuyun:

• «Veri bazaları və Kubernetes (icmal və təqdimat videosu)»;
• «Cassandra-nın Kubernetes-ə köçürülməsi: xüsusiyyətlər və həllər»;
• «MongoDB-nin Kubernetes-də çətinliklə miqrasiyası»;
• «RabbitMQ-nin Kubernetes-ə çətin miqrasiya».

Mənbə: habr.com