Deyirlər ki, həyatda hər şey ən azı bir dəfə cəhd etməyə dəyər. Əgər siz relyasiyalı DBMS-lərlə işləməyə öyrəşmisinizsə, onda NoSQL ilə praktikada, ilk növbədə, heç olmasa ümumi inkişaf üçün tanış olmağa dəyər. İndi bu texnologiyanın sürətli inkişafı səbəbindən bu mövzuda çoxlu ziddiyyətli fikirlər və qızğın mübahisələr var ki, bu da xüsusilə marağı artırır.
Bütün bu mübahisələrin mahiyyətini araşdırsanız, onların yanlış yanaşma ucbatından yarandığını görə bilərsiniz. NoSQL verilənlər bazalarından tam lazım olduğu yerdə istifadə edənlər razı qalırlar və bu həlldən bütün üstünlükləri alırlar. Və bu texnologiyanı heç bir şəkildə tətbiq oluna bilməyən bir dərman kimi qəbul edən eksperimentçilər əhəmiyyətli fayda əldə etmədən əlaqəli verilənlər bazalarının güclü tərəflərini itirərək məyus olurlar.
Mən sizə Cassandra DBMS əsasında həlli tətbiq etmək təcrübəmiz haqqında danışacağam: nə ilə üzləşməli olduq, çətin vəziyyətlərdən necə çıxdıq, NoSQL-dən istifadə etməkdən faydalana bildikmi və hara əlavə səylər/vəsaitlər yatırmalı olduq. .
İlkin vəzifə zəngləri bir növ yaddaşda qeyd edən sistem qurmaqdır.
Sistemin iş prinsipi aşağıdakı kimidir. Daxiletmə zəng strukturunu təsvir edən xüsusi strukturu olan fayllardan ibarətdir. Tətbiq daha sonra bu strukturun müvafiq sütunlarda saxlanmasını təmin edir. Gələcəkdə, saxlanan zənglər abunəçilər üçün trafik istehlakı haqqında məlumatı göstərmək üçün istifadə olunur (rüsumlar, zənglər, balans tarixçəsi).
Nə üçün Kassandranı seçdikləri aydındır - o, pulemyot kimi yazır, asanlıqla miqyaslanır və səhvlərə dözümlüdür.
Beləliklə, bu təcrübə bizə verdi
Bəli, uğursuz bir node faciə deyil. Kassandranın günaha dözümlülüyünün mahiyyəti budur. Amma bir node canlı ola bilər və eyni zamanda performansda əziyyət çəkməyə başlayır. Məlum olub ki, bu, bütün klasterin işinə dərhal təsir edir.
Oracle sizi məhdudiyyətləri ilə xilas etdiyi yerdə Cassandra sizi qorumayacaq. Tətbiqin müəllifi bunu əvvəlcədən başa düşməyibsə, Kassandra üçün gələn ikiqat orijinaldan daha pis deyil. Gələndən sonra onu yerləşdirəcəyik.
IB qutudan çıxan pulsuz Kassandranı qətiyyən bəyənmədi: İstifadəçi hərəkətlərinin qeydiyyatı, hüquqların fərqləndirilməsi yoxdur. Zənglər haqqında məlumat şəxsi məlumat hesab olunur, bu o deməkdir ki, onu istənilən şəkildə tələb etmək/dəyişdirmək üçün edilən bütün cəhdlər sonrakı auditin mümkünlüyü ilə qeyd edilməlidir. Həmçinin, müxtəlif istifadəçilər üçün müxtəlif səviyyələrdə hüquqların ayrılması zərurətindən xəbərdar olmalısınız. Sadə əməliyyat mühəndisi və bütün açar boşluğunu sərbəst silə bilən super admin fərqli rollar, fərqli məsuliyyətlər və bacarıqlardır. Giriş hüquqlarının bu cür diferensiallaşdırılması olmadan, məlumatların dəyəri və bütövlüyü HƏR ardıcıllıq səviyyəsindən daha tez sual altına düşəcək.
Nəzərə almadıq ki, zənglər həm ciddi analitika, həm də müxtəlif şərtlər üçün dövri seçmə tələb edir. Seçilmiş qeydlərin daha sonra silinməsi və yenidən yazılması nəzərdə tutulduğundan (tapşırığın bir hissəsi kimi, verilənlər ilkin dövrəmizə səhv daxil olduqda məlumatların yenilənməsi prosesini dəstəkləməliyik), Cassandra burada bizim dostumuz deyil. Cassandra donuz bankına bənzəyir - əşyaları qoymaq rahatdır, ancaq ona saymaq olmaz.
Test zonalarına verilənlərin ötürülməsində problemlə qarşılaşdıq (testdə 5 qovşaq, baloya 20 qovşaq). Bu vəziyyətdə, zibildən istifadə edilə bilməz.
Cassandra-ya yazan proqramın məlumat sxeminin yenilənməsi ilə bağlı problem. Geri çəkilmə çoxlu məzar daşları yaradacaq ki, bu da gözlənilməz şəkildə məhsuldarlığın itirilməsinə səbəb ola bilər.. Cassandra qeyd üçün optimallaşdırılmışdır və yazmadan əvvəl çox düşünmür.Onun içindəki mövcud məlumatlarla istənilən əməliyyat həm də qeyddir. Yəni, lazımsızları silməklə, sadəcə olaraq, daha da çox qeydlər istehsal edəcəyik və onlardan yalnız bəziləri məzar daşları ilə işarələnəcək.
Daxil edərkən fasilələr. Cassandra səsyazmada gözəldir, amma bəzən gələn axın onu əhəmiyyətli dərəcədə çaşdıra bilər. Bu, proqram nədənsə daxil edilə bilməyən bir neçə qeyd ətrafında dövr etməyə başlayanda baş verir. Bizə gc.log-a, sistemə və yavaş sorğular üçün debug qeydlərinə, sıxılma gözlənilən ölçülərə nəzarət edəcək real DBA lazımdır.
Bir klasterdə bir neçə məlumat mərkəzi. Haradan oxumalı və hardan yazmalı?
Bəlkə oxumaq və yazmaq bölünür? Və əgər belədirsə, yazmaq və ya oxumaq üçün ərizəyə daha yaxın bir DC olmalıdır? Yanlış ardıcıllıq səviyyəsini seçsək, əsl parçalanmış beyinlə nəticələnməyəcəyikmi? Çoxlu suallar, çoxlu naməlum parametrlər, həqiqətən də işləmək istədiyiniz imkanlar var.
Necə qərar verdik
Düyün batmasının qarşısını almaq üçün SWAP deaktiv edildi. Və indi, yaddaş çatışmazlığı varsa, node aşağı enməli və böyük gc fasilələri yaratmamalıdır.
Beləliklə, biz artıq verilənlər bazasında məntiqə etibar etmirik. Tətbiq tərtibatçıları özlərini yenidən hazırlayır və öz kodlarında fəal şəkildə ehtiyat tədbirləri görməyə başlayırlar. Məlumatların saxlanması və işlənməsinin ideal şəkildə aydın şəkildə ayrılması.
Biz DataStax-dan dəstək aldıq. Qutulu Kassandranın inkişafı artıq dayandırılıb (sonuncu öhdəliyi 2018-ci ilin fevralında olub). Eyni zamanda, Datastax mövcud IP həlləri üçün əla xidmət və çoxlu sayda dəyişdirilmiş və uyğunlaşdırılmış həllər təklif edir.
Onu da qeyd etmək istəyirəm ki, Cassandra seçim sorğuları üçün çox əlverişli deyil. Əlbəttə ki, CQL istifadəçilər üçün irəliyə doğru böyük bir addımdır (Trift ilə müqayisədə). Ancaq bu cür rahat birləşmələrə, istənilən sahə üzrə pulsuz filtrləmə və sorğuların optimallaşdırılması imkanlarına öyrəşmiş bütöv şöbələriniz varsa və bu şöbələr şikayətləri və qəzaları həll etməyə çalışırsa, Cassandra-da həll onlara düşmən və axmaq görünür. Və biz həmkarlarımızın nümunələri necə hazırlayacağına qərar verməyə başladıq.
Biz iki variantı nəzərdən keçirdik.Birinci variantda biz zəngləri təkcə C* dilində deyil, həm də arxivləşdirilmiş Oracle verilənlər bazasında yazırıq. Yalnız, C*-dən fərqli olaraq, bu verilənlər bazası yalnız cari ay üçün zəngləri saxlayır (zənglərin doldurulması üçün kifayət qədər zəngin yaddaş dərinliyi). Burada dərhal aşağıdakı problemi gördük: sinxron yazsaq, C*-nin sürətli daxiletmə ilə bağlı bütün üstünlüklərini itiririk; asinxron yazsaq, bütün lazımi zənglərin ümumiyyətlə Oracle-a daxil olmasına zəmanət yoxdur. Bir artı var idi, amma böyük olanı: əməliyyat üçün eyni tanış PL/SQL Developer qalır, yəni biz praktiki olaraq “Fasad” modelini həyata keçiririk.Alternativ variant. Biz C*-dan zəngləri boşaldan, Oracle-da müvafiq cədvəllərdən zənginləşdirmək üçün bəzi məlumatları çıxaran, əldə edilən nümunələri birləşdirən və bizə nəticə verən bir mexanizm həyata keçiririk, bundan sonra hansısa şəkildə istifadə edirik (geri qaytarırıq, təkrar edirik, təhlil edirik, heyran oluruq). Eksiler: proses olduqca çox mərhələlidir və əlavə olaraq əməliyyat işçiləri üçün heç bir interfeys yoxdur.
Sonda ikinci variant üzərində qərarlaşdıq. Apache Spark müxtəlif bankalardan nümunə götürmək üçün istifadə edilmişdir. Mexanizmin mahiyyəti müəyyən edilmiş düymələrdən (abunəçi, zəng vaxtı - bölmə düymələri) istifadə edərək C*-dan məlumatları, eləcə də istənilən digər verilənlər bazasından zənginləşdirmək üçün lazım olan məlumatları çıxaran Java koduna qədər azaldılıb. Bundan sonra o, onları yaddaşına qoşur və nəticəni alınan cədvəldə göstərir. Qığılcım üzərində bir veb üzü çəkdik və olduqca istifadə edilə bilər.
Sənaye test məlumatlarının yenilənməsi problemini həll edərkən yenidən bir neçə həll yolu nəzərdən keçirdik. Həm Sstloader vasitəsilə köçürmə, həm də test zonasındakı klasteri iki hissəyə bölmək seçimi, hər biri alternativ olaraq tanıtım klasteri ilə eyni klasterə aiddir və beləliklə, ondan gücləndirilir. Testi yeniləyərkən onların dəyişdirilməsi planlaşdırılırdı: sınaqda işləyən hissə təmizlənir və istehsala daxil edilir, digəri isə ayrıca məlumatlar ilə işləməyə başlayır. Bununla belə, bir daha düşündükdən sonra, biz ötürməyə dəyər olan məlumatları daha rasional qiymətləndirdik və başa düşdük ki, zənglərin özləri testlər üçün uyğun olmayan bir varlıqdır, lazım olduqda tez yaradılır və bu, promosyon məlumat dəstidir ki, bu da başqasına ötürülməsi üçün heç bir dəyəri yoxdur. test. Köçürülməyə dəyər bir neçə saxlama obyekti var, lakin bunlar sözün əsl mənasında bir neçə masadır və çox ağır deyil. Ona görə də biz həll yolu olaraq Spark yenidən köməyə gəldi, onun köməyi ilə biz yazdıq və cədvəllər arasında məlumat ötürmək üçün skriptdən, prom-testdən fəal istifadə etməyə başladıq.
Mövcud yerləşdirmə siyasətimiz bizə geri çəkilmədən işləməyə imkan verir. Promosyondan əvvəl, səhvin o qədər də bahalı olmadığı məcburi bir sınaq qaçışı var. Uğursuzluq halında, siz həmişə iş boşluğunu atıb bütün sxemi əvvəldən yuvarlaya bilərsiniz.
Cassandra-nın davamlı olmasını təmin etmək üçün sizə təkcə ona deyil, dba lazımdır. Tətbiqlə işləyən hər kəs mövcud vəziyyətə harada və necə baxmaq lazım olduğunu və problemləri vaxtında necə müəyyənləşdirmək lazım olduğunu başa düşməlidir. Bunun üçün biz DataStax OpsCenter (İş yüklərinin idarə edilməsi və monitorinqi), Cassandra Driver sisteminin ölçülərindən (C*-ə yazmaq üçün fasilələrin sayı, C*-dən oxumaq üçün fasilələrin sayı, maksimum gecikmə və s.) fəal şəkildə istifadə edirik, əməliyyata nəzarət edirik. proqramın özü, Cassandra ilə işləyir.
Əvvəlki sualı düşünəndə əsas riskimizin harada ola biləcəyini anladıq. Bunlar bir neçə müstəqil sorğudan məlumatları yaddaşa göstərən məlumatların göstərilməsi formalarıdır. Bu yolla kifayət qədər uyğun olmayan məlumatlar əldə edə bilərik. Ancaq yalnız bir məlumat mərkəzi ilə işləsək, bu problem eyni dərəcədə aktual olardı. Beləliklə, burada ən ağlabatan şey, əlbəttə ki, üçüncü tərəf proqramında məlumatların oxunması üçün toplu funksiya yaratmaqdır ki, bu da məlumatların bir müddət ərzində alınmasını təmin edəcəkdir. Performans baxımından oxuma və yazmağa bölünməyə gəlincə, burada DC-lər arasında əlaqənin bir qədər itməsi ilə bir-biri ilə tamamilə uyğun olmayan iki klasterlə nəticələnə biləcəyimiz riski bizi dayandırdı.
Nəticədə, hələlik EACH_QUORUM yazmaq üçün ardıcıllıq səviyyəsində dayandı, oxumaq üçün - LOCAL_QUORUM
Qısa təəssüratlar və nəticələr
Nəticə həllini əməliyyat dəstəyi və gələcək inkişaf perspektivləri nöqteyi-nəzərindən qiymətləndirmək üçün belə bir inkişafın başqa harada tətbiq oluna biləcəyi barədə düşünmək qərarına gəldik.
Dərhal dərhal, sonra “Rahat olanda ödə” (biz məlumatı C*-ə yükləyirik, Spark skriptlərindən istifadə edərək hesablama), ərazi üzrə toplama ilə iddiaların uçotu, rolların saxlanması və rola əsasən istifadəçi giriş hüququnun hesablanması kimi proqramlar üçün məlumatların qiymətləndirilməsi matris.
Göründüyü kimi, repertuar geniş və rəngarəngdir. NoSQL-in tərəfdarları/opponentləri düşərgəsini seçsək, üstünlüklərimizi əldə etdiyimiz üçün və tam olaraq gözlədiyimiz yerdə tərəfdarlara qoşulacağıq.
Hətta qutudan çıxarılan Cassandra seçimi, sistemdə məlumatların artırılması məsələsini tamamilə ağrısız şəkildə həll edərək, real vaxt rejimində üfüqi miqyaslamağa imkan verir. Zəng aqreqatlarının hesablanması üçün çox yüksək yükləmə mexanizmini ayrıca dövrəyə köçürə bildik, həmçinin proqram sxemini və məntiqini ayıraraq, verilənlər bazasında xüsusi işlərin və obyektlərin yazılmasının pis təcrübəsindən qurtula bildik. Biz seçmək və konfiqurasiya etmək, sürətləndirmək, hansı DC-lərdə hesablamalar aparacağımızı və hansıları üzərində məlumatları yazacağımızı seçmək imkanı əldə etdik, həm ayrı-ayrı qovşaqların, həm də bütövlükdə DC-nin qəzalarından özümüzü sığortaladıq.
Arxitekturamızı yeni layihələrə tətbiq edərək və artıq müəyyən təcrübəyə malik olmaqla, yuxarıda təsvir olunan nüansları dərhal nəzərə almaq və bəzi səhvlərin qarşısını almaq, əvvəlcə qarşısını almaq mümkün olmayan bəzi kəskin küncləri hamarlamaq istərdim.
Məsələn, Cassandra'nın yeniləmələrini vaxtında izləyinçünki əldə etdiyimiz problemlərin bir çoxu artıq məlum və aradan qaldırılmışdı.
Həm verilənlər bazasının özünü, həm də Spark-ı eyni qovşaqlara qoymayın (və ya ciddi şəkildə icazə verilən resurs istifadəsinin miqdarına bölün), çünki Spark gözlənildiyindən daha çox OP yeyə bilər və biz tez bir zamanda siyahımızdan 1 nömrəli problemi əldə edəcəyik.
Layihənin sınaq mərhələsində monitorinq və əməliyyat səriştəsini təkmilləşdirin. Əvvəlcə həllimizin bütün potensial istehlakçılarını mümkün qədər nəzərə alın, çünki verilənlər bazası strukturu son nəticədə bundan asılı olacaq.
Mümkün optimallaşdırma üçün ortaya çıxan dövrəni bir neçə dəfə çevirin. Hansı sahələrin seriallaşdırıla biləcəyini seçin. Ən düzgün və optimal şəkildə nəzərə almaq üçün hansı əlavə cədvəlləri düzəltməli olduğumuzu anlayın və sonra tələb əsasında tələb olunan məlumatları təqdim edin (məsələn, eyni məlumatları fərqli cədvəllərdə saxlaya biləcəyimizi fərz etməklə, cədvələ uyğun olaraq fərqli dağılmaları nəzərə alaraq. fərqli meyarlar, biz oxu sorğuları üçün CPU vaxtına əhəmiyyətli dərəcədə qənaət edə bilərik).
Pis deyil Dərhal TTL-nin əlavə edilməsini və köhnəlmiş məlumatların təmizlənməsini təmin edin.
Cassandra-dan məlumatları endirərkən Tətbiq məntiqi FETCH prinsipi üzərində işləməlidir ki, bütün sətirlər bir anda yaddaşa yüklənməsin, partiyalar şəklində seçilsin.
Layihəni təsvir edilmiş həllə köçürməzdən əvvəl məsləhətdir bir sıra qəza testləri keçirərək sistemin nasazlıqlara dözümlülüyünü yoxlayınməsələn, bir məlumat mərkəzində məlumat itkisi, müəyyən müddət ərzində zədələnmiş məlumatların bərpası, məlumat mərkəzləri arasında şəbəkənin kəsilməsi. Bu cür sınaqlar yalnız təklif olunan arxitekturanın müsbət və mənfi tərəflərini qiymətləndirməyə imkan verməyəcək, həm də onları aparan mühəndislər üçün yaxşı istiləşmə təcrübəsini təmin edəcək və sistem uğursuzluqları istehsalda təkrarlanarsa, əldə edilmiş bacarıq artıqlıqdan uzaq olacaqdır.
Əgər kritik məlumatlarla (məsələn, hesablaşma üçün məlumatlar, abunəçi borcunun hesablanması) işləsək, onda DBMS-nin xüsusiyyətləri ilə əlaqədar yaranan riskləri azaldacaq vasitələrə də diqqət yetirməyə dəyər. Məsələn, istifadə etmək üçün optimal strategiya hazırlayaraq nodesync yardım proqramını (Datastax) istifadə edin. ardıcıllıq naminə Cassandra üzərində həddindən artıq yük yaratmayın və yalnız müəyyən müddətdə müəyyən cədvəllər üçün istifadə edin.
Altı aylıq həyatdan sonra Kassandra ilə nə baş verir? Ümumiyyətlə, həll olunmamış problem yoxdur. Biz həmçinin heç bir ciddi qəzaya və ya məlumat itkisinə yol vermədik. Bəli, biz əvvəllər yaranmamış bəzi problemləri kompensasiya etmək barədə düşünməli olduq, amma sonda bu, bizim memarlıq həllimizə o qədər də kölgə salmadı. İstəyirsinizsə və yeni bir şey sınamaqdan qorxmursunuzsa və eyni zamanda çox məyus olmaq istəmirsinizsə, heç bir şeyin pulsuz olmadığına hazır olun. Köhnə miras həlli ilə müqayisədə daha çox başa düşməli, sənədləri araşdırmalı və öz fərdi dırmıqınızı yığmalı olacaqsınız və heç bir nəzəriyyə sizə hansı tırmığın sizi gözlədiyini əvvəlcədən söyləməyəcək.
Mənbə: www.habr.com