🥇Ko'proq ishlab chiquvchilar buni ma'lumotlar bazalari haqida bilishlari kerak

Eslatma. tarjima.: Jaana Dogan Google kompaniyasining tajribali muhandisi boʻlib, hozirda kompaniyaning Go-da yozilgan ishlab chiqarish xizmatlarini kuzatish ustida ishlamoqda. Ingliz tilida so'zlashuvchi auditoriya orasida katta shuhrat qozongan ushbu maqolada u 17 bandda DBMS (va ba'zan umuman taqsimlangan tizimlar) bo'yicha muhim texnik tafsilotlarni to'pladi, ular katta/talab qilinadigan ilovalarni ishlab chiquvchilar uchun foydalidir.

Kompyuter tizimlarining aksariyati o'z holatini kuzatib boradi va shunga mos ravishda ma'lumotlarni saqlash tizimini talab qiladi. Men uzoq vaqt davomida ma'lumotlar bazalari haqida bilimlarni to'pladim, yo'lda ma'lumotlar yo'qolishi va uzilishlarga olib keladigan dizayn xatolariga yo'l qo'ydim. Katta hajmdagi ma'lumotlarni qayta ishlaydigan tizimlarda ma'lumotlar bazalari tizim arxitekturasining markazida joylashgan va optimal echimni tanlashda asosiy element sifatida ishlaydi. Ma'lumotlar bazasi ishiga jiddiy e'tibor qaratilayotganiga qaramay, dastur ishlab chiquvchilari oldindan ko'rishga harakat qiladigan muammolar ko'pincha aysbergning uchi bo'ladi. Ushbu maqolalar turkumida men ushbu sohada ixtisoslashgan bo'lmagan ishlab chiquvchilar uchun foydali bo'lgan ba'zi fikrlarni baham ko'raman.

Agar 99,999% tarmoq muammo tug'dirmasa, siz omadlisiz.
ACID turli xil narsalarni anglatadi.
Har bir ma'lumotlar bazasida izchillik va izolyatsiyani ta'minlash uchun o'z mexanizmlari mavjud.
Optimistik blokirovka qilish odatiy holni saqlab qolish qiyin bo'lganda yordamga keladi.
Nopok o'qish va ma'lumotlarni yo'qotishdan tashqari boshqa anomaliyalar ham mavjud.
Ma'lumotlar bazasi va foydalanuvchi har doim ham harakat yo'nalishi bo'yicha kelisha olmaydi.
Ilova darajasidagi sharding ilovadan tashqariga ko'chirilishi mumkin.
Avtomatik oshirish xavfli bo'lishi mumkin.
Eskirgan ma'lumotlar foydali bo'lishi mumkin va ularni blokirovka qilish shart emas.
Buzilishlar har qanday vaqt manbalari uchun xosdir.
Kechikish ko'p ma'noga ega.
Muayyan operatsiya uchun ishlash talablari baholanishi kerak.
Ichki tranzaktsiyalar xavfli bo'lishi mumkin.
Tranzaktsiyalar dastur holatiga bog'lanmasligi kerak.
So'rovni rejalashtiruvchilar sizga ma'lumotlar bazalari haqida ko'p narsalarni aytib berishlari mumkin.
Onlayn migratsiya qiyin, ammo mumkin.
Ma'lumotlar bazasining sezilarli o'sishi oldindan aytib bo'lmaydiganlikning oshishiga olib keladi.

Men Emmanuel Odeke, Rein Henrichs va boshqalarga ushbu maqolaning oldingi versiyasi bo'yicha fikr-mulohazalari uchun minnatdorchilik bildirmoqchiman.

Agar 99,999% tarmoq muammo tug'dirmasa, siz omadlisiz.

Zamonaviy tarmoq texnologiyalari qanchalik ishonchli ekanligi va tarmoqdagi nosozliklar tufayli tizimlar qanchalik tez-tez ishlamay qolishi haqida savol qolmoqda. Ushbu masala bo'yicha ma'lumotlar kam va tadqiqotlar ko'pincha ixtisoslashgan tarmoqlar, uskunalar va xodimlarga ega yirik tashkilotlar tomonidan amalga oshiriladi.

Spanner (Googlening global tarqalgan ma'lumotlar bazasi) uchun 99,999% mavjudlik darajasi bilan Google faqat 7,6% muammolar tarmoq bilan bog'liq. Shu bilan birga, kompaniya o'zining ixtisoslashgan tarmog'ini yuqori mavjudlikning "asosiy ustuni" deb ataydi. O'qish Baylis va Kingsberi, 2014 yilda o'tkazilgan, "taqsimlangan hisoblash haqida noto'g'ri tushunchalar", uni Peter Deutsch 1994 yilda shakllantirgan. Tarmoq haqiqatan ham ishonchlimi?

Gigant kompaniyalardan tashqari kengroq Internet uchun o'tkazilgan keng qamrovli tadqiqotlar shunchaki mavjud emas. Shuningdek, asosiy o'yinchilarning mijozlari muammolarining necha foizi tarmoq bilan bog'liqligi haqida etarli ma'lumot yo'q. Biz yirik bulutli provayderlar tarmog‘idagi uzilishlar haqida yaxshi bilamiz, ular Internetning butun qismini bir necha soat davomida o‘chirib tashlashi mumkin, chunki ular juda ko‘p odamlar va kompaniyalarga ta’sir ko‘rsatadigan yuqori darajadagi voqealardir. Tarmoq uzilishlari ko'p hollarda muammolarga olib kelishi mumkin, garchi bu holatlarning hammasi ham diqqat markazida bo'lmasa ham. Bulutli xizmatlarning mijozlari ham muammolarning sabablari haqida hech narsa bilishmaydi. Agar nosozlik bo'lsa, uni xizmat ko'rsatuvchi provayder tomonidagi tarmoq xatosi bilan bog'lash deyarli mumkin emas. Ular uchun uchinchi tomon xizmatlari qora qutilardir. Katta xizmat ko'rsatuvchi provayder bo'lmasdan ta'sirni baholash mumkin emas.

Katta o'yinchilar o'z tizimlari haqida nima hisobot berishini hisobga olsak, agar tarmoqdagi qiyinchiliklar yuzaga kelishi mumkin bo'lgan uzilishlar bilan bog'liq muammolarning ozgina qismini tashkil qilsa, omadingiz borligini aytish xavfsiz. Tarmoq aloqalari hali ham apparatdagi nosozliklar, topologiya o'zgarishlari, ma'muriy konfiguratsiya o'zgarishlari va elektr ta'minotidagi uzilishlar kabi oddiy narsalardan aziyat chekmoqda. Yaqinda mumkin bo'lgan muammolar ro'yxati qo'shilganini bilib hayron bo'ldim akula chaqishi (ha, siz to'g'ri eshitdingiz).

ACID juda ko'p turli xil narsalarni anglatadi

ACID qisqartmasi Atomicity, Consistency, Izolyatsiya, Ishonchlilik degan ma'noni anglatadi. Tranzaktsiyalarning ushbu xususiyatlari nosozliklar, xatolar, apparatlarning nosozliklari va hokazolarda ularning haqiqiyligini ta'minlash uchun mo'ljallangan. ACID yoki shunga o'xshash sxemalarsiz, dastur ishlab chiquvchilari uchun ular nima uchun mas'ul ekanligi va ma'lumotlar bazasi nima uchun javobgar ekanligini farqlash qiyin bo'ladi. Aksariyat relyatsion tranzaksiya ma'lumotlar bazalari ACIDga mos bo'lishga harakat qiladi, ammo NoSQL kabi yangi yondashuvlar ACID tranzaksiyalarisiz ko'plab ma'lumotlar bazalarini keltirib chiqardi, chunki ularni amalga oshirish qimmat.

Men sanoatga birinchi marta kirganimda, texnik rahbarimiz ACID kontseptsiyasi qanchalik dolzarbligi haqida gapirdi. Adolat uchun, ACID qat'iy amalga oshirish standarti emas, balki qo'pol tavsif deb hisoblanadi. Bugun men uni asosan foydali deb bilaman, chunki u muayyan toifadagi muammolarni ko'taradi (va bir qator mumkin bo'lgan echimlarni taklif qiladi).

Har bir DBMS ACIDga mos kelmaydi; Shu bilan birga, ACID-ni qo'llab-quvvatlaydigan ma'lumotlar bazasi ilovalari talablar to'plamini boshqacha tushunadi. ACIDni qo'llashning noto'g'ri bo'lishining sabablaridan biri ACID talablarini amalga oshirish uchun amalga oshirilishi kerak bo'lgan ko'plab kelishuvlar bilan bog'liq. Ijodkorlar o'zlarining ma'lumotlar bazalarini ACID-mos keluvchi sifatida taqdim etishlari mumkin, ammo chekka holatlarning talqini, "ehtimol bo'lmagan" hodisalarni boshqarish mexanizmi kabi keskin farq qilishi mumkin. Hech bo'lmaganda, ishlab chiquvchilar o'zlarining maxsus xatti-harakatlari va dizayn kelishuvlarini to'g'ri tushunish uchun asosiy ilovalarning nozik tomonlarini yuqori darajada tushunishlari mumkin.

MongoDB ACID talablariga mos keladimi-yo'qmi haqidagi munozaralar 4-versiya chiqqandan keyin ham davom etmoqda. MongoDB uzoq vaqt davomida qo'llab-quvvatlanmaydi ro'yxatga olish, garchi sukut bo'yicha ma'lumotlar har 60 soniyada bir martadan ko'p bo'lmagan diskka solingan bo'lsa ham. Quyidagi stsenariyni tasavvur qiling: dastur ikkita yozishni (w1 va w2) joylashtiradi. MongoDB w1-ni muvaffaqiyatli saqlaydi, lekin apparatdagi nosozlik tufayli w2 yo'qoladi.

Stsenariyni tasvirlaydigan diagramma. MongoDB diskka ma'lumotlarni yozishdan oldin ishdan chiqadi

Disk bilan ishlash qimmat jarayondir. Tez-tez bajariladigan majburiyatlardan qochib, ishlab chiquvchilar ishonchlilik hisobiga yozib olish samaradorligini yaxshilaydi. MongoDB hozirda jurnalga yozishni qo'llab-quvvatlaydi, ammo iflos yozishlar hali ham ma'lumotlar yaxlitligiga ta'sir qilishi mumkin, chunki jurnallar sukut bo'yicha har 100 ms dan olinadi. Ya'ni, shunga o'xshash stsenariy loglar va ulardagi o'zgarishlar uchun hali ham mumkin, garchi xavf ancha past bo'lsa.

Har bir ma'lumotlar bazasi o'ziga xos mustahkamlik va izolyatsiya mexanizmlariga ega

ACID talablaridan izchillik va izolyatsiya eng ko'p turli xil ilovalar bilan maqtanadi, chunki o'zaro ta'sir doirasi kengroqdir. Aytish kerakki, mustahkamlik va izolyatsiya juda qimmat funktsiyalardir. Ular muvofiqlashtirishni talab qiladi va ma'lumotlar izchilligi uchun raqobatni kuchaytiradi. Ma'lumotlar bazasini bir nechta ma'lumotlar markazlarida (ayniqsa, ular turli geografik mintaqalarda joylashgan bo'lsa) gorizontal ravishda masshtablash zarur bo'lganda muammoning murakkabligi sezilarli darajada oshadi. Yuqori darajadagi izchillikka erishish juda qiyin, chunki u ham mavjudlikni kamaytiradi va tarmoq segmentatsiyasini oshiradi. Ushbu hodisani yanada umumiy tushuntirish uchun men sizga murojaat qilishingizni maslahat beraman CAP teoremasi. Shuni ham ta'kidlash joizki, ilovalar kichik hajmdagi nomuvofiqliklarni bartaraf etishi mumkin va dasturchilar muammoning nozik tomonlarini yetarlicha tushuna oladilar va dasturda nomuvofiqlikni boshqarish uchun ma'lumotlar bazasiga katta tayanmasdan, qo'shimcha mantiqni amalga oshirishlari mumkin.

DBMS ko'pincha turli darajadagi izolyatsiyani ta'minlaydi. Ilova ishlab chiquvchilari o'z xohishlariga ko'ra eng samaralisini tanlashlari mumkin. Kam izolyatsiya tezlikni oshirishga imkon beradi, ammo ma'lumotlar poygasi xavfini oshiradi. Yuqori izolyatsiya bu ehtimollikni kamaytiradi, lekin ishni sekinlashtiradi va raqobatga olib kelishi mumkin, bu esa muvaffaqiyatsizliklar boshlanadigan bazada bunday tormozlarga olib keladi.

Mavjud parallellik modellari va ular o'rtasidagi munosabatlarni ko'rib chiqish

SQL standarti faqat to'rtta izolyatsiya darajasini belgilaydi, garchi nazariy va amaliyotda yana ko'p narsalar mavjud. Jepson.io mavjud parallel modellarning ajoyib ko'rinishini taqdim etadi. Masalan, Google Spanner soat sinxronizatsiyasi bilan tashqi ketma-ketlikni kafolatlaydi va bu qattiqroq izolyatsiya qatlami bo'lsa-da, standart izolyatsiya qatlamlarida aniqlanmagan.

SQL standarti quyidagi izolyatsiya darajalarini eslatib o'tadi:

Serializatsiyalanadigan (eng qat'iy va qimmat): Serializatsiya qilinadigan bajarish ba'zi ketma-ket operatsiyalarni bajarish bilan bir xil ta'sirga ega. Ketma-ket bajarilish deganda, har bir keyingi tranzaksiya avvalgisi tugagandan keyingina boshlanishini bildiradi. Shuni ta'kidlash kerakki, daraja Serializatsiyalanadigan ko'pincha talqindagi farqlar tufayli oniy tasvir izolyatsiyasi deb ataladigan (masalan, Oracle'da) amalga oshiriladi, garchi oniy tasvirni izolyatsiyasining o'zi SQL standartida taqdim etilmagan.
Takroriy o'qishlar: Joriy tranzaksiyadagi tasdiqlanmagan yozuvlar joriy tranzaksiya uchun mavjud, ammo boshqa tranzaktsiyalar tomonidan kiritilgan o'zgarishlar (masalan, yangi qatorlar) ko'rinmaydi.
O'qildi: O'tkazilmagan ma'lumotlar tranzaktsiyalar uchun mavjud emas. Bunday holda, tranzaktsiyalar faqat tuzilgan ma'lumotlarni ko'rishi mumkin va fantom o'qishlar paydo bo'lishi mumkin. Agar tranzaksiya yangi qatorlarni qo'shsa va bajarsa, joriy tranzaksiya so'ralganda ularni ko'rishi mumkin bo'ladi.
Qattiq o'qing (eng kam qat'iy va qimmat daraja): iflos o'qishga ruxsat beriladi, tranzaktsiyalar boshqa tranzaktsiyalar tomonidan amalga oshirilmagan o'zgarishlarni ko'rishi mumkin. Amalda, bu daraja so'rovlar kabi taxminiy hisob-kitoblar uchun foydali bo'lishi mumkin COUNT(*) stol ustida.

daraja Serializatsiyalanadigan ma'lumotlar poygalari xavfini minimallashtiradi, shu bilan birga amalga oshirish eng qimmat va tizimdagi eng yuqori raqobatbardosh yukni keltirib chiqaradi. Boshqa izolyatsiya darajalarini amalga oshirish osonroq, ammo ma'lumotlar poygalari ehtimolini oshiradi. Ba'zi DBMSlar sizga maxsus izolyatsiya darajasini o'rnatishga imkon beradi, boshqalari kuchli afzalliklarga ega va barcha darajalar qo'llab-quvvatlanmaydi.

Izolyatsiya darajasini qo'llab-quvvatlash ko'pincha ma'lum bir DBMSda e'lon qilinadi, lekin faqat uning xatti-harakatlarini sinchkovlik bilan o'rganish aslida nima sodir bo'layotganini ko'rsatishi mumkin.

Turli DBMSlar uchun turli izolyatsiya darajalarida parallellik anomaliyalarini ko'rib chiqish

Martin Kleppmann o'z loyihasida ermitaj Turli xil izolyatsiya darajalarini taqqoslaydi, parallellik anomaliyalari haqida gapiradi va ma'lumotlar bazasi ma'lum bir izolyatsiya darajasiga rioya qila oladimi yoki yo'qmi. Kleppmanning tadqiqoti ma'lumotlar bazasini ishlab chiquvchilarning izolyatsiya darajalari haqida qanday fikrda ekanligini ko'rsatadi.

Optimistik blokirovka qilish odatiy holni saqlab qolish qiyin bo'lganda yordamga keladi.

Bloklash juda qimmatga tushishi mumkin, chunki bu nafaqat ma'lumotlar bazasida raqobatni kuchaytiradi, balki dastur serverlaridan doimiy ravishda ma'lumotlar bazasiga ulanishni talab qiladi. Tarmoq segmentatsiyasi eksklyuziv qulflash holatlarini kuchaytirishi va aniqlash va hal qilish qiyin bo'lgan boshi berk ko'chaga olib kelishi mumkin. Eksklyuziv qulflash mos bo'lmagan hollarda, optimistik qulflash yordam beradi.

Optimistik qulf satrni o'qiyotganda uning versiyasini, nazorat summasini yoki oxirgi o'zgartirish vaqtini hisobga oladigan usul. Bu yozuvni o'zgartirishdan oldin atom versiyasi o'zgarmasligiga ishonch hosil qilish imkonini beradi:

UPDATE products
SET name = 'Telegraph receiver', version = 2
WHERE id = 1 AND version = 1

Bunday holda, jadvalni yangilash products Agar ilgari ushbu qatorga boshqa operatsiya o'zgartirilgan bo'lsa, amalga oshirilmaydi. Agar ushbu qatorda boshqa operatsiyalar bajarilmagan bo'lsa, bitta satr uchun o'zgarish sodir bo'ladi va biz yangilanish muvaffaqiyatli bo'ldi deb ayta olamiz.

Nopok o'qish va ma'lumotlarni yo'qotishdan tashqari boshqa anomaliyalar ham mavjud

Ma'lumotlarning izchilligi haqida gap ketganda, asosiy e'tibor iflos o'qish va ma'lumotlarning yo'qolishiga olib kelishi mumkin bo'lgan poyga sharoitlariga qaratiladi. Biroq, ma'lumotlar anomaliyalari shu bilan tugamaydi.

Bunday anomaliyalarning bir misoli yozuv buzilishidir (qiyshiqlarni yozish). Buzilishlarni aniqlash qiyin, chunki ular odatda faol ravishda qidirilmaydi. Ular iflos o'qish yoki ma'lumotlarning yo'qolishi tufayli emas, balki ma'lumotlarga qo'yilgan mantiqiy cheklovlarning buzilishi bilan bog'liq.

Misol uchun, bitta operatorning har doim qo'ng'iroq bo'lishini talab qiladigan monitoring dasturini ko'rib chiqaylik:

BEGIN tx1;                      BEGIN tx2;
SELECT COUNT(*)
FROM operators
WHERE oncall = true;
0                               SELECT COUNT(*)
                                FROM operators
                                WHERE oncall = TRUE;
                                0
UPDATE operators                UPDATE operators
SET oncall = TRUE               SET oncall = TRUE
WHERE userId = 4;               WHERE userId = 2;
COMMIT tx1;                     COMMIT tx2;

Yuqoridagi vaziyatda, agar ikkala operatsiya ham muvaffaqiyatli amalga oshirilsa, rekord korruptsiya sodir bo'ladi. Hech qanday iflos o'qishlar yoki ma'lumotlar yo'qolmasa-da, ma'lumotlarning yaxlitligi buzilgan: endi bir vaqtning o'zida ikki kishi qo'ng'iroqda hisoblanadi.

Serializatsiya qilinadigan izolyatsiya, sxema dizayni yoki ma'lumotlar bazasi cheklovlari yozish buzilishini bartaraf etishga yordam beradi. Ishlab chiquvchilar ishlab chiqarishda ularni oldini olish uchun rivojlanish jarayonida bunday anomaliyalarni aniqlay olishlari kerak. Shu bilan birga, yozib olish buzilishlarini kod bazasida izlash juda qiyin. Ayniqsa, katta tizimlarda, turli xil ishlab chiqish guruhlari bir xil jadvallar asosida funktsiyalarni amalga oshirish uchun javobgar bo'lgan va ma'lumotlarga kirishning o'ziga xos xususiyatlari bo'yicha kelishmasa.

Ma'lumotlar bazasi va foydalanuvchi nima qilish kerakligi haqida har doim ham kelisha olmaydi

Ma'lumotlar bazalarining asosiy xususiyatlaridan biri - bu bajarilish tartibining kafolati, ammo bu tartibning o'zi dasturiy ta'minot ishlab chiqaruvchisi uchun shaffof bo'lmasligi mumkin. Ma'lumotlar bazalari tranzaktsiyalarni dasturchilar nazarda tutgan tartibda emas, balki qabul qilingan tartibda amalga oshiradi. Tranzaktsiyalar tartibini oldindan aytish qiyin, ayniqsa yuqori yuklangan parallel tizimlarda.

Rivojlanish jarayonida, ayniqsa bloklanmaydigan kutubxonalar bilan ishlashda, yomon uslub va past o'qilishi foydalanuvchilarning tranzaktsiyalar ketma-ket bajarilganligiga ishonishiga olib kelishi mumkin, aslida ular ma'lumotlar bazasiga istalgan tartibda kirishlari mumkin.

Bir qarashda, quyidagi dasturda T1 va T2 ketma-ket chaqiriladi, ammo agar bu funktsiyalar bloklanmagan bo'lsa va natijani darhol shaklda qaytaradi. va'da berish, keyin qo'ng'iroqlar tartibi ma'lumotlar bazasiga kirgan paytlari bilan belgilanadi:

result1 = T1() // haqiqiy natijalar va'dalardir
natija2 = T2()

Agar atomiklik zarur bo'lsa (ya'ni, barcha operatsiyalar bajarilishi yoki bekor qilinishi kerak) va ketma-ketlik muhim bo'lsa, u holda T1 va T2 operatsiyalari bitta operatsiya doirasida bajarilishi kerak.

Ilova darajasidagi sharding ilovadan tashqariga ko'chirilishi mumkin

Sharding - bu ma'lumotlar bazasini gorizontal qismlarga ajratish usuli. Ba'zi ma'lumotlar bazalari ma'lumotlarni avtomatik ravishda gorizontal ravishda ajratishi mumkin, boshqalari esa buni qila olmaydi yoki unchalik yaxshi emas. Ma'lumotlar arxitektorlari/ishlab chiquvchilari ma'lumotlarga qanday kirishni aniq taxmin qilish imkoniga ega bo'lganda, ular ushbu ishni ma'lumotlar bazasiga topshirish o'rniga foydalanuvchi maydonida gorizontal bo'limlarni yaratishi mumkin. Bu jarayon "ilova darajasidagi sharding" deb ataladi. (ilova darajasidagi parchalanish).

Afsuski, bu nom ko'pincha dastur xizmatlarida sharding yashaydi degan noto'g'ri fikrni keltirib chiqaradi. Aslida, u ma'lumotlar bazasi oldida alohida qatlam sifatida amalga oshirilishi mumkin. Ma'lumotlarning o'sishi va sxema takrorlanishiga qarab, sharding talablari juda murakkab bo'lishi mumkin. Ba'zi strategiyalar dastur serverlarini qayta joylashtirmasdan takrorlash qobiliyatidan foydalanishi mumkin.

Ilova serverlari sharding xizmatidan ajratilgan arxitekturaga misol

Shardingni alohida xizmatga koʻchirish ilovalarni qayta joylashtirishni talab qilmasdan turli xil sharding strategiyalaridan foydalanish imkoniyatini kengaytiradi. Vitess dastur darajasida bunday sharding tizimiga misol bo'ladi. Vitess MySQL uchun gorizontal parchalanishni ta'minlaydi va mijozlarga MySQL protokoli orqali ulanish imkonini beradi. Tizim ma'lumotlarni bir-biri haqida hech narsa bilmaydigan turli MySQL tugunlariga ajratadi.

Avtomatik oshirish xavfli bo'lishi mumkin

AUTOINCREMENT - asosiy kalitlarni yaratishning keng tarqalgan usuli. Ko'pincha ma'lumotlar bazalari ID generatorlari sifatida foydalaniladi va ma'lumotlar bazasida identifikatorlarni yaratish uchun mo'ljallangan jadvallar mavjud. Avtomatik oshirish yordamida asosiy kalitlarni yaratish idealdan uzoq bo'lishining bir qancha sabablari bor:

Tarqalgan ma'lumotlar bazasida avtomatik oshirish jiddiy muammo hisoblanadi. ID yaratish uchun global qulf talab qilinadi. Buning o'rniga siz UUID yaratishingiz mumkin: bu turli xil ma'lumotlar bazasi tugunlari o'rtasidagi o'zaro ta'sirni talab qilmaydi. Qulflar bilan avtomatik oshirish tortishuvlarga olib kelishi va taqsimlangan holatlarda qo'shimchalarning ishlashini sezilarli darajada kamaytirishi mumkin. Ba'zi DBMSlar (masalan, MySQL) master-master replikatsiyasini to'g'ri tashkil qilish uchun maxsus konfiguratsiya va ko'proq e'tibor talab qilishi mumkin. Va sozlashda xatolarga yo'l qo'yish oson, bu esa ro'yxatga olishda muvaffaqiyatsizlikka olib keladi.
Ba'zi ma'lumotlar bazalarida asosiy kalitlarga asoslangan qismlarga ajratish algoritmlari mavjud. Ketma-ket identifikatorlar oldindan aytib bo'lmaydigan issiq nuqtalarga va ba'zi bo'limlarda yukning oshishiga olib kelishi mumkin, boshqalari esa ishlamay qoladi.
Asosiy kalit ma'lumotlar bazasidagi qatorga kirishning eng tezkor usuli hisoblanadi. Yozuvlarni aniqlashning yaxshiroq usullari bilan ketma-ket identifikatorlar jadvallardagi eng muhim ustunni ma'nosiz qiymatlar bilan to'ldirilgan foydasiz ustunga aylantirishi mumkin. Shuning uchun, iloji boricha, global noyob va tabiiy asosiy kalitni tanlang (masalan, foydalanuvchi nomi).

Yondashuv haqida qaror qabul qilishdan oldin, identifikatorlar va UUIDlarni avtomatik ravishda oshirishning indekslash, bo'linish va parchalanishga ta'sirini ko'rib chiqing.

Eskirgan ma'lumotlar foydali bo'lishi mumkin va qulflashni talab qilmaydi

Multiversion Concurrency Control (MVCC) yuqorida qisqacha muhokama qilingan ko'plab izchillik talablarini amalga oshiradi. Ba'zi ma'lumotlar bazalari (masalan, Postgres, Spanner) MVCC-dan ma'lumotlar bazasining eski versiyalari bilan tranzaktsiyalarni "ta'minlash" uchun foydalanadi. Muvofiqlikni ta'minlash uchun suratga olingan tranzaktsiyalarni ketma-ketlashtirish ham mumkin. Eski suratdan o'qiyotganda, eskirgan ma'lumotlar o'qiladi.

Bir oz eskirgan ma'lumotlarni o'qish, masalan, ma'lumotlardan tahlillarni yaratishda yoki taxminiy jami qiymatlarni hisoblashda foydali bo'lishi mumkin.

Eski ma'lumotlar bilan ishlashning birinchi afzalligi past kechikishdir (ayniqsa, ma'lumotlar bazasi turli geografiyalarda taqsimlangan bo'lsa). Ikkinchisi, faqat o'qish uchun mo'ljallangan tranzaktsiyalar blokirovkasizdir. Bu ko'p o'qiydigan ilovalar uchun muhim afzallik, chunki ular eskirgan ma'lumotlarni qayta ishlashga qodir.

Ilova serveri Tinch okeanining narigi tomonida so'nggi versiya mavjud bo'lsa ham, mahalliy nusxadan 5 soniya eskirgan ma'lumotlarni o'qiydi.

DBMS eski versiyalarni avtomatik ravishda tozalaydi va ba'zi hollarda buni so'rov bo'yicha bajarishga imkon beradi. Masalan, Postgres foydalanuvchilarga buni amalga oshirishga imkon beradi VACUUM so'rov bo'yicha, shuningdek vaqti-vaqti bilan ushbu operatsiyani avtomatik ravishda amalga oshiradi. Spanner bir soatdan eski suratlardan xalos bo'lish uchun axlat yig'uvchini boshqaradi.

Har qanday vaqt manbalari buzilishlarga duchor bo'ladi

Kompyuter fanida eng yaxshi saqlanadigan sir shundaki, barcha vaqt API-lari yolg'on. Aslida, bizning mashinalarimiz hozirgi vaqtni aniq bilishmaydi. Kompyuterlarda vaqtni ushlab turish uchun ishlatiladigan tebranishlarni hosil qiluvchi kvarts kristallari mavjud. Biroq, ular etarlicha aniq emas va aniq vaqtdan oldinda/orqada bo'lishi mumkin. Shift kuniga 20 soniyaga yetishi mumkin. Shuning uchun bizning kompyuterimizdagi vaqt vaqti-vaqti bilan tarmoq bilan sinxronlashtirilishi kerak.

Sinxronizatsiya uchun NTP serverlari ishlatiladi, lekin sinxronizatsiya jarayonining o'zi tarmoq kechikishlariga bog'liq. Hatto bitta ma'lumot markazida NTP serveri bilan sinxronlash biroz vaqt talab etadi. Ommaviy NTP serveri bilan ishlash yanada katta buzilishlarga olib kelishi aniq.

Atom soatlari va ularning GPS hamkasblari joriy vaqtni aniqlash uchun yaxshiroqdir, lekin ular qimmat va murakkab sozlashni talab qiladi, shuning uchun ularni har bir mashinaga o'rnatib bo'lmaydi. Shu sababli, ma'lumotlar markazlari bosqichli yondashuvdan foydalanadilar. Atom va/yoki GPS soatlari aniq vaqtni ko'rsatadi, shundan so'ng u ikkinchi darajali serverlar orqali boshqa mashinalarga uzatiladi. Bu shuni anglatadiki, har bir mashina aniq vaqtdan ma'lum bir ofsetni boshdan kechiradi.

Vaziyat ilovalar va ma'lumotlar bazalari ko'pincha turli xil mashinalarda (agar turli ma'lumotlar markazlarida bo'lmasa) joylashganligi bilan og'irlashadi. Shunday qilib, vaqt nafaqat turli xil mashinalarda taqsimlangan JB tugunlarida farq qiladi. Ilova serverida ham u boshqacha bo'ladi.

Google TrueTime butunlay boshqacha yondashuvni qo'llaydi. Ko'pchilik Google'ning bu yo'nalishdagi taraqqiyoti atom va GPS soatlariga oddiy o'tish bilan izohlanadi, deb hisoblashadi, ammo bu katta rasmning faqat bir qismi. TrueTime qanday ishlaydi:

TrueTime ikki xil manbadan foydalanadi: GPS va atom soatlari. Bu soatlar korrelyatsiya qilinmagan nosozlik rejimlariga ega. [batafsil ma'lumot uchun 5-betga qarang shu yerda - taxminan. tarjima.), shuning uchun ularning birgalikda foydalanish ishonchliligini oshiradi.
TrueTime-da noodatiy API mavjud. U vaqtni o'lchov xatosi va unga o'rnatilgan noaniqlik bilan interval sifatida qaytaradi. Vaqtning haqiqiy momenti intervalning yuqori va pastki chegaralari orasida joylashgan. Spanner, Google-ning tarqatilgan ma'lumotlar bazasi, hozirgi vaqt diapazondan tashqarida ekanligini aytish xavfsiz bo'lguncha kutadi. Ushbu usul tizimga biroz kechikishni kiritadi, ayniqsa magistrlarda noaniqlik yuqori bo'lsa, lekin hatto global miqyosda taqsimlangan vaziyatda ham to'g'rilikni ta'minlaydi.

Spanner komponentlari TrueTime-dan foydalanadi, bu erda TT.now() intervalni qaytaradi, shuning uchun Spanner joriy vaqt ma'lum bir nuqtadan o'tganiga ishonch hosil bo'lguncha uxlaydi.

Joriy vaqtni aniqlashda pasaytirilgan aniqlik, Spanner operatsiyalari davomiyligini oshirish va ishlashning pasayishini anglatadi. Shu sababli, to'liq aniq soatni olishning iloji bo'lmasa ham, eng yuqori aniqlikni saqlab qolish muhimdir.

Kechikish ko'p ma'noga ega

Agar siz o'nlab mutaxassislardan kechikish nima ekanligini so'rasangiz, ehtimol siz turli xil javoblarni olasiz. DBMSda kechikish ko'pincha "ma'lumotlar bazasi kechikishi" deb ataladi va mijoz tomonidan qabul qilinganidan farq qiladi. Gap shundaki, mijoz tarmoq kechikishi va ma'lumotlar bazasi kechikishining yig'indisini kuzatadi. O'sib borayotgan muammolarni bartaraf etishda kechikish turini ajratish qobiliyati juda muhimdir. Ko'rsatkichlarni yig'ish va ko'rsatishda har doim ikkala turga ham e'tibor berishga harakat qiling.

Muayyan operatsiya uchun ishlash talablari baholanishi kerak

Ba'zan DBMS ning ishlash ko'rsatkichlari va uning cheklovlari yozish/o'qish qobiliyati va kechikish nuqtai nazaridan belgilanadi. Bu tizimning asosiy parametrlari haqida umumiy ma'lumot beradi, ammo yangi ma'lumotlar bazasi tizimini baholashda muhim operatsiyalarni (har bir so'rov va/yoki tranzaksiya uchun) alohida baholash juda keng qamrovli yondashuv hisoblanadi. Misollar:

X jadvaliga (50 million qatorli) yangi qator qo'shganda o'tkazuvchanlik va kechikish vaqtini belgilangan cheklovlar va tegishli jadvallarda qator to'ldirish bilan yozing.
Do'stlarning o'rtacha soni 500 ta bo'lsa, ma'lum bir foydalanuvchining do'stlarining do'stlarini ko'rsatishda kechikish.
Foydalanuvchi soatiga X yozuvlari bilan 100 ta boshqa foydalanuvchini kuzatib borayotganida, foydalanuvchi tarixidan eng yaxshi 500 ta yozuvni olishda kechikish.

Baholash va tajriba ma'lumotlar bazasi ishlash talablariga javob berishiga ishonchingiz komil bo'lmaguningizcha, bunday muhim holatlarni o'z ichiga olishi mumkin. Shunga o'xshash qoida, kechikish ko'rsatkichlarini yig'ishda va SLOlarni aniqlashda ham ushbu taqsimotni hisobga oladi.

Har bir operatsiya uchun o'lchovlarni yig'ishda yuqori kardinallikdan xabardor bo'ling. Yuqori quvvatli nosozliklarni tuzatish ma'lumotlarini olish uchun jurnallar, hodisalar to'plami yoki taqsimlangan kuzatuvdan foydalaning. Maqolada "Kechikishni tuzatishni xohlaysizmi?» kechikishlarni tuzatish metodologiyalari bilan tanishishingiz mumkin.

Ichki tranzaktsiyalar xavfli bo'lishi mumkin

Har bir DBMS ichki o'rnatilgan tranzaktsiyalarni qo'llab-quvvatlamaydi, lekin ular amalga oshirilganda, bunday tranzaktsiyalar kutilmagan xatolarga olib kelishi mumkin, ularni aniqlash har doim ham oson bo'lmaydi (ya'ni, qandaydir anomaliya mavjudligi aniq bo'lishi kerak).

Siz ularni aniqlay oladigan va chetlab o'tadigan mijozlar kutubxonalari yordamida ichki o'rnatilgan tranzaktsiyalardan foydalanishdan qochishingiz mumkin. Agar ichki o'rnatilgan tranzaktsiyalardan voz kechishning iloji bo'lmasa, ularni amalga oshirishga alohida e'tibor bering, kutilmagan vaziyatlarning oldini olish uchun yakunlangan tranzaktsiyalar ichki o'rnatilganlar tufayli tasodifan to'xtatiladi.

Turli qatlamlardagi tranzaktsiyalarni inkapsulyatsiya qilish kutilmagan ichki o'tkazmalarga olib kelishi mumkin va kodni o'qish nuqtai nazaridan muallifning niyatlarini tushunishni qiyinlashtirishi mumkin. Quyidagi dasturni ko'rib chiqing:

with newTransaction():
   Accounts.create("609-543-222")
   with newTransaction():
       Accounts.create("775-988-322")
       throw Rollback();

Yuqoridagi kodning chiqishi qanday bo'ladi? U ikkala tranzaktsiyani yoki faqat ichki operatsiyani qaytaradimi? Agar biz tranzaktsiyalarni yaratishni qamrab oladigan bir nechta kutubxona qatlamlariga tayansak nima bo'ladi? Bunday holatlarni aniqlab, takomillashtirishga erisha olamizmi?

Bir nechta operatsiyalarga ega ma'lumotlar qatlamini tasavvur qiling (masalan, newAccount) allaqachon o'z operatsiyalarida amalga oshirilgan. Agar siz ularni o'z tranzaktsiyasi doirasida ishlaydigan yuqori darajadagi biznes mantig'ining bir qismi sifatida ishlatsangiz nima bo'ladi? Bu holatda izolyatsiya va izchillik qanday bo'ladi?

function newAccount(id string) {
  with newTransaction():
      Accounts.create(id)
}

Bunday cheksiz savollarga javob izlash o'rniga, ichki operatsiyalardan qochish yaxshiroqdir. Axir, sizning ma'lumotlar qatlamingiz o'z tranzaktsiyalarini yaratmasdan yuqori darajadagi operatsiyalarni osongina bajarishi mumkin. Bundan tashqari, biznes mantig'ining o'zi tranzaktsiyani boshlash, u bo'yicha operatsiyalarni bajarish, bitimni amalga oshirish yoki bekor qilish qobiliyatiga ega.

function newAccount(id string) {
   Accounts.create(id)
}
// In main application:
with newTransaction():
   // Read some data from database for configuration.
   // Generate an ID from the ID service.
   Accounts.create(id)
   Uploads.create(id) // create upload queue for the user.

Tranzaktsiyalar dastur holatiga bog'lanmasligi kerak

Ba'zida ma'lum qiymatlarni o'zgartirish yoki so'rov parametrlarini o'zgartirish uchun tranzaktsiyalarda dastur holatidan foydalanish vasvasasi paydo bo'ladi. Ko'rib chiqilishi kerak bo'lgan muhim nuance - to'g'ri dastur doirasi. Mijozlar ko'pincha tarmoq muammolari mavjud bo'lganda tranzaktsiyalarni qayta boshlashadi. Agar tranzaktsiya boshqa jarayon tomonidan o'zgartirilayotgan holatga bog'liq bo'lsa, u ma'lumotlar poygasi ehtimoliga qarab noto'g'ri qiymatni tanlashi mumkin. Tranzaktsiyalar ilovada ma'lumotlar poygasi shartlari xavfini hisobga olishi kerak.

var seq int64
with newTransaction():
    newSeq := atomic.Increment(&seq)
    Entries.query(newSeq)
    // Other operations...

Yuqoridagi tranzaksiya yakuniy natijadan qat'i nazar, har safar bajarilganda tartib raqamini oshiradi. Tarmoq muammolari tufayli topshiriq bajarilmasa, qayta urinib ko'rganingizda so'rov boshqa tartib raqami bilan bajariladi.

So'rovni rejalashtiruvchilar sizga ma'lumotlar bazasi haqida ko'p narsalarni aytib berishlari mumkin

So'rovni rejalashtiruvchilar ma'lumotlar bazasida so'rov qanday bajarilishini aniqlaydi. Shuningdek, ular so'rovlarni tahlil qiladi va ularni yuborishdan oldin ularni optimallashtiradi. Rejalashtiruvchilar faqat o'z ixtiyoridagi signallarga asoslangan ba'zi mumkin bo'lgan taxminlarni taqdim etishlari mumkin. Misol uchun, quyidagi so'rov uchun eng yaxshi qidiruv usuli qaysi?

SELECT * FROM articles where author = "rakyll" order by title;

Natijalarni ikki yo'l bilan olish mumkin:

Jadvalni to'liq skanerlash: Jadvaldagi har bir yozuvni ko'rib chiqishingiz va mos keladigan muallif nomi bilan maqolalarni qaytarishingiz va keyin ularga buyurtma berishingiz mumkin.
Indeks skanerlash: Mos identifikatorlarni topish, ushbu qatorlarni olish va keyin ularni buyurtma qilish uchun indeksdan foydalanishingiz mumkin.

So'rovni rejalashtiruvchining vazifasi qaysi strategiya eng yaxshi ekanligini aniqlashdir. So'rovni rejalashtiruvchilar faqat cheklangan bashorat qilish imkoniyatlariga ega ekanligini hisobga olish kerak. Bu noto'g'ri qarorlarga olib kelishi mumkin. DBA yoki ishlab chiquvchilar ulardan noto'g'ri bajarilgan so'rovlarni tashxislash va sozlash uchun foydalanishlari mumkin. Ma'lumotlar bazasining yangi versiyalari so'rovlarni rejalashtiruvchilarni sozlashi mumkin va agar yangi versiya ishlash muammolariga olib keladigan bo'lsa, o'z-o'zini diagnostika ma'lumotlar bazasini yangilashda yordam beradi. Sekin so'rovlar jurnallari, kechikish muammosi hisobotlari yoki bajarish vaqti statistikasi optimallashtirishga muhtoj bo'lgan so'rovlarni aniqlashga yordam beradi.

So'rovni rejalashtiruvchi tomonidan taqdim etilgan ba'zi ko'rsatkichlar shovqinga duchor bo'lishi mumkin (ayniqsa, kechikish yoki protsessor vaqtini baholashda). Rejalashtiruvchilarga yaxshi qo'shimcha - bu ijro yo'lini kuzatish va kuzatish uchun vositalar. Ular sizga bunday muammolarni tashxislash imkonini beradi (afsuski, barcha DBMSlar bunday vositalarni taqdim etmaydi).

Onlayn migratsiya qiyin, ammo mumkin

Onlayn migratsiya, jonli migratsiya yoki real vaqtda migratsiya bir ma'lumotlar bazasidan ikkinchisiga to'xtab qolmasdan yoki ma'lumotlarning buzilishisiz o'tishni anglatadi. Agar o'tish bir xil DBMS/dvigatel ichida sodir bo'lsa, jonli migratsiyani amalga oshirish osonroq. Turli xil ishlash va sxema talablari bilan yangi ma'lumotlar bazasiga o'tish zarur bo'lganda, vaziyat yanada murakkablashadi.

Turli xil onlayn migratsiya modellari mavjud. Mana ulardan biri:

Ikkala ma'lumotlar bazasida ikki marta kirishni yoqing. Ushbu bosqichdagi yangi ma'lumotlar bazasi barcha ma'lumotlarga ega emas, faqat oxirgi ma'lumotlarni qabul qiladi. Bunga ishonchingiz komil bo'lsa, keyingi bosqichga o'tishingiz mumkin.
Ikkala ma'lumotlar bazasidan o'qishni yoqing.
Tizimni o'qish va yozish birinchi navbatda yangi ma'lumotlar bazasida bajarilishi uchun sozlang.
Eski ma'lumotlar bazasiga yozishni to'xtatib, undan ma'lumotlarni o'qishni davom ettiring. Ushbu bosqichda yangi ma'lumotlar bazasi hali ham ba'zi ma'lumotlardan mahrum. Ular eski ma'lumotlar bazasidan ko'chirilishi kerak.
Eski ma'lumotlar bazasi faqat o'qish uchun mo'ljallangan. Eski ma'lumotlar bazasidan etishmayotgan ma'lumotlarni yangisiga nusxalash. Migratsiya tugallangandan so'ng, yo'llarni yangi ma'lumotlar bazasiga o'tkazing va eskisini to'xtatib, uni tizimdan o'chiring.

Qo'shimcha ma'lumot uchun men bog'lanishni maslahat beraman maqola, bu modelga asoslangan Stripe migratsiya strategiyasini batafsil bayon qiladi.

Ma'lumotlar bazasining sezilarli o'sishi oldindan aytib bo'lmaydiganlikning oshishiga olib keladi

Ma'lumotlar bazasining o'sishi uning miqyosi bilan bog'liq oldindan aytib bo'lmaydigan muammolarga olib keladi. Biz ma'lumotlar bazasining ichki tuzilishi haqida qanchalik ko'p bilsak, uning qanday miqyosda bo'lishini taxmin qilishimiz mumkin. Biroq, ba'zi daqiqalarni oldindan aytib bo'lmaydi.
Baza o'sishi bilan ma'lumotlar hajmi va tarmoq o'tkazish qobiliyatiga bo'lgan talablar bo'yicha oldingi taxminlar va taxminlar eskirib qolishi mumkin. Mumkin bo'lgan muammolarni oldini olish uchun dizaynni tubdan ta'mirlash, keng ko'lamli operatsion takomillashtirish, joylashtirishni qayta ko'rib chiqish yoki boshqa ma'lumotlar bazasiga o'tish haqida savol tug'iladi.

Ammo mavjud ma'lumotlar bazasining ichki tuzilishini mukammal bilish zarur bo'lgan yagona narsa deb o'ylamang. Yangi tarozilar o'zlari bilan yangi noma'lum narsalarni olib keladi. Kutilmagan og'riqli nuqtalar, ma'lumotlarning notekis taqsimlanishi, kutilmagan tarmoqli kengligi va apparat muammolari, tobora ortib borayotgan trafik va yangi tarmoq segmentlari sizni ma'lumotlar bazasi yondashuvini, ma'lumotlar modelini, joylashtirish modelini va ma'lumotlar bazasi hajmini qayta ko'rib chiqishga majbur qiladi.

...

Men ushbu maqolani nashr etish haqida o'ylashni boshlaganimda, mening asl ro'yxatimda yana beshta narsa bor edi. Keyin juda katta raqam paydo bo'ldi yangi g'oyalar yana nimani qamrab olishi mumkinligi haqida. Shuning uchun, maqola maksimal e'tibor talab qiladigan eng kam aniq muammolarga to'xtalib o'tadi. Biroq, bu mavzu tugaydi degani emas va men kelajakdagi materiallarimda unga qaytmayman va hozirgi mavzuga o'zgartirish kiritmayman.

PS

Shuningdek, bizning blogimizda o'qing:

Manba: www.habr.com

Ko'proq ishlab chiquvchilar buni ma'lumotlar bazalari haqida bilishlari kerak