BASE vs ACID

6.1 BASE vs. ACID: Qısaltmaların döyüşü

 Kimyada pH, sulu məhlulun nisbi turşuluğunu ölçür.
pH 0-dan (güclü turşular) 14-ə (güclü qələvilər) qədər uzanır;
25°C-də təmiz su pH 7-dir və neytraldır.

Mühəndislər bu metaforu, verilənlər bazalarının əməliyyat etibarlılığını müqayisə etmək üçün götürdülər.
Verilənlər bazası "qələvi"yə ("BASE") nə qədər yaxın olarsa, əməliyyatlar bir o qədər etibarsızdır.

MySQL kimi populyar əlaqəli verilənlər bazaları ACID zəminində meydana çıxdı. Son on ildə bir neçə fərqli növ verilənlər bazalarını birləşdirən NoSQL adlanan verilənlər bazaları meydana çıxdı. Onlar ACID olmadan yaxşı işləyirlər. Bir çox inkişafçılar NoSQL ilə işləyir və əməliyyatlar və onların etibarlılığı haqqında düşünmürlər. Gəlin onların haqlı olub-olmadığını araşdıraq.

NoSQL haqqında ümumi sözlərlə danışmaq olmaz, çünki bu sadəcə uğurlu bir abstraksiyadır. NoSQL verilənlər bazaları məlumat saxlama alt sistemlərinin dizaynı və məlumat modellərinə görə bir-birindən fərqlənir: məsələn, sənəd-əsaslı CouchDB və qraf əsaslı Neo4J. Lakin, əməliyyatlar kontekstində onlar adətən bir aspektdə bir-birlərinə bənzəyirlər: onlar atomarlıq və izolyasiyanın məhdud versiyalarını təklif edirlər, belə ki, ACID təminatları vermirlər. Anlamaq üçün ki, bu nəyə işarə edir, gəlin bu suala cavab tapaq: əgər ACID təqdim etmirlərsə, nə verirlər? Heç nə?

Tam deyil. Onlar özlərini cazibədar bir şəkildə satmalıdırlar. Onlar öz qısaldılmış adlarını icad etdilər - BASE.

6.2 BASE bir antagonist kimi

Burada yenidən hərfi ardıcıllıqla deyil, ilkin termin - consistency ilə davam edirəm. Bu termin ACID konsistensiyası ilə az əlaqəsi var. Problem onun çox sayda kontekstdə istifadə edilməsidir. Lakin, bu konsistensiya daha geniş tətbiqə malikdir və paylanmış sistemlər nəzərdən keçirildikdə müzakirə olunan məsələdir.

Yuxarıda danışdığımız əlaqəli verilənlər bazaları əməliyyatların müxtəlif izolyasiya səviyyələrini təmin edir. Ən ciddi olanlar bir əməliyyatın digər əməliyyat tərəfindən həyata keçirilən etibarsız dəyişiklikləri görməməsini təmin edir.

Məsələn, mağazada kassada dayandığınızı düşünün, və bu anda kommunal ödənişlər üçün hesabınızdan pul çıxarılır, lakin kommunal ödəniş əməliyyatı uğursuz olur və hesabınız əvvəlki vəziyyətinə qayıdır (pul çıxarılmır), sizin kassadakı ödəniş əməliyyatınız bu mürəkkəb dəyişiklikləri görməyəcək. Bu, əməliyyatların izolyasiya tələblərinə əsasən düzgündür, müvəqqəti dəyişikliklər etibarsız əməliyyat tərəfindən həyata keçirilən müvəqqəti dəyişikliklər digər əməliyyatlar tərəfindən görünməzdir.

Çoxlu NoSQL verilənlər bazaları, izolyasiya təminatını tərk edərək, «sonda konsistensiya» (eventual consistency) təklif edir, yəni nəticədə etibarlı məlumat alacaqsınız, lakin əməliyyatınızın etibarsız, müvəqqəti, qismən yenilənmiş və ya köhnəlmiş dəyərləri oxuması ehtimalı var. Məlumatların oxunması zamanı “bu yavaş” rejimdə konsistent ola biləcəklər ("lazily at read time").

NoSQL real vaxt analitikası üçün hazırlanmışdır və daha yüksək sürət əldə etmək üçün, konsistensiyadan fədakarlıq edilmişdir. BASE terminini düşünən Erick Brewer, "CAP teoremi"ni formalaşdırmışdır, bu belədir:

Hər hansı bir paylanmış hesablamanın həyata keçirilməsi üçün aşağıdakı üç xüsusiyyətdən ən çox ikisi təmin edilə bilər:

• məlumatların uyğunluğu (consistency) — fərqli qovşaqlardakı (instances) məlumatlar bir-birinə zidd deyil;
• mövcudluq (availability) — paylanmış sistemə hər hansı bir sorğu doğru cavabla tamamlanır, lakin sistemin bütün qovşaqlarının cavablarının uyğunluğu zəmanət verilmir;
• parçalanmaya/rəzviyata davamlılıq (partition tolerance) — Qovşaqlar arasında əlaqə olmasa belə, onlar müstəqil işləməyə davam edirlər.

Sizə CAP-ın sadə izahı lazımdırsa, burada o var:

CAP teoreminin işləmədiyini və ya kifayət qədər konkret formada olmadığını söyləyənlər var. Amma NoSQL verilənlər bazaları tez-tez CAP teoremi ilə uyğunluğu tərk edirlər. Bu, məlumatların klasterdəki bir neçə nümunədə yeniləndiyini, lakin dəyişikliklərin hələ də bütün nümunələrlə sinxronlaşdırılmadığını ifadə edir. Məsələn, DynamoDB sizə xəbər verə bilər: dəyişiklikləriniz dayanıklı oldu və siz HTTP 200 aldınız, lakin dəyişikliklər yalnız 10 saniyə sonra görünürdü. Gündəlik inkişafçının həyatda başqa bir nümunə - http(s) ünvanlarını IP ünvanlarına çevirən domen adlarının sistemi (DNS) dir.

Yenilənmiş DNS-yaşayış qeyd dəftəri serverlər arasında yaddaş saxlama intervallarının tənzimləmələrinə əsasən yayıldığı üçün yeniləmələr dərhal fərq edilmir. Beləliklə, müvəqqəti qeyri-uyğunluq (sonunda uyğunluğa gətirib çıxara bilən) əlaqəli verilənlər bazası klasterində (məsələn, MySQL-də) baş verə bilər, çünki bu uyğunluq ACID ilə əlaqəli deyil. Buna görə, SQL və NoSQL-in bu mənada əhəmiyyətli dərəcədə fərqlənməyəcəyi ehtimal edilir, klasterdə bir neçə nümunə varsa.

Bundan əlavə, sonda konsistensiya yazı sorğularının qəbul sırası ilə yerinə yetirilməyəcəyi deməkdir: yəni, bütün məlumatlar yazılacaq, lakin nəticədə qəbul edilən dəyər növbədə son qəbul oldan fərqli olacaq.

ACID zəmanətlərini təmin etməyən NoSQL verilənlər bazaları "yumşaq vəziyyət"ə ("soft state") malikdirlər, çünki son nəticədə konsistensiya modeli. Bu o deməkdir ki, sistemin vəziyyəti giriş məlumatları olmadan dəyişə bilər. Bununla belə, bu tip sistemlər daha böyük bir mövcudluğu təmin etməyə çalışırlar, buna "əsasən əlçatanlıq" deyirlər. Bu üç anlayış - "əsasən əlçatanlıq" ("basically available"), "yumşaq vəziyyət" ("soft state") və "sorğunu sonunda uyğunluğa" ("eventual consistency") - BASE qısaltmasını formalaşdırır. Lakin bu, ACID-dən daha çox boş bir marketinq qabığıdır və inkişafçıları çaşdıra bilər. Buna görə izolyasiya anlayışına qayıtmaq daha yaxşıdır.

6.3 Beləliklə, BASE verilənlər bazaları heç ACID kriteriyalarını yerinə yetirmir?

ACID verilənlər bazasını ACID-olmayanlardan fərqləndirən əsas fərq, ACID-olmayanların izolyasiyanı təəccübləndirməməsidir. Bunu başa düşmək vacibdir. Ancaq sənədi oxumaq və onları Hermitage layihəsinin uşaqlarının etdikləri kimi test etmək daha da vacibdir. Müəyyən bir bazanın yaradıcıları öz yaratdıqlarını - ACID və ya BASE, CAP və ya CAP deyil, necə adlandırırsa fərqi yoxdur. Vacib olan təkcə müəyyən bir bazanın nə təmin etdiyidir.

Əgər verilənlər bazasının yaradıcıları onun ACID zəmanətlərini təmin etdiyini iddia edirlərsə, buna inanmaq olar. Amma hər şeyin doğru olub-olmadığını və hansı dərəcədə doğru olduğunu bilmək üçün özünüz sınamalısınız. Əgər onlar zəmanətlərin verilmədiyini elan edirlərsə, bu bir çox şeyi ifadə edə bilər.

• Verilənlər bazası atomarlığı təmin etmir. Lakin bəzi NoSQL verilənlər bazaları atomar əməliyyatlar üçün ayrı API təklif edir (məsələn, DynamoDB).
• Verilənlər bazası izolyasiyanı təmin etmir. Bu, məsələn, məlumatların yazıldığı sıradan fərqli bir sırada yazılmasını ifadə edə bilər.

Müxtəlif verilənlər bazalarını durability zəmanəti ilə müqayisə etmək üçün, hansı məlumat strukturlarının saxlama və məlumat çıxarma üçün istifadə edildiyini bilmək lazımdır. Onlardan bəziləri məlumatları daha sürətli yazmağa imkan verir, digərləri daha sürətli oxumağa imkan verir. Lakin müəyyən məlumat strukturunun durability artırıb azaltığını ümumi şəkildə söyləmək olmaz.

6.4 Fərqli verilənlər bazaları məlumatları necə indeksləşdirir və bu, yalnız durability-yə necə təsir edir

Məlumatları saxlamaq və axtarmaq üçün iki əsas yanaşma var.

Məlumatların saxlanması üçün bütün CRUD əməliyyatlarının jurnallara yazıldığı üçün əməliyyatların faylın sonuna əlavə edilməsi üsulu istifadə olunur. Sürətli axtarış üçün isə indeks - məlumatları saxlayan bir məlumat strukturu istifadə olunur. Sadə indeks olaraq, bir açarı və dəyəri birləşdirən bir hash-cədvəli ola bilər. Dəyərlər diskin üzərində saxlanılan jurnal faylındakı məlumatların sürüşdürmələridir. Bu məlumat strukturu LSM ağacı adlanır və yaddaşda saxlanılır, məlumatlar isə diskdə saxlanılır.

Bəlkə də özünüzə sual verdiniz: əgər əməliyyatları jurnal faylına yazırıqsa, jurnal çox böyüməyəcək? Bəli, buna görə də hər bir açar üçün yalnız ən son dəyəri saxlayan və ya saxlamaq üçün kompresiya (compaction) texnikası inkişaf etdirilmişdir. Əgər diskdə bir neçə jurnal faylı istifadə edəriksə, verilənlər SSTable ("sorted string table") adlanan bir məlumat strukturu yaradarıq ki, bu da məhsuldarlığı artırır. Əgər məlumatları yaddaşda sıralamağa çalışsaq, belə bir MemTable adlanan bir cədvəl alarıq. Lakin daha sonra yazılmış məlumatlar (yəni MemTable-də olan, lakin hələ diskin üzərinə yazılmamış olan məlumatlar) bazanın fəlakətli pozulmasında itəcək. Bu məlumat bazalarına əsaslanan LSM ağaclarının durability ilə problemi budur.

İndeksasiyanın digər yanaşması B-çoxluğun ("B-trees") üzərində qurulmuşdur. B-ağacında məlumatlar sabit ölçülü bloklarda diskin üzərinə yazılır. Bu məlumat blokları təxminən 4 KB ölçüsündədir və açar-dəyər cütlərini açara görə sortlayır. Hər bir B-ağacının düyünü səhifə aralığına olan keçidlərin birləşməsi olan bir massivdir. Massivdəki maksimum keçid sayı branching faktor adlanır. Hər səhifə aralığı bir B-ağacının alt-bölməsi ilə başqa səhifə aralığına keçid edir.

Nəticədə, leaf səviyyəsində tək səhifələri tapacaqsınız. Bu fikir aşağı səviyyəli proqramlaşdırma dillərindəki pointerlərə oxşardır, ancaq bu səhifələrə olan keçidlər yaddaşda deyil, diskdə saxlanılır. INSERT və DELETE baş verdikdə, bəzi düyünlər branching faktorunu vəyerinə yetirmək üçün iki alt ağaca bölünə bilər. Əgər verilənlər bazası hər hansı bir səbəbdən bu prosesin ortasında çökərsə, məlumatların bütövlüyü poza bilər.

Bunu qarşısını almaq üçün, B-ağacları istifadə edən bazalar hər bir əməliyyatı yazan jurnal qabaqlayıcı yazı logu (write-ahead log ya da WAL) saxlayır. Bu WAL B-ağacından biri zədələnsə, vəziyyəti bərpa etmək üçün istifadə olunur. Buna görə də B-ağacları istifadə edən bazaların durability baxımından daha yaxşı olduğunu demək olar. Lakin LSM əsaslı bazalar, WAL kimi eyni funksiyanı istifadə edə bilən bir faylı apara bilərlər. Buna görə seçilən bazanın iş mexanizmlərini diqqətlə öyrənmək lazımdır.

B-ağacları haqqında demək olar ki, onlar əməliyyat üçün uyğundur: hər açar indekste yalnız bir yerdə mövcuddur, jurnal saxlayıcı alt sistemlərində bir açarın fərqli seqmentlərdə bir neçə kopyası ola bilər (məsələn, növbəti həyata keçirilən kompresiyaya qədər).

İndeks dizaynı verilənlər bazasının məhsuldarlığına təsir edir. LSM ağacında diskə yazma ardıcıl baş verir, B-ağaclarında isə bir çox təsadüfi girişlər yaradır. Bu, LSM-də yazmanın B-ağaclarına nisbətən daha sürətli olması deməkdir, xüsusən maqnit disklərdə (HDD). Oxuma isə, LSM ağaclarında daha yavaş yerinə yetirilir, çünki bir çox məlumat strukturu və SS-cədvəlləri araşdırılmalıdır. LSM ilə verilənlər bazasına sadə sorğu zamanı biz əvvəlcə açarı MemTable-də axtarırıq, sonra hər SSTable'ı ardıcıl olaraq yoxlayırıq. Açar yoxdursa, sonuncu olaraq bunu öyrənirik.

LSM ağacları bunlarda istifadə olunur:

• LevelDB
• RocksDB
• Cassandra
• HBase

Bunu belə əhatəli təsvir edirəm ki, verilənlər bazası seçimində nələri nəzərə almanız lazım olduğunu anlamağınız üçün: məsələn, daha çox yazmaq və ya məlumatları oxumaq lazımdır. Ayrıca, məlumat modellərindəki fərqləri (qrafik modeli olduğu kimi məlumatları keçmək lazımdırmı? Müxtəlif məlumat birlikləri arasında hər hansı əlaqələr varmı? Yazı və ya məlumatların oxunuşunda müxtəlif sxemləri istifadə etmək lazımdırmı?) və məlumatların dayanıklığını nəzərdən keçirmək lazımdır. Hər hansı bir məlumat bazası diskin üzərinə yazarsa, yaxşı məlumat dayanıklılığı zəmanəti verə bilər, ancaq hər bir bazanı müstəqil təhlil etmək lazımdır.

6.5 In-memory DB-lər necə işləyir

Məsələn, diskin üzərinə məlumatları yazan bazalardan başqa, yaddaşda saxlanılan bazalar da var, bəzən "in-memory" adlanırlar. Onlar əsasən RAM ilə işləyirlər və daha yüksək yazı və oxu sürətinə qarşı daha aşağı dayanıklılığı təmin edirlər. Bu, cavab vaxtının əhəmiyyət kəsb etdiyi bir çox tətbiq üçün faydalı ola bilər. Məsələn, bu axtarış sorğuları və ya böyük məlumat həcmlərinin sürətli emalını tələb edən analitika üçün istifadə edilə bilər.

Məsələ ondadır ki, RAM uzun bir müddət diskdən daha bahalı olmuşdur, lakin son dövrdə daha ucuzlaşmışdır. Bu, məlumatları RAM-yə sürətlə yazmaq və oxumaq qabiliyyəti ilə yeni növ verilənlər bazalarının yaranmasına gətirib çıxardı. Suallar: Bu bazaların məlumat təminatçılığı necədir? İnkişafçılar təminatçılığı təmin etmək üçün müxtəlif mexanizmlər təklif edirlər.

• Batareyalarla təmin olunan yaddaşı istifadə edin.
• Dəyişiklikləri diskin üzərinə jurnallarda qeyd edin (yuxarıda qeyd olunan WAL kimi), lakin məlumatları deyil.
• Bazanın vəziyyətinin diskin üzərinə nüsxələrini periodik olaraq yazın (ancaq başqa seçimlərdən istifadə etmədən heç bir təminat vermir, sadəcə etibarlılığı artırır);
• Yaddaş vəziyyətini digər maşınlara təkrarlayın.

Məsələn, tez-tez mesaj sırası və ya önbellek kimi istifadə olunan yaddaşda olan Redis verilənlər bazası, ACID-dən uzun müddətli dayanıklılığı təmin etmir: o, uğurlu əmrin diskin üzərinə yazılacağını təmin etmir, çünki Redis məlumatları diskin üzərinə yalnız asinxron olaraq periodik yazır (əgər bu seçilmişdirsə).

Lakin bütün tətbiqlər üçün bu vacib deyil. Məsələn, birlikdə istifadə üçün onlayn redaktor olan EtherPad hər 1-2 saniyədə bir flush edirdi. Bu bir neçə hərf və ya söz itirilməsinə səbəb ola bilərdi, lakin bu çox əhəmiyyətli deyil. Redis verdiyi məlumat modeli ilə önəmlidir, bu modeli disklə həyata keçirmək çətindir. O, həmçinin öz prioritet növbəsi ilə əməliyyatların aparılmasına imkan verir.