Hey Habr.
Mənim adım Misha Butrimov, sizə bir az Kassandra haqqında danışmaq istərdim. Mənim hekayəm NoSQL verilənlər bazası ilə heç vaxt qarşılaşmayanlar üçün faydalı olacaq - onun bilməli olduğunuz bir çox tətbiq xüsusiyyətləri və tələləri var. Oracle və ya hər hansı digər əlaqəli verilənlər bazasından başqa heç nə görməmisinizsə, bunlar həyatınızı xilas edəcək.
Kassandranın nəyi yaxşıdır? Bu yaxşı miqyasda bir uğursuzluq nöqtəsi olmadan hazırlanmış NoSQL verilənlər bazasıdır. Bəzi verilənlər bazası üçün bir neçə terabayt əlavə etmək lazımdırsa, sadəcə olaraq ringə qovşaqlar əlavə edin. Onu başqa məlumat mərkəzinə genişləndirin? Klasterə qovşaqlar əlavə edin. İşlənmiş RPS artırılsın? Klasterə qovşaqlar əlavə edin. Bu da əks istiqamətdə işləyir.
O başqa nəyi bacarır? Bu, çoxlu sorğuların idarə edilməsindən gedir. Ancaq çox şey nə qədərdir? Saniyədə 10, 20, 30, 40 min sorğu çox deyil. Qeyd üçün saniyədə 100 min sorğu - çox. Saniyədə 2 milyon sorğu saxladıqlarını söyləyən şirkətlər var. Onlar yəqin ki, buna inanmalı olacaqlar.
Prinsipcə, Kassandranın relational məlumatlardan bir böyük fərqi var - o, onlara heç bənzəmir. Və bunu xatırlamaq çox vacibdir.
Eyni görünən hər şey eyni işləmir
Bir dəfə bir həmkarım yanıma gəldi və soruşdu: “Budur, CQL Cassandra sorğu dili və onun seçilmiş ifadəsi var, harada, var və var. Mən məktublar yazıram, işləmir. Niyə?". Kassandra ilə əlaqəli məlumat bazası kimi davranmaq şiddətli intihar etmək üçün mükəmməl bir yoldur. Mən bunu təbliğ etmirəm, Rusiyada qadağandır. Sadəcə nəyisə səhv dizayn edəcəksən.
Məsələn, müştəri bizə gəlir və deyir: “Gəlin seriallar üçün məlumat bazası, yaxud reseptlər kataloqu üçün məlumat bazası yaradaq. Orada yemək yeməklərimiz və ya serialların, aktyorların siyahısı olacaq”. Sevinclə deyirik: “Gedək!” Sadəcə iki bayt, bir neçə işarə göndərin və işiniz bitdi, hər şey çox tez və etibarlı şəkildə işləyəcək. Müştərilər gəlib evdar qadınların da əks problemi həll etdiyini deyənə qədər hər şey qaydasındadır: onların məhsulları siyahısı var və onlar hansı yeməyi bişirmək istədiklərini bilmək istəyirlər. sən öldün.
Bunun səbəbi Cassandra-nın hibrid verilənlər bazasıdır: o, eyni zamanda əsas dəyəri təmin edir və məlumatları geniş sütunlarda saxlayır. Java və ya Kotlin-də bunu belə təsvir etmək olar:
Map<RowKey, SortedMap<ColumnKey, ColumnValue>>
Yəni çeşidlənmiş xəritəni də ehtiva edən xəritə. Bu xəritənin ilk açarı Sıra açarı və ya Bölmə açarıdır - bölmə açarı. Artıq çeşidlənmiş xəritənin açarı olan ikinci açar Klasterləşdirmə açarıdır.
Verilənlər bazasının paylanmasını təsvir etmək üçün üç qovşaq çəkək. İndi məlumatları qovşaqlara necə parçalayacağınızı başa düşməlisiniz. Çünki hər şeyi birinə sıxışdırsaq (yeri gəlmişkən, min, iki min, beş ola bilər - istədiyiniz qədər), bu, əslində paylama ilə bağlı deyil. Buna görə də bizə ədədi qaytaracaq riyazi funksiya lazımdır. Sadəcə bir sıra, bəzi diapazona düşəcək uzun bir int. Və biz bir sıra üçün cavabdeh bir node olacaq, ikinci üçün ikinci, n-ci üçün bir.
Bu nömrə, Bölmə açarı dediyimiz şeyə tətbiq olunan hash funksiyasından istifadə etməklə götürülür. Bu, Primary key direktivində göstərilən sütundur və bu, xəritənin ilk və ən əsas açarı olacaq sütundur. Hansı qovşağın hansı məlumatları alacağını müəyyənləşdirir. Cassandra-da SQL-də olduğu kimi demək olar ki, eyni sintaksislə cədvəl yaradılmışdır:
CREATE TABLE users (
user_id uu id,
name text,
year int,
salary float,
PRIMARY KEY(user_id)
)
Bu halda Əsas açar bir sütundan ibarətdir və o, həm də bölmə açarıdır.
İstifadəçilərimiz necə çıxış edəcəklər? Bəziləri bir düyünə, bəziləri digərinə, bəziləri isə üçüncü qovşağına gedəcək. Nəticə Python-da lüğət kimi tanınan xəritə kimi tanınan adi hash cədvəli və ya bütün dəyərləri oxuya biləcəyimiz, açarla oxuya və yaza biləcəyimiz sadə Açar dəyər strukturudur.
Seçin: süzgəcdən keçməyə icazə verdikdə tam skanla və ya nə etməməli
Gəlin bəzi seçilmiş ifadələr yazaq: select * from users where, userid = . Oracle-da olduğu kimi çıxır: biz select yazırıq, şərtləri müəyyənləşdiririk və hər şey işləyir, istifadəçilər bunu alır. Ancaq məsələn, müəyyən doğum ili olan bir istifadəçi seçsəniz, Cassandra tələbi yerinə yetirə bilmədiyindən şikayətlənir. Doğum ili ilə bağlı məlumatları necə yaydığımız barədə ümumiyyətlə heç nə bilmədiyi üçün - onun açar kimi yalnız bir sütunu var. Sonra deyir: “Yaxşı, mən hələ də bu istəyi yerinə yetirə bilərəm. Filtrləmə icazəsini əlavə edin." Direktivi əlavə edirik, hər şey işləyir. Və bu anda dəhşətli bir şey baş verir.
Test məlumatları üzərində işlədiyimiz zaman hər şey qaydasındadır. Məsələn, 4 milyon qeydimiz olduğu istehsalda bir sorğu yerinə yetirdikdə, hər şey bizim üçün çox yaxşı deyil. Çünki filtrə icazə vermək Cassandra-ya bu cədvəldəki bütün məlumatları bütün qovşaqlardan, bütün məlumat mərkəzlərindən (əgər bu klasterdə onların çoxu varsa) toplamağa və yalnız bundan sonra onu filtrləməyə imkan verən direktivdir. Bu, Full Scan-ın analoqudur və demək olar ki, heç kim bundan məmnun deyil.
Bizə yalnız şəxsiyyət vəsiqəsi ilə istifadəçilər lazım olsaydı, bununla yaxşı olardıq. Ancaq bəzən başqa sorğular yazmaq və seçimə başqa məhdudiyyətlər qoymaq lazımdır. Buna görə də xatırlayırıq: bunların hamısı bölmə açarı olan bir xəritədir, lakin içərisində çeşidlənmiş bir xəritədir.
Onun da bir açarı var ki, biz onu Klaster Açarı adlandırırıq. Bu açar, öz növbəsində, seçdiyimiz sütunlardan ibarətdir, onun köməyi ilə Cassandra onun məlumatlarının fiziki olaraq necə çeşidləndiyini və hər bir qovşaqda yerləşəcəyini başa düşür. Yəni bəzi Bölmə açarı üçün Clustering açarı məlumatı bu ağaca necə itələyəcəyini, orada hansı yeri tutacağını dəqiq izah edəcək.
Bu, həqiqətən bir ağacdır, orada sadəcə bir müqayisəçi çağırılır, ona obyekt şəklində müəyyən bir sütun dəstini veririk və o, sütunların siyahısı kimi də göstərilmişdir.
CREATE TABLE users_by_year_salary_id (
user_id uuid,
name text,
year int,
salary float,
PRIMARY KEY((year), salary, user_id)
Əsas açar direktivinə diqqət yetirin; onun ilk arqumenti (bizim vəziyyətimizdə il) həmişə Bölmə açarıdır. Bir və ya bir neçə sütundan ibarət ola bilər, fərq etməz. Bir neçə sütun varsa, onu yenidən mötərizədə çıxarmaq lazımdır ki, dilin preprosessoru bunun İlkin açar olduğunu başa düşsün və onun arxasında bütün digər sütunlar Clustering açarıdır. Bu halda, onlar göründükləri ardıcıllıqla müqayisə aparatında ötürüləcəklər. Yəni birinci sütun daha əhəmiyyətlidir, ikinci sütun daha az əhəmiyyətlidir və s. Necə yazdığımız, məsələn, məlumat sinifləri üçün sahələrə bərabərdir: biz sahələri sadalayırıq və onlar üçün hansının daha böyük, hansının daha kiçik olduğunu yazırıq. Kassandrada bunlar, nisbətən desək, onun üçün yazılmış bərabərlərin tətbiq ediləcəyi məlumat sinfinin sahələridir.
Biz çeşidləmə təyin edirik və məhdudiyyətlər qoyuruq
Yadda saxlamaq lazımdır ki, çeşidləmə qaydası (azalan, artan, nə olursa olsun) açar yaradılarkən eyni anda təyin olunur və sonra onu dəyişdirmək mümkün deyil. Verilənlərin necə çeşidlənəcəyini və necə saxlanacağını fiziki olaraq müəyyən edir. Əgər siz Clustering açarını və ya çeşidləmə qaydasını dəyişməlisinizsə, yeni cədvəl yaratmalı və ona məlumat ötürməli olacaqsınız. Bu, mövcud olanla işləməyəcək.
Cədvəlimizi istifadəçilərlə doldurduq və gördük ki, onlar əvvəlcə doğum ili ilə, sonra isə hər bir qovşaqda maaş və istifadəçi identifikatoru ilə bir üzükə düşdülər. İndi məhdudiyyətlər qoyaraq seçə bilərik.
İşləyənimiz yenidən görünür where, and, və biz istifadəçilər əldə edirik və hər şey yenidən qaydasındadır. Lakin biz Klaster açarının yalnız bir hissəsindən və daha az əhəmiyyətli olandan istifadə etməyə çalışsaq, onda Cassandra dərhal xəritəmizdə null müqayisəçisi üçün bu sahələrin olduğu bu obyektin və bu obyektin yerini tapa bilmədiyindən şikayət edəcək. ki, yenicə qurulmuşdu, - o, haradadır. Mən yenidən bu qovşaqdan bütün məlumatları götürməli və filtrləməli olacağam. Və bu bir node daxilində Tam Scan analoqudur, bu pisdir.
Hər hansı bir qeyri-müəyyən vəziyyətdə, yeni bir cədvəl yaradın
İstifadəçiləri şəxsiyyət vəsiqəsinə, yaşa və ya maaşa görə hədəfə almaq istəyiriksə, nə etməliyik? heç nə. Sadəcə iki cədvəldən istifadə edin. İstifadəçilərə üç fərqli yolla çatmaq lazımdırsa, üç cədvəl olacaq. Vidada yer qənaət etdiyimiz günlər geridə qaldı. Bu ən ucuz resursdur. Bu, istifadəçi üçün zərərli ola biləcək cavab müddətindən qat-qat azdır. İstifadəçi üçün 10 dəqiqədən çox bir saniyədə bir şey almaq daha xoşdur.
Biz yaxşı miqyas almaq və etibarlı işləmək üçün lazımsız yer və normallaşdırılmamış məlumatları alqı-satqı edirik. Axı, əslində, hər birində beş qovşaq olan, məqbul səviyyədə məlumatların mühafizəsi səviyyəsinə malik (heç bir şey itirilməyəndə) üç məlumat mərkəzindən ibarət klaster bir məlumat mərkəzinin ölümündən tamamilə sağ çıxa bilir. Və qalan ikisinin hər birində daha iki qovşaq. Və yalnız bundan sonra problemlər başlayır. Bu, olduqca yaxşı bir ehtiyatdır, bir neçə əlavə SSD sürücüsü və prosessoruna dəyər. Buna görə heç vaxt SQL olmayan, heç bir əlaqəsi, xarici açarı olmayan Cassandra-dan istifadə etmək üçün sadə qaydaları bilmək lazımdır.
İstəyinizə uyğun olaraq hər şeyi dizayn edirik. Əsas odur ki, məlumat deyil, tətbiqin onunla necə işləyəcəyidir. Fərqli məlumatları müxtəlif yollarla və ya eyni məlumatları müxtəlif yollarla qəbul etmək lazımdırsa, biz onu tətbiq üçün əlverişli bir şəkildə qoymalıyıq. Əks halda, Tam Skanda uğursuz olacağıq və Cassandra bizə heç bir üstünlük verməyəcək.
Məlumatların normallaşdırılması normadır. Normal formaları unuduruq, artıq relyasiya verilənlər bazamız yoxdur. Bir şeyi 100 dəfə yerə qoysaq, 100 dəfə uzanacaq. Hələ dayanmaqdan daha ucuzdur.
Bölmə üçün düymələri seçirik ki, onlar normal şəkildə paylansınlar. Açarlarımızın hashinin bir dar diapazona düşməsini istəmirik. Yəni yuxarıdakı nümunədəki doğum ili pis nümunədir. Daha doğrusu, istifadəçilərimiz doğum illərinə görə normal paylansa yaxşıdır, əgər söhbət 5-ci sinif şagirdlərindən gedirsə, pisdir - orada bölgü o qədər də yaxşı olmayacaq.
Çeşidləmə Klaster Açarının yaradılması mərhələsində bir dəfə seçilir. Əgər dəyişdirilməlidirsə, cədvəlimizi başqa bir açarla yeniləməli olacağıq.
Və ən əsası: əgər eyni məlumatları 100 müxtəlif yolla əldə etmək lazımdırsa, onda 100 fərqli cədvəlimiz olacaq.
Mənbə: www.habr.com