Tərtibatçılar üçün NoSQL bələdçisi

Əgər backend inkişafı və Big Data tendensiyalarını izləyirsinizsə, çox güman ki, son illərdə NoSQL verilənlər bazası ətrafında səs-küy hiss etmisiniz. Bəzi insanlar verilənlər bazasına bu cür yanaşmadan ilhamlanır, bəziləri isə burada bir növ hiylənin gizləndiyini düşünür: onlarda olan məlumat modelləri adi relyasiya verilənlər bazaları ilə eyni deyil, tətbiqi proqramlaşdırma interfeysləri qeyri-adidir və tətbiqlər çox vaxt anlaşılmaz olur. Bu yazıda sizə ilk növbədə onların niyə yaradıldığını, bu NoSQL verilənlər bazalarını, hansı problemləri həll etdiklərini və nə üçün birdən-birə bu qədər müxtəlif verilənlər bazasına ehtiyac duyulduğunu söyləyəcəyəm. Əgər NoSQL-də yenisinizsə, məqalənin sonuncu hissəsi ilə maraqlana bilərsiniz, bu sahəni hərtərəfli başa düşmək üçün ilk növbədə araşdırmağa dəyər hesab etdiyim NoSQL verilənlər bazası növlərini sadalayır.

Niyə birdən-birə yeni verilənlər bazasına ehtiyacımız var?

Siz sual verməkdə çaşqın ola bilərsiniz: əlaqəli verilənlər bazalarında nə səhvdir? Məsələ burasındadır ki, onlar uzun illər həqiqətən yaxşı işləyiblər, amma indi bir problem var ki, artıq onların öhdəsindən gələ bilmirlər. Bəzi proqnozlara görə, 2018-ci ildə bəşəriyyət saniyədə 50 000 giqabayt məlumat istehsal edəcək. Bu, böyük miqdarda məlumatdır! Onun saxlanması və idarə olunması ciddi mühəndislik problemi yaradır. Ən pisi odur ki, bu həcm daim artır. Göründüyü kimi, relyasiya verilənlər bazaları həqiqətən böyük həcmli məlumatlarla işləmək üçün zəif uyğundur. Onlar bir maşında işləmək üçün nəzərdə tutulub və əgər siz daha çox sorğunu idarə etmək istəyirsinizsə, yeganə seçim daha çox RAM və daha güclü prosessoru olan kompüter almaqdır. Təəssüf ki, bir maşının idarə edə biləcəyi sorğuların sayı məhduddur və bir neçə maşın arasında paylanmış iş üçün bizə fərqli verilənlər bazası texnologiyası lazımdır. Əlbəttə ki, bəzi oxucular bu nöqtədə güləcək və deyəcəklər ki, əlaqəli verilənlər bazası vəziyyətində birdən çox maşından istifadə etmək üçün geniş istifadə olunan iki üsul var: replikasiya və parçalanma. Doğrudur, amma bu üsullar bizim vəzifələrimizin öhdəsindən gəlməyə kifayət etmir. Oxunun təkrarlanması hər bir verilənlər bazası yeniləməsinin yalnız oxumaq sorğularını idarə edə bilən digər maşınlara yayıldığı bir texnikadır. Bu halda, bütün dəyişikliklər master node adlanan bir server tərəfindən həyata keçirilir, digər serverlər isə oxunmuş replikalar adlanır, yalnız məlumatların surətlərini saxlayır. İstifadəçi istənilən maşından oxuya bilər, lakin məlumatları yalnız master node vasitəsilə dəyişə bilər. Bu, rahat və çox populyar bir üsuldur, lakin bu, yalnız daha çox oxunmuş sorğuları emal etməyə imkan verir və heç bir şəkildə tələb olunan həcmli məlumatların işlənməsi problemini həll etmir. Sharding , əlaqəli verilənlər bazasının çoxsaylı nümunələrindən istifadə edən başqa bir məşhur yanaşmadır. Onların hər biri məlumatların bir hissəsi üçün yazma və oxu əməliyyatlarını idarə edir. Verilənlər bazası müştərilər haqqında məlumatları saxlayırsa, məsələn, sharding istifadə edərək, bir maşın adları A ilə başlayan müştərilər üçün bütün sorğuları idarə edə bilər, başqa bir maşın adları B ilə başlayan müştərilər üçün bütün məlumatları saxlaya bilər və s. Sharding daha çox məlumat yazmağa imkan versə də, belə bir verilənlər bazasını idarə etmək əsl kabusdur: məlumatları maşınlar arasında uyğunlaşdırmalısınız və lazım olduqda çoxluğu hər iki istiqamətdə miqyaslandırmalısınız. Nəzəri cəhətdən sadə görünsə də, onu düzgün əldə etmək olduqca çətindir.

Əlaqəli verilənlər bazası təkmilləşdirilə bilərmi?

Düşünürəm ki, siz artıq relational verilənlər bazalarının müasir dünyada yaradılan məlumatların həcminə ən uyğun olmadığına inanmısınız. Baxmayaraq ki, hələ də heç kimin birdən çox maşın arasında səmərəli işləyə bilən "daha yaxşı" əlaqəli verilənlər bazası yaratmadığını hələ də merak edə bilərsiniz. Görünə bilər ki, bu texnologiya sadəcə olaraq hələ hazırlanmayıb və paylanmış əlaqəli verilənlər bazaları çox yaxında görünəcək. Təəssüf ki, bu baş verməyəcək. Bu, riyazi olaraq mümkün deyil və bununla bağlı heç nə etmək olmaz. Bunun niyə belə olduğunu başa düşmək üçün CAP teoreminə (aka Brewer teoremi) baxmaq lazımdır. Bu, 1999-cu ildə sübut edilmişdir və burada deyilir ki, bir neçə maşında işləyən paylanmış verilənlər bazası aşağıdakı üç xüsusiyyətə malik ola bilər: Ardıcıllıq - istənilən oxu əməliyyatı sonuncu müvafiq yazma əməliyyatının nəticələrini qaytarır. Sistem ardıcıldırsa, yeni məlumatlar yazdıqdan sonra köhnə, artıq yazılmış məlumatları oxumaq mümkün deyil. Mövcudluq ( Mövcudluq ) - paylanmış sistem istənilən vaxt daxil olan sorğuya xidmət göstərə və səhvsiz cavab qaytara bilər. Bölmələrə dözümlülük - verilənlər bazası bəzi serverləri müvəqqəti olaraq bir-biri ilə əlaqə qura bilmədikdə belə oxumaq və yazma sorğularına cavab verməyə davam edir. Bu müvəqqəti nasazlıq şəbəkəyə qoşulma nasazlığı adlanır və serverin yavaş işləməsi səbəbindən fiziki şəbəkə problemlərindən tutmuş şəbəkə avadanlığının fiziki zədələnməsinə qədər müxtəlif amillər səbəb ola bilər. Bu xassələrin hamısı əlbəttə ki, əlverişlidir və biz, həqiqətən, onların hamısını birləşdirmək üçün verilənlər bazası istərdik. Heç bir sağlam tərtibatçı əvəzində heç nə almadan əlçatanlıqdan imtina etmək istəməz. Təəssüf ki, CAP teoremi də bildirir ki, hər üç xüsusiyyətin eyni vaxtda olması qeyri-mümkündür. Bunu dərk etmək asan olmaya bilər, amma mümkündür. Birincisi, paylanmış verilənlər bazasına ehtiyacımız varsa, o, "əlaqəni kəsməyə dözümlü" olmalıdır. Bu, hətta müzakirə olunmur. Bağlantıların kəsilməsi hər zaman olur və buna baxmayaraq bizim verilənlər bazamız işləməlidir. İndi gəlin başa düşək ki, niyə həm ardıcıllığa, həm də əlçatanlığa nail ola bilmirik. Təsəvvür edin ki, bizdə iki maşında işləyən sadə verilənlər bazası var: A və B. İstənilən istifadəçi hər iki maşına yaza bilər, bundan sonra məlumatlar digərinə kopyalanır. İndi təsəvvür edin ki, bu maşınlar müvəqqəti olaraq bir-biri ilə əlaqə qura bilmir və B maşını A maşınına məlumat göndərə və ya ondan məlumat ala bilmir. Bu müddət ərzində B maşını müştəridən oxuma sorğusu alırsa, onun iki variantı var:

1. Ən son olmasa belə, yerli məlumatlarınızı geri alın. Bu vəziyyətdə, mövcudluğa üstünlük verilir (ən azı bəzi məlumatları, hətta köhnəlmiş məlumatları qaytarmaq üçün).
2. Qaytarma xətası. Bu vəziyyətdə ardıcıllığa üstünlük verilir: müştəri köhnəlmiş məlumatları almayacaq, lakin ümumiyyətlə heç bir məlumat almayacaq.

Əlaqəli verilənlər bazaları eyni vaxtda "ardıcıllıq" və "mövcudluq" xüsusiyyətlərini təcəssüm etdirməyə çalışır və buna görə də paylanmış mühitdə işləyə bilməz. Paylanmış bir sistemdə əlaqəli verilənlər bazasının bütün imkanlarını tətbiq etməyə çalışmaq ya qeyri-real, ya da sadəcə olaraq mümkün olmayacaqdır . Digər tərəfdən, NoSQL verilənlər bazaları miqyaslılığa və performansa əsas diqqət yetirir. Onlar adətən bağlantılar və əməliyyatlar kimi "əsas" xüsusiyyətlərə malik deyillər və məlumat modeli tamamilə fərqli olur, bəlkə də hansısa şəkildə məhdudlaşdırır. Bütün bunlar daha böyük həcmdə məlumat saxlamağa və əvvəlkindən daha çox sorğunu emal etməyə imkan verir.

NoSQL verilənlər bazaları ardıcıllıq və mövcudluğu necə balanslaşdırır?

Sizə elə gələ bilər ki, əgər siz NoSQL verilənlər bazası seçsəniz, hər hansı bir uğursuzluq halında həmişə ya bəzi köhnəlmiş məlumatları, ya da xəta alacaqsınız. Praktikada mövcudluq və ardıcıllıq heç bir halda yeganə mövcud seçim deyil. Seçmək üçün çoxlu seçimlər mövcuddur. Əlaqəli verilənlər bazalarında bu seçimlər yoxdur, lakin NoSQL sorğunun icrasına oxşar şəkildə nəzarət etməyə imkan verir. Bu və ya digər şəkildə, onlar NoSQL verilənlər bazasında yazma və ya oxuma əməliyyatlarını yerinə yetirərkən iki parametr təyin etməyə imkan verir: W - yazma əməliyyatını yerinə yetirərkən çoxluqdakı neçə maşın məlumatların saxlanmasını təsdiqləməlidir . Məlumatlarınızı yazdığınız maşınların sayı nə qədər çox olarsa, növbəti oxuma əməliyyatı üzrə ən son məlumatları oxumaq bir o qədər asan olacaq, həm də bir o qədər uzun sürəcək. R – məlumatı neçə maşından oxumaq istərdiniz . Paylanmış sistemdə məlumatların klasterdəki bütün maşınlara paylanması müəyyən vaxt apara bilər, buna görə də bəzi serverlər ən son məlumatlara sahib olacaq, digərləri isə gecikəcək. Məlumatların oxunduğu maşınların sayı nə qədər çox olarsa, cari məlumatları oxumaq şansı bir o qədər yüksəkdir. Praktik bir nümunəyə baxaq. Klasterinizdə beş kompüteriniz varsa və yalnız birinə məlumat yazmaq qərarına gəlsəniz və sonra təsadüfi seçilmiş bir kompüterdən məlumatları oxuyursunuzsa, köhnə məlumatları oxumaq şansınız 80% olacaq. Digər tərəfdən, bu, minimum resurslardan istifadə edəcəkdir. Beləliklə, köhnə məlumatlar sizin üçün yaxşıdırsa, bu o qədər də pis seçim deyil. Bu halda W və R parametrləri 1-ə bərabərdir. Digər tərəfdən, NoSQL verilənlər bazasındakı bütün beş maşına məlumat yazsanız, istənilən maşından məlumatları oxuya bilərsiniz və hər dəfə yeni məlumat əldə etməyinizə zəmanət verilir. Daha çox sayda maşında eyni əməliyyatı yerinə yetirmək daha uzun çəkəcək, lakin yeni məlumatlar sizin üçün vacibdirsə, bu seçimi seçə bilərsiniz. Bu halda, W = R = 5. Verilənlər bazası ardıcıllığı üçün tələb olunan minimum oxuma və yazma sayı nə qədərdir? Budur sadə bir düstur: R + W ≥ N + 1 , burada N çoxluqdakı maşınların sayıdır. Bu o deməkdir ki, beş serverlə siz ya R = 2 və W = 4, ya da R = 3 və W = 3, ya da R = 4 və W = 2 seçə bilərsiniz. Bu halda verilənlərin hansı maşınlara verilməsinin fərqi yoxdur. yazılır, oxunması həmişə ən azı bir maşından aktual məlumatlarla həyata keçiriləcək. DynamoDB kimi digər verilənlər bazaları müxtəlif məhdudiyyətlərə malikdir və yalnız ardıcıl yazmağa imkan verir. Hər bir məlumat parçası üç serverdə saxlanılır və hər hansı məlumat yazıldıqda üç maşından ikisinə yazılır. Lakin məlumatları oxuyarkən iki seçimdən birini seçə bilərsiniz:

1. Verilənlərin üçdən iki maşından oxunduğu və həmişə ən son yazılan məlumatları qaytaran ciddi ardıcıl oxunur.
2. Məlumatı oxumaq üçün bir maşının təsadüfi seçildiyi son ardıcıl oxunuş. Bununla belə, bu, köhnəlmiş məlumatları müvəqqəti olaraq qaytara bilər.

Niyə bu qədər çox NoSQL verilənlər bazası var?

Proqram təminatının inkişafı sahəsində ən son xəbərləri izləyirsinizsə, yəqin ki, MongoDB, DynamoDB, Cassandra, Redis və bir çox başqaları kimi bir çox müxtəlif NoSQL verilənlər bazası haqqında eşitmisiniz. Sizi maraqlandıra bilərsiniz: niyə bizə bu qədər müxtəlif NoSQL verilənlər bazası lazımdır? Səbəb sadədir: müxtəlif NoSQL verilənlər bazası müxtəlif problemləri həll etmək üçün nəzərdə tutulmuşdur. Buna görə rəqabət aparan verilənlər bazalarının sayı çox böyükdür. NoSQL verilənlər bazası dörd əsas kateqoriyaya bölünür:

Sənəd yönümlü verilənlər bazası

Bu verilənlər bazaları mürəkkəb daxili sənədləri saxlamaq imkanı verir, halbuki əksər əlaqəli verilənlər bazaları yalnız bir ölçülü sətirləri dəstəkləyir. Bu funksiya bir çox hallarda, məsələn, sistemdə bir neçə ünvanı olan istifadəçi haqqında məlumat saxlamaq lazım olduqda faydalı ola bilər. Sənəd yönümlü verilənlər bazasından istifadə edərkən, bu halda siz sadəcə olaraq ünvanlar massivindən ibarət mürəkkəb obyekti saxlaya bilərsiniz, halbuki relational verilənlər bazasında siz iki cədvəl yaratmalısınız: biri istifadəçi məlumatı, digəri isə ünvanlar üçün. Sənəd yönümlü verilənlər bazaları obyekt modeli ilə verilənlər modeli arasındakı boşluğu aradan qaldırır . PostgreSQL kimi bəzi əlaqəli verilənlər bazaları indi də sənəd yönümlü yaddaşı dəstəkləyir, lakin əksər əlaqəli verilənlər bazalarında hələ də bu imkan yoxdur.

Açar/Dəyər Bazaları

Açar/dəyər verilənlər bazaları adətən ən sadə NoSQL modelini həyata keçirir. Əslində, onlar sizə verilmiş bir açara məlumat yazmağa və ondan istifadə edərək onu oxumağa imkan verən paylanmış hash cədvəli ilə təmin edirlər. Açar/dəyər verilənlər bazaları yüksək dərəcədə genişlənə bilir və digər verilənlər bazalarına nisbətən xeyli aşağı gecikmə müddətinə malikdir.

Qrafik verilənlər bazaları

Bir çox mövzu sahələri, məsələn, sosial şəbəkələr və ya filmlər və aktyorlar haqqında məlumatlar qrafiklər şəklində təqdim edilə bilər. Qrafik əlaqə verilənlər bazasından istifadə etməklə təqdim oluna bilsə də, çətin və əlverişsizdir. Qrafik məlumatlarına ehtiyacınız varsa, qrafik haqqında məlumatı paylanmış çoxluqda saxlaya bilən və qrafiklərdə alqoritmləri səmərəli şəkildə həyata keçirməyə imkan verən ixtisaslaşmış qrafik verilənlər bazasından istifadə etmək daha yaxşıdır.

Sütunlu verilənlər bazaları

Sütunlu verilənlər bazası ilə digər verilənlər bazası arasındakı əsas fərq verilənlərin diskdə saxlanma üsuludur. Əlaqəli verilənlər bazaları hər bir cədvəl üçün bir fayl yaradır və bütün sətirlərin dəyərlərini ardıcıl olaraq saxlayır. Sütunlu verilənlər bazaları cədvəllərinizdə hər bir sütun üçün bir fayl yaradır. Bu struktur sizə məlumatları ümumiləşdirməyə və müəyyən sorğuları daha səmərəli icra etməyə imkan verir, lakin siz məlumatların bu cür verilənlər bazalarının məhdudiyyətlərinə uyğun olmasını təmin etməlisiniz.

Hansı verilənlər bazasını seçməlisiniz?

Verilənlər bazasını seçmək, adətən, sinir bozucu bir problemdir və bu qədər çox variantın mövcudluğu ilə bu, hədsiz iş kimi görünə bilər. Yaxşı xəbər budur ki, yalnız birini seçməyə ehtiyac yoxdur. Bütün imkanları həyata keçirən və bütün sistem məlumatlarına çıxışı olan vahid monolit proqram yaratmaq əvəzinə, mikroservislər adlı başqa bir müasir modeldən istifadə edə bilərsiniz : tətbiqi müstəqil xidmətlər dəstinə bölmək. Hər bir xidmət öz dar problemini həll edir və yalnız bu problemin həlli üçün ən uyğun olan öz verilənlər bazasından istifadə edir.

Bütün bunları necə öyrənməlisən?

Bu qədər verilənlər bazası ilə onların hamısını öyrənmək qeyri-mümkün bir iş kimi görünə bilər. Yaxşı xəbər: bunu etmək lazım deyil. NoSQL verilənlər bazalarının yalnız bir neçə əsas növü var və onların necə işlədiyini başa düşsəniz, digərlərini başa düşmək daha asan olacaq. Həmçinin, bəzi NoSQL verilənlər bazaları digərlərinə nisbətən daha tez-tez istifadə olunur, buna görə də səylərinizi ən populyar həllər üzərində cəmləmək yaxşıdır. Ən çox istifadə olunan NoSQL verilənlər bazası siyahısına nəzər salmalı olduğunuzu düşünürəm:

1. MongoDB . Yəqin ki, bazarda ən populyar NoSQL verilənlər bazası. Əgər şirkət əsas məlumat anbarı kimi əlaqəli verilənlər bazasından istifadə etmirsə, ehtimal ki, MongoDB-dən istifadə edir. Bu, yaxşı alətlər dəsti ilə çevik sənəd saxlama yeridir. Karyerasının əvvəlində MongoDB bəzi hallarda məlumatların itirilməsi ilə bağlı pis reputasiyaya malik idi , lakin o vaxtdan onun sabitliyi və etibarlılığı xeyli yaxşılaşmışdır. Daha çox öyrənmək istəyirsinizsə, bu MongoDB kursuna nəzər salın


2. DynamoDB . Əgər siz Amazon Veb Xidmətlərindən (AWS) istifadə edirsinizsə, DynamoDB haqqında daha çox öyrənəsiniz. Bu, zəngin xüsusiyyətlər dəsti və bir çox digər AWS xidmətləri ilə inteqrasiyası ilə son dərəcə etibarlı, genişlənən, aşağı gecikmə verilənlər bazasıdır. Ən yaxşı tərəfi odur ki, onu özünüz yerləşdirməyə ehtiyac yoxdur. Minlərlə sorğuları idarə edə bilən genişlənə bilən DynamoDB klasterinin qurulması bir neçə klikdir. Əgər bu sizi maraqlandırırsa, bu kursa nəzər sala bilərsiniz.


3. Neo4j . Ən çox yayılmış qrafik verilənlər bazası. Bu, qrafik məlumat modelindən istifadə etmək istəyənlər üçün uyğun olan miqyaslana bilən və sabit bir həlldir. Daha çox öyrənmək istəyirsinizsə, bu kursla başlayın .


4. Redis . Burada təsvir edilən digər verilənlər bazaları əsas proqram məlumatlarını saxlamaq üçün istifadə edilsə də, Redis ilk növbədə keşləri həyata keçirmək və köməkçi məlumatları saxlamaq üçün istifadə olunur. Bir çox hallarda yuxarıda qeyd olunan verilənlər bazalarından biri Redis ilə tandemdə istifadə olunur. Daha çox öyrənmək üçün bu kursu yoxlayın .

2018-ci ildə NoSQL ilə

NoSQL verilənlər bazaları geniş və sürətlə inkişaf edən bir sahədir. Onlar sizə əvvəllər ağlasığmaz həcmdə məlumatı saxlamağa və emal etməyə imkan verir, lakin bu, baha başa gəlir. Bu verilənlər bazalarında əlaqə verilənlər bazalarında tanış olduğunuz bir çox xüsusiyyət yoxdur və onlardan istifadə etmək üçün özünüzü qurmaq çətin ola bilər. Lakin siz bunlarla tanış olduqdan sonra siz heyrətamiz həcmdə oxumaq və yazma sorğularını idarə edə bilən miqyaslana bilən, paylanmış verilənlər bazaları yarada bilərsiniz ki, bu da daha böyük və daha böyük həcmli məlumatların yaradılması ilə son dərəcə vacib ola bilər. Orijinal: https://simpleprogrammer.com/guide-nosql-software-developers/