Bir tasavvur qilib koʻring-a, siz bir necha oʻnlab, hatto yuzlab odamlar ishtirokida katta tadbir tashkil qilishingiz kerak. Bu, masalan, Amerika boyskaut tashkilotlarining gulxan atrofidagi uchrashuvi boʻlsin va u har yili oʻtkazilsin. Sizga tashkiliy qoʻmita va uni moliyalashtirish uchun qancha mablagʻ kerak boʻladi deb oʻylaysiz? Yaxshiyamki, buning oson yoʻli bor. Zamonaviy texnologiyalar xilma-xil maʼlumotlarning katta hajmini birlashtira oladigan va ulardan dunyoning istalgan nuqtasidan turib qulay foydalanishni taʼminlab beradigan infratuzilma platformalarini yaratishga imkon beradi. Bu moʻjizami? Yoʻq, bu shunchaki ish berayotgan texnologiya xolos. N + 1 Personify.Inc bilan hamkorlikda rivojlanayotgan infratuzilma xizmati – Wild Apricot (ha, amerikalik boyskautlar yigʻilishi uchun ishlab chiqilgan platforma), bunday platformaning yadrosi – maʼlumotlar bazalari va ular bilan ishlash tizimlari haqida suhbat qurdi.
Jadvallar nima uchun kerak?
Zamonaviy (relyatsion) maʼlumotlar bazasining paydo boʻlishi 1970-yilga toʻgʻri keladi. Oʻshanda Edgar Kodd oʻz maqolasida ularning matematik modelini tavsiflaydi. Agar hayotingizda kamida bir marta boʻlsa ham Excel yoki Google Sheetsʼda jadvalni koʻrgan boʻlsangiz, siz bunday modelni tasavvur qila olasiz. Maʼlumotlar bazasidagi har bir yozuv (qator) maʼlum miqdordagi maydonlarga ega (ustunlar soni boʻyicha) boʻlishi kerak.
Shu sababli maʼlumotlar modeli yoki “sxema” (scheme) fizik nusxadan alohida mavjud boʻlishi mumkin. Jadvalingizda nimalar borligini bilgan holda, oldindan kerakli diapazonni tanlash, hozirda kerak boʻladigan maʼlumotlarning “qismini” tartibga solish va keyin uni fizik qurilmadan tez va maqbullashgan holda oʻqish mumkin edi.
Relyatsion maʼlumotlar bazasi uchun SQL tili (strukturali soʻrov tili) de-fakto standartga aylandi. Relyatsion maʼlumotlar bazasi bilan ishlash hozirga qadar talabgor va ularning koʻpchiligi tavsifida SQL qisqartmasi mavjud.
Maʼlumotlar bazasidagi maʼlumotlarni yana qanday qilib tartibga solish mumkin? Agar siz ushbu savolga jiddiy javob olmoqchi boʻlsangiz, relyatsion modeli barcha vazifalar uchun mos kelmasligini bilib olasiz. U har qanday qiymat kiritish uchun yagona modelni taqdim qiladi. Tizim jadval nomini, asosiy kalit qiymatini (qator raqami) va ustun nomini bilishi kerak. Bu barcha kiritiladigan maʼlumotlar mana shu standartga mos boʻlishi kerakligini anglatadi.
Amalda bu barcha maʼlumotlar standart boʻlsa, hech qanday muammo yuzaga kelmasligini anglatadi. Ammo agar maʼlumotlar bazasida birdaniga bir nechta xususiyatlarga ega boʻlgan element paydo boʻlsa, unda butun maʼlumotlar bazasi qayta tashkil qilinishi kerak boʻladi. Aniqlanishicha, relyatsion model bunday vazifalar bilan moslashib ishlashga qodir emas.
Nega aynan Wild Apricot?
Wild Apricot xizmati mijozlarning maʼlumotlar bazasini yaratish va yuritish sohasida mutaxassislarni ish bilan taʼminlaydi. Ular xizmatlarini noldan yaratganlari uchun bunday loyihalarni ishlab chiqish bilan bogʻliq barcha “past-balandliklarni” boshlaridan oʻtkazishgan. Natijada, xizmat turli xil mijozlar uchun mahsulotlar yaratishni yoʻlga qoʻydi. Mijozlarning maʼlumotlar bazasi boʻyicha soʻrovlari baʼzan bir-biridan keskin farq qilardi. Kanadaning “Italiya oʻgʻillari” ordeni, Ontario shtati parklari assotsiatsiyasi, Maho daryosi havzasi ayollarining biznes tarmogʻi va pivoga baho beruvchi Shimoliy Amerika yozuvchilar-kolumnistlar tashkiloti kabi mijozlarning qanday umumiy jihatlari bor deb oʻylaysiz? Faqat bitta narsa – ular tarmoqdagi barcha faoliyatlarini Wild Apricot xizmati mahsulotlari asosida quradi. Shuning uchun biz maʼlumotlar bazasi haqidagi savollarimizni uning ishlab chiquvchilariga berdik.
Maʼlumotlar koʻpaygandan koʻpaymoqda
SQL yaratilishi va faol rivojlanishi davrida saqlanishi kerak boʻlgan maʼlumotlar hajmining kelajakda bunchalik koʻpayib ketishini tasavvur qilish qiyin edi. Shu sababli endi relyatsion maʼlumotlar bazasi doimiy oʻzgaruvchan va tez oʻsib borayotgan loyihalar uchun mos kelmay qolgani ajablanarli emas.
Bunday maʼlumotlar bazasi “vertikal” masshtablash, yaʼni yangi qatorlarni qoʻshish orqali jadvallarning ketma-ket oʻsishi tamoyili boʻyicha ishlaydi. Fizika nuqtai nazaridan vertikal oʻlchov bu – yanada kuchli server, kattaroq disk degani. Ammo maʼlumotlar hajmi petabaytlarga yetganda hatto “juda katta” server ham bunday hajmlarga bardosh bera olmay qoladi. Endi “gorizontal” masshtablash, yaʼni maʼlumotlar bazasini boʻlaklarga boʻlish haqida oʻylashga toʻgʻri keladi.
Gorizontal taqsimot uchun relyatsion model va xususan SQL endi mos kelmaydi. Albatta, siz katta maʼlumotlar bazasini bir marta 10 ta kichikroq maʼlumotlar bazasiga ajratishingiz mumkin. Ammo qachondir ulardagi bosim yana muvozanatni izdan chiqaradi va maʼlumotlarni qayta “joylashtirish”ga toʻgʻri keladi. Endi bizga tanish boʻlgan SQL sintaksisini yanada rivojlangan va oʻsuvchi gorizontal masshtablash modeli bilan birlashtirgan “qoʻshimchalar”ni yozish kerak boʻladi.
Wild Apricot dasturchisining sharhi
Biz bilan ham deyarli shunday boʻldi. Muammo SQLʼda ham emas, maʼlumotlar bazasi sxemasining oʻzida edi. Bazadagi maʼlumotlar bir-biriga ulanib ketgan. Avvalo, bu “Custom” funksiyasida, administratorlar oʻz foydalanuvchilari toʻldirishlari uchun maydonlarni yaratganda sezilarli koʻzga tashlandi. Maydonlarning soni tezda oʻsib, muammoga aylandi.
Xuddi shu tarzda maʼlumotlar sxemasi tufayli “katta” mijozlar uchun alohida maʼlumotlar bazasini shakllantirishning imkoni yoʻq, ularning mavjudligi shuning uchun ham butun xizmat koʻrsatkichlarini pasaytira boshladi.
Yaʼni, MSSQLʼning oʻzi mahsulot sifatida bosimlarga mukammal darajada bardosh beradi va biz uning jismoniy cheklovlariga duch kelmaymiz. Muammo asl maʼlumotlarni saqlash sxemasida edi.
Maʼlumotlar juda koʻp boʻlganda
Xizmat koʻlamli muammoga duch kelganida, hammasi oʻzgaradi. Xususan, apparat va dasturiy taʼminot bilan bogʻliq muammolar yuzaga keladi. Serverlar endi server xonasiga joylashtirilmaydi va alohida hosting hududiga koʻchib oʻtadi. Endi “server maʼlumotlar bazasini saqlaydi” tamoyiliga asoslangan oddiy va ishonchli backend modeli yetarli boʻlmay qoladi.
Toʻplangan maʼlumotlar miqdori bitta serverga joylashtirish uchun juda kattalik qiladi, uni bir nechta tugunlarga (nod) tarqatish kerak boʻladi. Bundan tashqari, maʼlumotlar qanchalik koʻpaysa, bazada oddiy “qidirish / yozish / oʻchirish” operatsiyalarini bajarish shunchalik qiyinlashib boraveradi. Misol tariqasida toʻliq matnli qidiruvni keltirish mumkin. Garchi u SQLʼga asoslangan maʼlumotlar bazasida amalga oshirilgan boʻlsa-da, turli xil soʻrovlar soni sezilarli darajada oʻsa boshlaganda uning funksionalligi yetarli boʻlmasligi mumkin.
Soʻrovlar soni tufayli maʼlumotlar bazasiga kirishning oʻzi “shisha ogʻzi”ga aylanib qoladi va bu muammoni hal qilish uchun alohida xizmat yaratish kerak boʻladi.
Wild Apricot dasturchisining sharhi
Sxema yoʻqligi bilan bir qatorda maʼlumotlarni boʻlaklash tamoyili ham yetishmas ekan. Kontentni saqlash, birinchi navbatda, hajm degani. Bu borada gorizontal yoʻnalishsiz ishlash qiyin. Muhokama davomida biz xilma-xil maʼlumotlar bilan shugʻullanayotganimiz va hujjat-asosli maʼlumotlar bazasini boshqarish tizimi bu muammoni juda yaxshi hal qilishi aniq boʻldi.
Natijada, biz MongoDB dasturi tanlovida toʻxtadik. U nomiga (huMONGOus – ulkan degan soʻzdan olingan) mos tarzda maʼlumotlarni boʻlaklash uchun ajoyib imkoniyatlarni taqdim etadi. Ushbu maʼlumotlar bazasining hujjat-asosli xususiyati oxir-oqibatda murakkab soʻrovlarni qayta ishlashni soddalashtirishga, maʼlumotlarni sharding – bosimni bir nechta serverlar boʻylab tarqatishga imkon berdi.
Taxminan 2009-yilda NoSQL nomi ostiga birlashtirilgan texnologiyalar paydo boʻldi. Nomidan koʻrinib turibdiki, bu tizimlarning yagona umumiy tomoni ularning “oʻzaro aloqasi” va markaziy mexanizm sifatida SQLʼning yoʻqligi. Savolning javobi oʻzi bilan keldi – “Agar jadval boʻlmasa, qanday ishlanadi?”.
Barcha mavjud NoSQL maʼlumotlar bazasini bir vaqtning oʻzida qamrab olish ulkan vazifadir, shuning uchun biz asosiy turlar haqida gapirish bilan cheklanamiz.
NoSQL maʼlumotlar bazasining eng keng guruhi C# kabi dasturlash tilidagi xesh-jadvallarga juda oʻxshash kalit-qiymat modeli (key-value) asosida qurilgan. Har bir obyektga uni (toʻliq) topish mumkin boʻlgan noyob kalit beriladi.
“Qiymat” deganda bir nechta maydonlardan iborat qisqa yozuvdan tortib rasm yoki hatto veb-sahifagacha boʻlgan barcha narsani nazarda tutish mumkin. Ammo munosabatlar modeliga xos boʻlgan ichki sxema (schema) boʻlmasa, murakkab soʻrov bilan barcha obyektlarga “oʻtish” va ularni tezda topish uchun ixcham shaklni yaratish oson boʻlmaydi.
Boshqa NoSQL yondashuvi “ustun” modellardir. Algoritm juda oddiy: agar biz diqqatni satr (qator)dan ustunga oʻtkazsak nima boʻladi? Bunday model har bir yozuvda (qatorda) istagancha maydonlar soniga ega boʻlish imkonini beradi, lekin bitta ustundagi maʼlumotlar jismoniy jihatdan “birgalikda” saqlanadi, shuning uchun keraksiz NULL kabi maydonlar yoʻqoladi va boʻsh joy tejaladi.
Bunday holda qattiq tuzilma va moslashuvchanlik oʻrtasidagi bogʻliqlik avvalgidek aniq boʻlmaydi, lekin tizim samaradorligi nuqtai nazaridan olinsa, uning “narxi” unchalik yuqori ham emas. “Ustun” bazasining afzalligi uning ishlash tezligidadir. Misol uchun, bunday vazifalar muntazam ravishda maʼlum koʻrsatkichlarni hisoblash kerak boʻlgandagina tahliliy ilovalarda qoʻllanadi.
Boshqa ikkita vazifa – asinxron ishlov berish va kengaytirilgan qidiruv xizmati haqida nima deyish mumkin? Hozirda bular uchun ochiq va tijoriy tayyor yechimlar mavjud. Navbatlarni boshqarish tizimiga misol sifatida mijoz va turli xizmatlar oʻrtasidagi “muloqot”ni amalga oshiradigan ActiveMQ dasturini keltirish mumkin. Qidiruv boʻyicha dasturning “ichki Google” loyihasi – ElasticSearch ishlaydi. U hujjatlarni toʻliq matnli qidirishga ixtisoslashgan va ichki tizim boʻylab shardingni amalga oshiradi.
Wild Apricot dasturchisining sharhi
Sharding – bu maʼlumotlar bazasini qisman yoki toʻliq mustaqil boʻlaklarga boʻlish degani. Relyatsion maʼlumotlar bazasi uchun sharding koʻpincha qoʻltiqtayoq sifatida qabul qilinadi. Yuqorida aytib oʻtilganidek, jadvallar qoʻlda boʻlib chiqilishi kerak. Bu esa dasturning foydasini kamaytiradi. Ammo MongoDB kabi maʼlumotlar bazasida sharding ichki maʼlumotlar bazasi miqyosida amalga oshiriladi va qoʻllanadigan maʼlumotlar modeli bilan samarali tarzda birlashtiriladi.
Bulutga koʻchib oʻtish kerakmi?
Tegishli maʼlumotlar bazasi va ularning oʻzaro taʼsirini taʼminlaydigan xizmatlarning muvaffaqiyatli birlashmasi katta hajmdagi maʼlumotlar uchun backend (saqlash) muammolarini hal qilishga imkon beradi. Yoki aslida unday emasmi?
Darhaqiqat, ushbu model turli xil maʼlumotlarga nisbatan masshtablash, tarqatish va moslashuvchanlikni oʻz ichiga oladi, bu esa yangi funksionallikni oson amalga oshirishni anglatadi. Ammo shunda ham toʻliq erkinlik taʼminlanmaydi. Hosting saytlari va fizik serverlar kabi “bogʻlanmalarga” bogʻliqlik mavjudligicha qoladi. Shuning uchun keyingi mantiqiy qadam bu backendning jismoniy tuzilishidan voz kechish va sof texnologiya asosiga oʻtishdir. Biz bulutli xizmatlar haqida gapirmoqdamiz.
“Bulut”ga ham mashinalar kerakligi aniq. Ammo unga oʻtilganda mashinalar kompaniyaning ichki muammosi boʻlmay qoladi. Backendni yigʻish kerak boʻlgan yuz foiz virtual xizmatlar dunyosiga oʻtish kerak va u ishlaydi.
Wild Apricot dasturchisining sharhi
Bulutli xizmatlarga oʻtish orqali biz xizmat tezligini uch baravar oshirdik. Shuningdek, xizmat koʻrsatish uchun serverlarning bosimni koʻtarish tezligini ham oʻn baravarga orttirdik. Bu Wild Apricot versiyalarini toʻrt marta koʻproq yuklashga imkon berdi. Shunday qilib, bizning holatda bulutga koʻchib oʻtish faqatgina ijobiylik olib keldi. Yagona salbiy tomoni – jarayon boshidagi nomaʼlumlikdan nima qilishni bilmaslik edi xolos.
70 yildan kamroq vaqt ichida maʼlumotlar bazasi bilan ishlash perfokartalardan bulut texnologiyalariga qadar yetib keldi va bu oxirgi bekat emasligi aniq. Maʼlumotlar bazasini boshqarish tizimlarini rivojlantirishning soʻnggi bosqichi yaqinda boshlandi va bu sanoatning rivojlanish tezligi hayratlanarli darajada ulkan surʼatlarda ketmoqda.
Jarayon ortidan kuzatish esa undan ham qiziq.
Muallif: Taras Molotilin. Ushbu maqola nplus1.ru saytidagi “Идем на базу. Как современные IT-компании используют мощности БД разных типов” nomli maqolaning tarjimasi.
Muqova surat:freepik.com
