Menyu

Layihəyə uyğun məlumat bazasının seçimi

Dostum mənə deyirdi: “Görəcəyin iş üçün düzgün alət istifadə et, əksinə yox”. Hər-hansı tətbiq və ya proqram təminatının hazırlanmasına gəldikdə isə düzgün məlumat bazasının seçilməsi ən vacib qərarlardandır. Bu məqalədə, 7 məlumat bazası ailəsinə (növünə) nəzər yetirəcəyik. Çox güman ki, bunlardan bəziləri haqqında artıq eşitmiş və ya artıq tətbiq etmiş ola bilərsiniz. Həmçinin, ilk dəfə tanış olacaqlarınız da ola bilər. Həmçinin, məlumat bazalarının texniki cəhətdən necə işlərdikləri ilə tanış olacaq və ən əsası onlardan ən yaxşı istifadənin hansı hallarda uyğun olduğunu başa düşməyə çalışacağıq. Daha bir dost deyimi ilə desək: “Güllə atəşi olan yerə, bıçaqla getməzlər”.
Siyahımız ən sadə verilənlər bazası növü ilə başlayacaq və yeddinci növə yaxınlaşdıqca tədricən daha da mürəkkəbləşəcək. Lakin bundan qorxmaqa dəyməz smiley 

key value

Beləliklə ilk məlumat bazası ailəsinə (növünə) gəldik. Key-Value Databases – Hərfi mənada tərcümə etsək “Açar – Dəyər” məlumat bazaları. Bu növ məlumat bazalarına misal olaraq Redis, MemcachedEtcd göstərmək olar. Burada verilənlər bazası, JavaScript obyekti və ya Python lüğəti ilə oxşar formada realizasiya olunmuşdur. Təsəvvür edin ki, sizdə bir neçə unikal açar var və hər açar üçün müəyyən dəyər qeydə alınmışdır. Redis -də məsələn, biz məlumatların oxunmasını və ya yazılmasını əmrlər vasitəsi ilə həyata keçiririk. Məlumat yazılması üçün “SET” əmri və sonra açar və dəyər qeyd olunmaqla icra olunur ( SET user:21:name “Kibrit” ). Əksinə hər hansı bir açara aid olan dəyəri oxumaq üçün isə “GET” əmrini açarla birlikdə icra edirik (GET user:21:name və geriyə “Kibrit” cavabını alırıq). Redis və Memcached -də bütün məlumatlarını diskdə saxlayan əksər verilənlər bazalarından fərqli olaraq, məlumatlar operativ yaddaşda saxlanılır (RAM – Random Access Memory). Bu saxlaya biləcəyiniz məlumat miqdarını operativ yaddaşın faktiki miqdarına qədər məhdudlaşdırır. Lakin verilənlər bazasını son dərəcə sürətli edir, çünki hər əməliyyatın icra olunması - diskdən oxunmanı tələb etmir. Əməliyyat zamanı sorğu göndərilməsi, disklər daxili bağlantı və s. bu kimi proseslər icra olunmur. Bu səbəbdən məlumat modelləşdirmə kimi funksiyalar bu tip bazalarda çox limitlidir. Ancaq burada əməliyyatlar çox tez, 1 millisaniyəyə qədər tez icra olunur. Proqram təminatınıza aid əsas məlumatları bu tip bazalarda saxlamaq istəməzsiniz. Əksinə bu bazalar ən çox məlumat ötürmə zamanı gecikmələrin olmaması və ya minimum olması üçün istifadə olunur. Twitter, GitHub və Snapchat kimi tətbiqetmələr real vaxt məlumatlarını çatdırmaq üçün Redis -dən istifadə edir. Əksər hallarda belə quruluşa malik məlumat bazaları əsasas məlumat bazaları üçün “cache” olaraq istifadə olunur.

wide column

Səmimi olsaq “Açar-dəyər” cütlərini dəstəkləyən məlumat bazaları açıq şəkildə digər növlərdən daha məhduddur. Artıq bu problem bizi, Wide-Column Databases – “Geniş – Sütun” tipli məlumat bazalarına müraciət etməyə məcbur edir. Apache CassandraApache HBase bu ailədəki məşhur seçimlərdəndir. “Geniş – Sütun” tipli məlumat bazasını təsəvvür etmək istəyirsinizsə, “Açar – Dəyər” tipli baza götürüb, ona ikinci fəza əlavə edin. Belə ki, burada artıq hər “Açar” üçün vahid “Dəyər” əvəzinə - sütunlardan ibarət məlumat massivi yerləşir. Hər sütun daxilində də müxtəlif dəyərlər qeyd oluna bilər. Bu bir-biri ilə bilavasitə əlaqəli müxtəlif məlumatların bir araya toplanmasına imkan verir. Ancaq əlaqəli (relational) verilənlər bazasından fərqli olaraq, burada məlumatları əlaqələndirən sxem yoxdur. Bu bu tip məlumat bazalarında yalnız strukturlaşdırılmamış (non-relational) məlumatlar idarə oluna bilər. Proqramçılar üçün bu çox əlverişlidir, çünki onlara öz sorğulalarını icra etmək üçün “CQL” sorğu dili təqdim olunur. Bu dil hamının eşidib – bildiyi “SQL” dilinə çox bənzəyir. Lakin “SQL” -dən fəqli olaraq burada sxema olmadığı üçün “JOİN” – kimi sorğu əməliyyatlarının icrası mümkün deyil. “SQL” tipli məlumat bazalarından fərqli olaraq, bu tip məlumat bazaları “mərkəzləşmiş” deyildir, onların üfüqi yaradılması (horizontal scaling) və “replikasıya” -sını icra etmək olduqca asandır. Adətən bu bazalardan böyük həcmli “time-series” tipli məlumatların yığılmasında, məs. müəyyən İOT cihazlardakı müxtəlif sensor məlumatlarının yığılmasında istifadə olunur. Netflix sizin baxdığınız film və şouların tarixçəsini bu tip məlumat bazalarında saxlayır. Qısa desək, Cassandra və Hbase kimi məlumat bazaları tez-tez yazma, lakin nadir hallarda yenilənmə və oxunma əməliyyatlarının icra olunduğu hallarda istifadə olunur. Burdan anlamaq olar ki, bu tip məlumat bazalarını, tətbiqiniz üçün əsas məlumat bazası kimi seçmək effektiv olmayacaq.

document

Tətbiqiniz üçün daha ümumiləşdirilmiş, “Document – Oriented Databases” – “Sənəd -yönümlü” məlumat bazasından istifadə etmək, öncə haqqında danışdığımız “Geniş – Sütun” tipli bazalardan daha effektiv olacaqdır. Bu ailəyə məxsus tanınmış məlumat bazalarına, Cloud Firestore, MongoDB, Amazon DynamoDB , Apache CouchDB və başqalarını misal göstərmək olar. Bu məlumat bazasını təsəvvür etmək üçün, daxilində “Açar – Dəyər” cütlərinin yerləşdiyi sənədlərinizin olduğunu düşünün. Sənədlər strukturlaşmadığından onlar üçün bir sxem tələb olunmur. Daha sonra sənədlər “kolleksiyalar” -da birləşdirilir. Bir kolleksiyadakı sahələr indeksləşdirilə, bir neçə kolleksiya isə məntiqi iyerarxiya şəklində təşkil oluna bilər. Bu, öz növbəsində əlaqəli məlumatları olduqca əhəmiyyətli dərəcədə modelləşdirməyə və əldə etməyə imkan verir. Bu ailədəki məlumat bazaları da “JOİN” tipli əməliyyatları dəstəkləmirlər və əlaqəli məlumatları kiçik hisslərlə yox, vahid sənəddə toplamaq tövsiyyə olunur. Front – End tipli tətbiqlər üçün məlumat oxunmasını olduqca sürətli, yeni məlumat yazılması və ya məlumat yenilənməsini nisbətən mürəkkəb edir. “Sənəd yönümlü” verilənlər bazaları indiyə qədər nəzərdən keçirdiyimiz digər seçimlərdən daha ümumi məqsədlidir. Bir proqramçı baxımından istifadəsi olduqca asandır. Adətən mobil oyunlar, məzmun redaktorları tərəfindən və .s oxşar hallarda istifadə olunması olduqca əlverişlidir. Ümumiyyətlə istifadə edəcəyiniz məlumatların strukturunun necə olacağından əmin deyilsinizsə, “Sənəd yönümlü” verilənlər bazası başlamağınız üçün ideal yerdir. Çox sayda istifadəçi, dost, şərh və bəyənmə kimi bir-biri ilə əlaqəli çoxsaylı məlumat yenilənməsi olan bir sosial şəbəkə tətbiqi üçün bu ailədəki məlumat bazasından istifadə etmək məqsədə uyğun sayılmır. Dostlarınızın sizə yazdıqları şərhləri görmək istəsəz, ilk olaraq cari şərhlərə aid məlumatları bazadan oxumaq lazımdır. Bu cür məlumatların toplanması üçün “JOİN” tipli əməliyyatlar aparılmalıdır. Bunu icra etmək, “Sənəd - yönümlü” məlumat bazası miqyasında asan deyil.

reational

Xoşbəxtlikdən, demək olar ki, əsrlərdən bəri mövcud olan və əlaqəli verilənlər bazası deyilən “Relational Databases” mövcuddur. Çox güman ki, bu tip verilənlər bazası ilə MySQL, PostgreSQL, SQL Server və daha çox bazalarla tanışsınız. Təxminən 50 ildir mövcuddurlar və bu gün dünyanın ən populyar verilənlər bazaları ailəsi olaraq qalırlar. İlk dəfə bu tip məlumat bazası fikri, kompyuter elmləri ailimi Ted Kord tərəfindən düşünülmüşdür. O, IBM-də işləmiş və illərlə əlaqəli məlumat modelləşdirmə nəzəriyyələrini inkişaf etdirmişdir. İnternetdə onun orijinal məqaləsini oxuya bilərsiniz, amma öncədən deyim yazdığının əksəriyyətini anlaya bilmədim. Ən azından, əlaqə verilənlər bazasının yaradılması, inkişafı üçün sərf olunmuş riyaziyyat və elmin miqdarını qiymətləndirə bilərsiniz. Məncə günümüzdə bu qədər populyar olması elə bundan qaynaqlanır. İlk məqalədən bir neçə il sonra, SQL və ya strukturlaşdırılmış sorğu dilininin yaradılmasına proqramçılara ilham verəcəkdir. Verilənlər bazasında məlumat əldə etməyə və yazmağa imkan verən sorğu dili - SQL adlanan xüsusi bir proqramlaşdırma dilidir. Tamam, amma əlaqəli verilənlər bazası dedikdə əslində nə demək istəyirik?
Təsəvvür edin ki, təyyarələr düzəldən bir müəssisəniz var. Bu müəssisə sizin verilənlər bazanızdır. Və bu verilənlər bazasında mühərriklər, təkərlər və s. kimi müxtəlif hissələri saxlayan fərqli anbarlarınız ola bilər, hər bir anbar müəyyən bir hissəni tutmaq üçün verilənlər bazası masasına bənzəyir. Hər bir fərdi hissənin unikal şəkildə müəyyənləşdirilməsi üçün seriya nömrəsi - “Açarı” var. Və fərdi bir hissəni cədvəldəki bir sıra kimi düşünə bilərsiniz. İndi bu hissələrin hamısını ayrı-ayrı anbarlara ayırdıqdan sonra, necə təyyarə düzəldə bilərik? Məhz indi “əlaqə” -lərin necə vacib olduğunu görürük. Təyyarəni müxtəlif detallardan yığa bilməyimiz üçün unikal “açar” -ları ilə uyğun anbarlardan toplaya bilərik. Hər detalın özünə aid yeganə və unikal “açar” -ının olduğunu anlamaq çox vacibdir. Bu açar – “Əsas açar” olaraq adlandırılır və detalın öz anbarında olan seriyasıya istinad edir. Digər anbarda da bu detalı tapa bilmək üçün ona məxsus seriya (açar) qeyd oluna bilər. Artıq belə açar, başqa anbarda (cədvəldə) olduğu üçün “Xarici Açar” olaraq adladırılır.

Nəticədə biz, bütün bu məlumatları bir araya gətirmək üçün sadəcə bir sorğu yerinə yetirməliyik. Bu tip məlumat bazalarının məntiqi, böyük həcmdə olan məlumatların daha kiçik parçalar şəklində təşkil olunmasıdır. Bu məntiqin müsbət cəhətləri çox olduğu kimi, mənfi cəhətləri də vardır. Əsas potensial çətinlik, bu tip bazaların mütləq “məlumat sxem” -inə ehtiyac duymalarıdır. Əgər tətbiqinizdə olacaq məlumatların strukturunu öncədən bilmirsinizsə, növbəti mərhələlərdə məlumat bazası ilə işiniz çətinləşə bilər. Əlaqəli məlumat bazaları ACİD standartı ilə uyğundur, yəni verilənlər bazasındakı hər hansı bir əməliyyatın doğru olmasına şəbəkə və ya texniki nasazlıqlar halında belə zəmanət verilir. Bu, banklar və maliyyə qurumları kimi idarələr üçün çox vacibdir. Lakin bu tip məlumat bazasını miqyaslaşdırmağı (scale up) olduqca çətinləşdirir. Buna baxmayaraq günümüzdə yüklənməsindən asılı olaraq avtomatik miqyaslaşan, CockroachDB kimi məlumat bazaları da artıq vardır. Hər iki halda da, əlaqəli verilənlər bazaları bu gün istifadədə ən populyar verilənlər bazası olaraq qalır.

graph

Bəs bir sxemdə münasibətləri modelləşdirmək əvəzinə, münasibətlərin özlərini məlumat kimi qəbul etsək nə olar? Qraf (Graph) ailəsinə məxsus verilənlər bazası əldə etmiş olarıq! Bu ailədə, öz aralarında ixtiyari qaydada birləşmiş (tillər vasitəsilə - “edge”) müəyyən sayda (sıfır da ola bilər) təpədən (“node”) ibarət olan verilənlər mövcuddur. Bu ailədə populyar seçimlərə DgraphNeo4j kimi məlumat bazalarını misal göstərmək olar. Təsəvvür edək ki, əlaqəli (relational) verilənlər bazasında bir-biri əlaqəli münasibətlər qurmaq istəyirik. Bunu etmək üçün, verilənlər bazasında əlaqələri təyin edən xarici açarlardan ibarət bir masa yaradacağıq. Qraf ailəsinə məxsus məlumat bazasında bu vasitəçi masaya ehtiyacımız yoxdur. Burada yalnız bir till (“edge”) müəyyənləşdiririk və qeydlərə (“node”) bağlayırıq. İndi bu məlumatları daha qısa və oxunaqlı bir operatordan istifadə edərək sorğu edə bilərik. Əlavə olaraq, xüsusən böyük miqdarda məlumatla işləyərkən daha yüksək performans əldə edirik. Çoxsaylı qoşuma və əlaqələnmə - “JOİN” tipli əməliyyat icra etdiyinizdən sistem performansı aşağı düşdüyündən, Qraf tipli məlumat bazası sizin üçün əla alternativ ola bilər. Bu bazalar tez zamanda maliyyə sistemlərində fırıldaqçılıq hallarını aşkarlamaq, şirkətlər daxilində daxili bilik qrupları yaratmaq və Airbnb-nin istifadə etdiyi kimi, tövsiyə mühərrikləri üçün istifadə olunur.

 


İndi Google-a bənzər bir axtarış sistemi yaratmaq istədiyinizi düşünək. İstifadəçi, verilənlər bazanızın cavab qaytarması üçün lazım olan miqdardan daha az miqdarda mətn daxil edir. Ən uyğun nəticələr çox sayda məlumatdan müvafiq qaydada sıralanır. Bunun üçün tam mətn axtarış motoru istəyəcəksiniz. Bu məkandakı məlumat bazalarının əksəriyyəti, SolrElasticSearch kimi 1999-cu ildən bəri davam edən Apache Lucene layihəsinin əsasını təşkil edir. Əlavə olaraq Algolia kimi bulud əsaslı və Rust proqramlaşdırma dili əsaslı MeiliSearch alətləri “axtarış mühərriki” ailəsinə məxsus məlumat bazalarıdır. Proqramçı tərəfindən baxsaq, bu bazalar öncə haqqında danışdığımız “Sənəd-yönümlü” bazalara çox oxşayır. Bir indekslə (açarla) başlayırsız və ona çox sayda məlumat obyektləri əlavə edə bilirsiniz. Fərq ondadır ki, məlumat bazası ona daxil olunmuş sənəddəki bütün mətni öncədən təhlil edir və istifadə olunan axtarış terminlərinə aid indekslər yaradır. Mahiyyət etibarilə bu, dərsliyin arxasında tapacağınız mündəricat kimi işləyir. İstifadəçi axtarış edən zaman məlumat bazası özündə olan hər sənəddə yox, əksinə ancaq indekslər üzrə axtarış edir. Buda axtarış müddəti inanılmaz dərəcədə sürətli edir. Çox sayda məlumatla işləyərkən verilənlər bazası nəticələri sıralamaq, əhəmiyyətsiz nəticələri kənarlaşdırmaq, səhv yazıları ayırmaq və s. üçün bir çox fərqli alqoritmlərdən istifadə edə bilər. Bütün bu proseslər müəyyən hesablama gücü tələb etdiyindən istifadəsi əlavə xərclər tələb edir və bu tip bazaları böyük miqyasda işə salmaq baha başa gələ bilər. Eyni zamanda bir axtarış sistemi kimi bir tətbiq qurursanız, istifadəçi təcrübəsinə əvəzedilməz dəyər əlavə edə bilər.

multi model


Bununla da, yeddinci nömrəyə, “Multimodel” məlumat bazasına çatdıq, mənim fikrimcə bu siyahımızda, öyrənilməsi və tətbiqi ən həyəcan verici olan məlumat bazası ailəsidir. Bu ailədə də diqqəti cəlb edən bir neçə fərqli seçim var. Ancaq bu məqaləmdə diqqət etmək istədiyim verilənlər bazası indiyə qədər baxdığımız bütün sistemlərdən çox fərqli olan, FaunaDB-dir. Əgər Front-End təyinatlı proqramçısınızsa həqiqətən önəm verdiyiniz şey, tətbiqdə istifadə edəcəyiniz məlumatlardır. Səmimi olsaq, sizə lazım olan yeganə mövhum məlumatları özündə saxlayan JSON -dur. Məlumatların modelləşdirilməsi, sxemlərin qurulması, replikasiya və ya bunlara bənzər əməliyyatlar haqqında düşünmək istəməzsiniz. FaunaDB ilə GraphQL sxemlərdən istifadə edərək, sadəcə məlumatlarınızı necə əldə etmək istədiyinizi təsvir edirsiniz. İndiki nümunəmizdə bir istifadəçi modeli və bir istifadəçinin bir çox paylaşıma sahib ola biləcəyi paylaşım modeli nəzərdən keçirək. GraphQL sxemlərimizi yeniləsək, FaundaDB avtomatik olaraq məlumatları sorğu etmək üçün indeksdə saxlaya biləcəyimiz kolleksiyalar yaradır. Pərdə arxasında Qraf, əlaqəli və sənəd kimi birdən çox verilənlər bazası ailəsində necə yararlanacağınızı müəyyənləşdirir və təqdim etdiyiniz GraphQL sxemi əsas götürərək bu ailələrdən ən yaxşı şəkildə necə istifadə edəcəyinizi müəyyənləşdirir. Sənəd verilənlər bazası kimi kolleksiyalara sənədlər əlavə edərək məlumat yaradırsınız. Bununla birlikdə, əlaqəli bazalardakı kimi, məlumat modelləşdirməsinin özünəməxsus məhdudiyyətləri ilə qarşılaşmırsınız. Bundan əlavə, FaunaDB ACID standartına uyğundur, sistem çox sürətli işləyir və artıq yüklənmə zamanı əlavə infrastruktur qurmaqdan əsla narahat olmayacaqsınız. Sadəcə məlumatlarınızı necə istifadə etmək istədiyinizə qərar verirsiniz və FaunaDB sizin üçün qalanını edir.
Beləliklə, birlikdə məqaləmin sonuna çatdıq. Düzdür, bütün məlumat bazaları növlərini əhatə etmədik. “Zaman-seriyası” (Time-Series) verilənlər bazaları və ayrıca məlumat anbarları kimi bilmək istəyə biləcəyiniz bir neçə digərləri mövcuddur.