Hammaga salom! Mening ismim Golov Nikolay. Ilgari men Avito’da ishlaganman va olti yil davomida Data Platform’ni boshqarganman, ya’ni barcha ma’lumotlar bazalarida ishlaganman: analitik (Vertica, ClickHouse), oqim va OLTP (Redis, Tarantool, VoltDB, MongoDB, PostgreSQL). Shu vaqt ichida men juda ko'p sonli ma'lumotlar bazalari bilan shug'ullandim - juda boshqacha va g'ayrioddiy va ulardan foydalanishning nostandart holatlari bilan.
Men hozir ManyChatda ishlayapman. Aslini olganda, bu startap - yangi, ambitsiyali va tez rivojlanayotgan. Va men kompaniyaga birinchi marta qo'shilganimda, klassik savol tug'ildi: "Yosh startap endi ma'lumotlar bazasi va ma'lumotlar bazasi bozoridan nimani olishi kerak?"
Ushbu maqolada mening hisobotimga asoslanib , Men bu savolga javob beraman. Hisobotning video versiyasini quyidagi manzilda olishingiz mumkin .
Ma'lum bo'lgan ma'lumotlar bazalari 2020
2020 yil, men atrofga qaradim va uch turdagi ma'lumotlar bazalarini ko'rdim.
Birinchi tur - klassik OLTP ma'lumotlar bazalari: PostgreSQL, SQL Server, Oracle, MySQL. Ular uzoq vaqt oldin yozilgan, ammo hali ham dolzarbdir, chunki ular ishlab chiquvchilar hamjamiyatiga juda yaxshi tanish.
Ikkinchi tur "nol" dan asoslar. Ular SQL, an'anaviy tuzilmalar va ACIDdan voz kechib, o'rnatilgan sharding va boshqa jozibali xususiyatlarni qo'shib, klassik naqshlardan uzoqlashishga harakat qilishdi. Masalan, bu Cassandra, MongoDB, Redis yoki Tarantool. Ushbu echimlarning barchasi bozorga tubdan yangi narsani taklif qilishni xohladi va o'z o'rnini egalladi, chunki ular ma'lum vazifalar uchun juda qulay bo'lib chiqdi. Men ushbu ma'lumotlar bazalarini NOSQL atamasi bilan belgilayman.
"Nollar" tugadi, biz NOSQL ma'lumotlar bazalariga o'rganib qoldik va dunyo, mening nuqtai nazarimdan, keyingi qadamni qo'ydi - boshqariladigan ma'lumotlar bazalari. Ushbu ma'lumotlar bazalari klassik OLTP ma'lumotlar bazalari yoki yangi NoSQL ma'lumotlar bazalari bilan bir xil yadroga ega. Ammo ular DBA va DevOps-ga ehtiyoj sezmaydilar va bulutlarda boshqariladigan uskunada ishlaydi. Ishlab chiquvchi uchun bu bir joyda ishlaydigan "shunchaki tayanch" dir, lekin uning serverga qanday o'rnatilgani, serverni kim sozlagani va uni kim yangilashi hech kimga ahamiyat bermaydi.
Bunday ma'lumotlar bazalariga misollar:
- AWS RDS - bu PostgreSQL/MySQL uchun boshqariladigan o'ram.
- DynamoDB - bu Redis va MongoDB kabi hujjatlarga asoslangan ma'lumotlar bazasining AWS analogidir.
- Amazon Redshift - bu boshqariladigan analitik ma'lumotlar bazasi.
Bular asosan eski ma'lumotlar bazalari bo'lib, lekin boshqariladigan muhitda, apparat bilan ishlashga hojat yo'q.
Eslatma. Misollar AWS muhiti uchun olingan, ammo ularning analoglari Microsoft Azure, Google Cloud yoki Yandex.Cloud-da ham mavjud.
Bu haqda nima yangiliklar bor? 2020 yilda bularning hech biri.
Serversiz tushuncha
2020-yilda bozorda haqiqatan ham yangilik serversiz yoki serversiz yechimlardir.
Bu nimani anglatishini oddiy xizmat yoki backend ilovasi misolida tushuntirishga harakat qilaman.
Muntazam backend ilovasini oʻrnatish uchun biz server sotib olamiz yoki ijaraga olamiz, unga kodni koʻchirib olamiz, oxirgi nuqtani tashqarida eʼlon qilamiz va ijara, elektr energiyasi va maʼlumotlar markazi xizmatlari uchun muntazam ravishda toʻlov qilamiz. Bu standart sxema.
Boshqa yo'l bormi? Serversiz xizmatlar bilan mumkin.
Ushbu yondashuvning asosiy maqsadi: server yo'q, bulutda virtual nusxani ijaraga olish ham yo'q. Xizmatni o'rnatish uchun kodni (funktsiyalarni) omborga ko'chiring va uni oxirgi nuqtaga e'lon qiling. Keyin biz ushbu funktsiyaga har bir qo'ng'iroq uchun to'lovni amalga oshiramiz, u bajarilgan uskunani butunlay e'tiborsiz qoldiramiz.
Men bu yondashuvni rasmlar bilan ko'rsatishga harakat qilaman.
Klassik joylashtirish. Bizda ma'lum bir yuk bilan xizmat mavjud. Biz ikkita misolni ko'taramiz: jismoniy serverlar yoki AWSdagi misollar. Tashqi so'rovlar ushbu instansiyalarga yuboriladi va u erda qayta ishlanadi.
Rasmda ko'rib turganingizdek, serverlar teng ravishda tashlanmagan. Bittasi 100% foydalanilgan, ikkita soʻrov bor, biri esa atigi 50% – qisman boʻsh. Agar uchta emas, balki 30 ta so'rov kelsa, unda butun tizim yukni bardosh bera olmaydi va sekinlasha boshlaydi.
Serversiz joylashtirish. Serversiz muhitda bunday xizmatda misollar yoki serverlar mavjud emas. Isitilgan resurslarning ma'lum bir hovuzi mavjud - o'rnatilgan funktsiya kodi bilan tayyorlangan kichik Docker konteynerlari. Tizim tashqi so'rovlarni qabul qiladi va ularning har biri uchun serversiz ramka kodli kichik konteynerni ko'taradi: u ushbu maxsus so'rovni qayta ishlaydi va konteynerni o'ldiradi.
Bitta so'rov - bitta konteyner ko'tarildi, 1000 ta so'rov - 1000 konteyner. Va apparat serverlarida joylashtirish allaqachon bulutli provayderning ishi. U butunlay serversiz ramka tomonidan yashiringan. Ushbu kontseptsiyada biz har bir qo'ng'iroq uchun to'laymiz. Masalan, bir kunda bitta qo‘ng‘iroq bo‘ldi – bitta qo‘ng‘iroq uchun pul to‘ladik, daqiqasiga million keldi – millionni to‘ladik. Yoki bir soniya ichida bu ham sodir bo'ladi.
Serversiz funksiyani nashr qilish kontseptsiyasi fuqaroligi bo'lmagan xizmat uchun mos keladi. Va agar sizga (davlat) davlat xizmati kerak bo'lsa, biz xizmatga ma'lumotlar bazasini qo'shamiz. Bu holatda, davlat bilan ishlash haqida gap ketganda, har bir davlat funksiyasi shunchaki ma'lumotlar bazasidan yozadi va o'qiydi. Bundan tashqari, maqolaning boshida tasvirlangan uchta turdagi har qanday ma'lumotlar bazasidan.
Ushbu ma'lumotlar bazalarining umumiy cheklovi nimada? Bu doimiy foydalaniladigan bulut yoki apparat serveri (yoki bir nechta serverlar) xarajatlari. Klassik yoki boshqariladigan ma'lumotlar bazasidan foydalanishimiz muhim emas, bizda Devops va administrator bormi yoki yo'qmi, biz har doim ham apparat, elektr energiyasi va ma'lumotlar markazi ijarasi uchun 24/7 to'laymiz. Agar biz klassik bazaga ega bo'lsak, biz xo'jayin va qul uchun to'laymiz. Agar bu juda yuklangan shard ma'lumotlar bazasi bo'lsa, biz 10, 20 yoki 30 serverlar uchun to'laymiz va biz doimiy ravishda to'laymiz.
Xarajatlar tuzilmasida doimiy zahiradagi serverlarning mavjudligi avval zaruriy yovuzlik sifatida qabul qilingan. An'anaviy ma'lumotlar bazalarida, shuningdek, ulanishlar soni bo'yicha cheklovlar, masshtablash cheklovlari, geo-tarqatilgan konsensus kabi boshqa qiyinchiliklar mavjud - ular qandaydir tarzda ma'lum ma'lumotlar bazalarida hal qilinishi mumkin, lekin barchasi bir vaqtning o'zida emas va ideal emas.
Serversiz ma'lumotlar bazasi - nazariya
2020 yil savoli: ma'lumotlar bazasini ham serversiz qilish mumkinmi? Serversiz backend haqida hamma eshitgan... keling, ma'lumotlar bazasini serversiz qilishga harakat qilaylikmi?
Bu g'alati tuyuladi, chunki ma'lumotlar bazasi davlat to'liq xizmat bo'lib, serversiz infratuzilma uchun unchalik mos kelmaydi. Shu bilan birga, ma'lumotlar bazasining holati juda katta: gigabaytlar, terabaytlar va analitik ma'lumotlar bazalarida hatto petabaytlar. Uni engil Docker konteynerlarida ko'tarish unchalik oson emas.
Boshqa tomondan, deyarli barcha zamonaviy ma'lumotlar bazalari juda katta miqdordagi mantiq va komponentlarni o'z ichiga oladi: tranzaktsiyalar, yaxlitlikni muvofiqlashtirish, protseduralar, aloqador bog'liqliklar va juda ko'p mantiq. Ko'p ma'lumotlar bazasi mantig'i uchun kichik holat etarli. Gigabaytlar va terabaytlar to'g'ridan-to'g'ri so'rovlarni to'g'ridan-to'g'ri bajarishda ishtirok etadigan ma'lumotlar bazasi mantig'ining faqat kichik bir qismi tomonidan bevosita foydalaniladi.
Shunga ko'ra, g'oya quyidagilardan iborat: agar mantiqning bir qismi fuqaroliksiz ijro etishga imkon bersa, nega bazani Davlat va fuqaroligi bo'lmagan qismlarga bo'lish kerak emas.
OLAP yechimlari uchun serversiz
Keling, amaliy misollar yordamida ma'lumotlar bazasini Davlat va fuqaroligi bo'lmagan qismlarga ajratish qanday ko'rinishini ko'rib chiqaylik.
Misol uchun, bizda analitik ma'lumotlar bazasi mavjud: tashqi ma'lumotlar (chapdagi qizil silindr), ma'lumotlar bazasiga ma'lumotlarni yuklaydigan ETL jarayoni va ma'lumotlar bazasiga SQL so'rovlarini yuboradigan tahlilchi. Bu ma'lumotlar omborining klassik ishlash sxemasi.
Bu sxemada ETL shartli ravishda bir marta bajariladi. Keyin ma'lumotlar bazasi ETL bilan to'ldirilgan ma'lumotlar bilan ishlaydigan serverlar uchun doimiy ravishda to'lashingiz kerak, shunda so'rovlarni yuborish uchun biror narsa mavjud.
Keling, AWS Athena Serverless-da amalga oshirilgan muqobil yondashuvni ko'rib chiqaylik. Yuklab olingan ma'lumotlar saqlanadigan doimiy maxsus uskuna yo'q. Buning o'rniga:
- Foydalanuvchi Athena-ga SQL so'rovini yuboradi. Athena optimallashtiruvchisi SQL so'rovini tahlil qiladi va so'rovni bajarish uchun zarur bo'lgan aniq ma'lumotlarni metadata do'konida (Metadata) qidiradi.
- Optimallashtiruvchi to'plangan ma'lumotlarga asoslanib, zarur ma'lumotlarni tashqi manbalardan vaqtinchalik saqlashga (vaqtinchalik ma'lumotlar bazasiga) yuklaydi.
- Foydalanuvchining SQL so'rovi vaqtinchalik saqlashda bajariladi va natija foydalanuvchiga qaytariladi.
- Vaqtinchalik saqlash joyi tozalanadi va resurslar chiqariladi.
Ushbu arxitekturada biz faqat so'rovni bajarish jarayoni uchun to'laymiz. Hech qanday so'rov yo'q - xarajatlar yo'q.
Bu ishchi yondashuv bo'lib, nafaqat Athena Serverless, balki Redshift Spectrum (AWSda)da ham qo'llaniladi.
Athena misoli shuni ko'rsatadiki, Serversiz ma'lumotlar bazasi o'nlab va yuzlab terabayt ma'lumotlarga ega haqiqiy so'rovlar ustida ishlaydi. Yuzlab terabaytlar uchun yuzlab serverlar kerak bo'ladi, lekin biz ular uchun pul to'lashimiz shart emas - biz so'rovlar uchun to'laymiz. Har bir soʻrovning tezligi Vertica kabi ixtisoslashtirilgan analitik maʼlumotlar bazalariga nisbatan (juda) past, lekin biz toʻxtab qolgan vaqtlar uchun toʻlamaymiz.
Bunday ma'lumotlar bazasi nodir tahliliy maxsus so'rovlar uchun qo'llaniladi. Masalan, biz o'z-o'zidan gipotezani ba'zi bir ulkan ma'lumotlarga sinab ko'rishga qaror qilganimizda. Afina bu holatlar uchun juda mos keladi. Muntazam so'rovlar uchun bunday tizim qimmat. Bunday holda, ma'lumotlarni biron bir maxsus yechimda keshlang.
OLTP yechimlari uchun serversiz
Oldingi misol OLAP (analitik) vazifalarini ko'rib chiqdi. Endi OLTP vazifalarini ko'rib chiqamiz.
Keling, kengaytiriladigan PostgreSQL yoki MySQL-ni tasavvur qilaylik. Minimal resurslar bilan oddiy boshqariladigan PostgreSQL yoki MySQL misolini yarataylik. Misol ko'proq yuklanganda, biz o'qish yukining bir qismini taqsimlaydigan qo'shimcha replikalarni ulaymiz. Hech qanday so'rov yoki yuk bo'lmasa, biz replikalarni o'chirib qo'yamiz. Birinchi instantsiya usta, qolganlari esa replikadir.
Ushbu g'oya Aurora Serverless AWS deb nomlangan ma'lumotlar bazasida amalga oshiriladi. Printsip oddiy: tashqi ilovalardan so'rovlar proksi-serverlar parki tomonidan qabul qilinadi. Yuk ko'tarilishini ko'rib, u oldindan qizdirilgan minimal misollardan hisoblash resurslarini ajratadi - ulanish imkon qadar tezroq amalga oshiriladi. Misollarni o'chirish xuddi shu tarzda sodir bo'ladi.
Aurora ichida Aurora Capacity Unit, ACU tushunchasi mavjud. Bu (shartli) misol (server). Har bir aniq ACU master yoki qul bo'lishi mumkin. Har bir sig'im birligi o'z RAM, protsessor va minimal diskka ega. Shunga ko'ra, biri usta, qolganlari faqat o'qiladigan nusxalar.
Ishlayotgan ushbu Aurora sig'im birliklarining soni sozlanishi mumkin bo'lgan parametrdir. Minimal miqdor bitta yoki nolga teng bo'lishi mumkin (bu holda, so'rovlar bo'lmasa, ma'lumotlar bazasi ishlamaydi).
Baza so'rovlarni qabul qilganda, proksi-serverlar parki Aurora CapacityUnits ni oshiradi va tizimning ishlash resurslarini oshiradi. Resurslarni ko'paytirish va kamaytirish qobiliyati tizimga resurslarni "jungle qilish" imkonini beradi: avtomatik ravishda individual ACU-larni ko'rsatish (ularni yangilari bilan almashtirish) va olib qo'yilgan resurslarga barcha joriy yangilanishlarni tarqatish.
Aurora Serversiz bazasi o'qish yukini ko'paytirishi mumkin. Ammo hujjatlar bu haqda to'g'ridan-to'g'ri aytmaydi. Ular multi-masterni ko'tara oladigandek tuyulishi mumkin. Hech qanday sehr yo'q.
Ushbu ma'lumotlar bazasi oldindan aytib bo'lmaydigan kirish imkoniyatiga ega bo'lgan tizimlarga katta miqdorda pul sarflamaslik uchun juda mos keladi. Misol uchun, MVP yoki marketing biznes kartalari saytlarini yaratishda biz odatda barqaror yukni kutmaymiz. Shunga ko'ra, agar kirish imkoni bo'lmasa, biz misollar uchun to'lamaymiz. Kutilmagan yuk paydo bo'lganda, masalan, konferentsiya yoki reklama kampaniyasidan so'ng, saytga ko'plab odamlar tashrif buyurishadi va yuk keskin oshadi, Aurora Serverless bu yukni avtomatik ravishda oladi va etishmayotgan resurslarni (ACU) tezda bog'laydi. Keyin konferentsiya o'tadi, hamma prototipni unutadi, serverlar (ACU) qorong'ilashadi va xarajatlar nolga tushadi - qulay.
Ushbu yechim barqaror yuklash uchun mos emas, chunki u yozish yukini o'lchamaydi. Bu barcha ulanishlar va resurslarning uzilishi "masshtab nuqtasi" deb ataladigan nuqtada - ma'lumotlar bazasi tranzaksiya yoki vaqtinchalik jadvallar tomonidan qo'llab-quvvatlanmaydigan vaqt nuqtasida sodir bo'ladi. Misol uchun, bir hafta ichida o'lchov nuqtasi sodir bo'lmasligi mumkin va baza bir xil resurslarda ishlaydi va shunchaki kengaytira olmaydi yoki qisqara olmaydi.
Hech qanday sehr yo'q - bu oddiy PostgreSQL. Ammo mashinalarni qo'shish va ularni o'chirish jarayoni qisman avtomatlashtirilgan.
Dizayni bo'yicha serversiz
Aurora Serverless - bu Serversizning ba'zi afzalliklaridan foydalanish uchun bulut uchun qayta yozilgan eski ma'lumotlar bazasi. Va endi men sizga serversiz yondashuv uchun dastlab bulut uchun yozilgan baza haqida gapirib beraman - serversiz dizayn. U darhol jismoniy serverlarda ishlaydi degan taxminsiz ishlab chiqilgan.
Ushbu asos Snowflake deb ataladi. Unda uchta asosiy blok mavjud.
Birinchisi, metadata blokidir. Bu xavfsizlik, metadata, tranzaktsiyalar va so'rovlarni optimallashtirish bilan bog'liq muammolarni hal qiladigan tezkor xotira xizmati (chapdagi rasmda ko'rsatilgan).
Ikkinchi blok - hisob-kitoblar uchun virtual hisoblash klasterlari to'plami (rasmda ko'k doiralar to'plami mavjud).
Uchinchi blok - S3 asosidagi ma'lumotlarni saqlash tizimi. S3 - bu biznes uchun o'lchamsiz Dropbox kabi AWS-da o'lchamsiz ob'ektlarni saqlash.
Keling, Snowflake qanday ishlashini ko'rib chiqaylik, agar sovuq boshlangan bo'lsa. Ya'ni, ma'lumotlar bazasi mavjud, unga ma'lumotlar yuklanadi, ishlaydigan so'rovlar yo'q. Shunga ko'ra, agar ma'lumotlar bazasiga so'rovlar bo'lmasa, biz tezkor xotiradagi Metadata xizmatini (birinchi blok) ko'tardik. Va bizda S3 xotirasi bor, u erda jadval ma'lumotlari saqlanadi, ular mikro bo'limlarga bo'linadi. Oddiylik uchun: agar jadvalda tranzaktsiyalar mavjud bo'lsa, u holda mikro-bo'limlar tranzaktsiyalar kunlari hisoblanadi. Har kuni alohida mikro bo'lim, alohida fayl. Va ma'lumotlar bazasi ushbu rejimda ishlaganda, siz faqat ma'lumotlar egallagan joy uchun to'laysiz. Bundan tashqari, har bir o'rindiq uchun stavka juda past (ayniqsa, sezilarli siqishni hisobga olgan holda). Metama'lumotlar xizmati ham doimiy ishlaydi, lekin so'rovlarni optimallashtirish uchun sizga ko'p resurslar kerak emas va xizmatni umumiy dastur deb hisoblash mumkin.
Keling, foydalanuvchi ma'lumotlar bazasiga kelib, SQL so'rovini yuborganini tasavvur qilaylik. SQL so'rovi qayta ishlash uchun darhol Metadata xizmatiga yuboriladi. Shunga ko'ra, so'rovni olgandan so'ng, ushbu xizmat so'rovni, mavjud ma'lumotlarni, foydalanuvchi ruxsatlarini tahlil qiladi va agar hammasi yaxshi bo'lsa, so'rovni qayta ishlash rejasini tuzadi.
Keyinchalik, xizmat hisoblash klasterini ishga tushirishni boshlaydi. Hisoblash klasteri - bu hisob-kitoblarni amalga oshiradigan serverlar klasteridir. Ya'ni, bu 1 ta server, 2 ta server, 4, 8, 16, 32 - xohlaganingizcha bo'lishi mumkin bo'lgan klaster. Siz so'rov yuborasiz va ushbu klasterni ishga tushirish darhol boshlanadi. Bu haqiqatan ham soniyalarni oladi.
Keyin, klaster ishga tushirilgandan so'ng, so'rovingizni qayta ishlash uchun zarur bo'lgan mikro-bo'limlar S3 dan klasterga ko'chirila boshlaydi. Ya'ni, SQL so'rovini bajarish uchun bitta jadvaldan ikkita bo'lim va ikkinchidan bitta bo'lim kerak, deb tasavvur qilaylik. Bunday holda, barcha jadvallar to'liq emas, balki klasterga faqat uchta kerakli bo'lim ko'chiriladi. Aynan shuning uchun va hamma narsa bitta ma'lumot markazida joylashganligi va juda tez kanallar bilan bog'langanligi sababli, butun uzatish jarayoni juda tez sodir bo'ladi: soniyalarda, juda kamdan-kam hollarda daqiqalarda, ba'zi dahshatli so'rovlar haqida gapirmasak. Shunga ko'ra, mikro-bo'limlar hisoblash klasteriga ko'chiriladi va tugallangandan so'ng SQL so'rovi ushbu hisoblash klasterida bajariladi. Ushbu so'rovning natijasi bitta satr, bir nechta satr yoki jadval bo'lishi mumkin - ular foydalanuvchiga uni yuklab olishi, BI vositasida ko'rsatishi yoki boshqa yo'l bilan foydalanishi uchun tashqaridan yuboriladi.
Har bir SQL so'rovi nafaqat avval yuklangan ma'lumotlardan agregatlarni o'qiy oladi, balki ma'lumotlar bazasida yangi ma'lumotlarni yuklaydi/yaratadi. Ya'ni, bu, masalan, boshqa jadvalga yangi yozuvlarni qo'shadigan so'rov bo'lishi mumkin, bu esa hisoblash klasterida yangi bo'limning paydo bo'lishiga olib keladi, bu esa o'z navbatida bitta S3 xotirasida avtomatik ravishda saqlanadi.
Yuqorida tavsiflangan stsenariy foydalanuvchining kelishidan boshlab klasterni ko'tarish, ma'lumotlarni yuklash, so'rovlarni bajarish, natijalarni olish uchun ko'tarilgan virtual hisoblash klasteridan, virtual ombordan foydalanganlik daqiqalari uchun to'lanadi. Narx AWS zonasi va klaster hajmiga qarab o'zgaradi, lekin o'rtacha soatiga bir necha dollarni tashkil qiladi. To'rtta mashinadan iborat klaster ikki mashinadan iborat klasterdan ikki baravar qimmat, sakkizta klaster esa hali ham ikki baravar qimmat. So'rovlarning murakkabligiga qarab 16, 32 ta mashinaning variantlari mavjud. Ammo siz klaster amalda ishlayotgan daqiqalar uchun to'laysiz, chunki hech qanday so'rovlar bo'lmasa, siz qo'llaringizni olib qo'yasiz va 5-10 daqiqa kutishdan keyin (sozlanishi mumkin bo'lgan parametr) u o'z-o'zidan o'chadi, resurslarni bo'shatib, ozod bo'ling.
To'liq real stsenariy shundan iboratki, siz so'rov yuborganingizda, klaster ochiladi, nisbatan aytganda, bir daqiqada u yana bir daqiqani hisoblaydi, keyin o'chirish uchun besh daqiqa ketadi va siz ushbu klasterning etti daqiqa ishlashi uchun to'laysiz va oylar va yillar davomida emas.
Birinchi stsenariy Snowflake-dan bitta foydalanuvchi sozlamalari yordamida tasvirlangan. Keling, haqiqiy stsenariyga yaqinroq bo'lgan ko'plab foydalanuvchilar borligini tasavvur qilaylik.
Aytaylik, bizda ko'plab tahlilchilar va Tableau hisobotlari mavjud bo'lib, ular doimiy ravishda bizning ma'lumotlar bazamizni juda ko'p sonli oddiy analitik SQL so'rovlari bilan bombardimon qilishadi.
Bundan tashqari, aytaylik, bizda ma'lumotlar bilan dahshatli narsalarni qilishga harakat qiladigan, o'nlab terabaytlar bilan ishlaydigan, milliardlab va trillionlab ma'lumotlar qatorlarini tahlil qiladigan ixtirochi Data Scientists bor.
Yuqorida tavsiflangan ikki turdagi ish yuki uchun Snowflake sizga turli sig'imdagi bir nechta mustaqil hisoblash klasterlarini yaratishga imkon beradi. Bundan tashqari, ushbu hisoblash klasterlari mustaqil ishlaydi, lekin umumiy izchil ma'lumotlar bilan.
Ko'p sonli yorug'lik so'rovlari uchun siz har birida taxminan 2 ta mashinadan iborat 3-2 ta kichik klasterni ko'tarishingiz mumkin. Ushbu xatti-harakat, boshqa narsalar qatori, avtomatik sozlamalar yordamida amalga oshirilishi mumkin. Shunday qilib, siz shunday deysiz: “Qor parchasi, kichik klasterni ko'taring. Agar undagi yuk ma'lum bir parametrdan oshsa, shunga o'xshash ikkinchi, uchinchi darajani ko'taring. Yuk pasayishni boshlaganda, ortiqcha narsani o'chiring." Shunday qilib, qancha tahlilchilar kelib, hisobotlarni ko'rishni boshlamasin, hamma uchun etarli resurslar mavjud.
Shu bilan birga, agar tahlilchilar uxlab yotgan bo'lsa va hech kim hisobotlarga qaramasa, klasterlar butunlay qorong'i bo'lib qolishi mumkin va siz ular uchun to'lashni to'xtatasiz.
Shu bilan birga, og'ir so'rovlar uchun (Data Scientists'dan) siz 32 ta mashina uchun bitta juda katta klasterni ko'tarishingiz mumkin. Bu klaster, shuningdek, sizning ulkan so'rovingiz amalga oshirilgan daqiqalar va soatlar uchun ham to'lanadi.
Yuqorida tavsiflangan imkoniyat sizga nafaqat 2, balki ko'proq turdagi ish yuklarini klasterlarga (ETL, monitoring, hisobotni materiallashtirish,...) bo'lish imkonini beradi.
Keling, Snowflake-ni umumlashtiramiz. Baza chiroyli g'oya va amaliy amalga oshirishni birlashtiradi. ManyChat-da biz mavjud bo'lgan barcha ma'lumotlarni tahlil qilish uchun Snowflake-dan foydalanamiz. Bizda misoldagi kabi uchta klaster yo'q, lekin 5 dan 9 gacha, har xil o'lchamdagi. Bizda ba'zi vazifalar uchun odatiy 16-mashina, 2-mashina va shuningdek, o'ta kichik 1-mashinalar mavjud. Ular yukni muvaffaqiyatli taqsimlaydilar va bizga ko'p narsalarni tejash imkonini beradi.
Ma'lumotlar bazasi o'qish va yozish yukini muvaffaqiyatli o'lchaydi. Bu faqat o'qish yukini ko'targan bir xil "Aurora" bilan solishtirganda juda katta farq va ulkan yutuq. Snowflake sizga ushbu hisoblash klasterlari yordamida yozish ish yukingizni kengaytirish imkonini beradi. Ya'ni, aytib o'tganimdek, biz ManyChat-da bir nechta klasterlardan foydalanamiz, kichik va o'ta kichik klasterlar asosan ETL uchun, ma'lumotlarni yuklash uchun ishlatiladi. Va tahlilchilar allaqachon o'rta klasterlarda yashaydilar, ular ETL yukiga mutlaqo ta'sir qilmaydi, shuning uchun ular juda tez ishlaydi.
Shunga ko'ra, ma'lumotlar bazasi OLAP vazifalari uchun juda mos keladi. Ammo, afsuski, u OLTP ish yuklari uchun hali qo'llanilmaydi. Birinchidan, bu ma'lumotlar bazasi ustunli bo'lib, barcha oqibatlarga olib keladi. Ikkinchidan, yondashuvning o'zi, agar kerak bo'lsa, har bir so'rov uchun siz hisoblash klasterini ko'tarasiz va uni ma'lumotlar bilan to'ldirasiz, afsuski, OLTP yuklari uchun hali etarlicha tez emas. OLAP vazifalari uchun soniyalarni kutish odatiy hol, lekin OLTP vazifalari uchun bu qabul qilinishi mumkin emas; 100 ms yaxshiroq yoki 10 ms yaxshiroq bo'lar edi.
Xulosa
Ma'lumotlar bazasini fuqaroligi bo'lmagan va statistik qismlarga bo'lish orqali serversiz ma'lumotlar bazasini yaratish mumkin. Yuqoridagi barcha misollarda Stateful qismi, nisbatan aytganda, S3-da mikro-bo'limlarni saqlaydi va Stateless - bu optimallashtiruvchi, metama'lumotlar bilan ishlaydigan va mustaqil yengil va fuqaroligi bo'lmagan xizmatlar sifatida ko'tarilishi mumkin bo'lgan xavfsizlik masalalarini hal qilishini payqagandirsiz.
SQL so'rovlarini bajarish, shuningdek, Snowflake hisoblash klasterlari kabi serversiz rejimda paydo bo'lishi, faqat kerakli ma'lumotlarni yuklab olish, so'rovni bajarish va "tashqariga chiqish" mumkin bo'lgan engil holat xizmatlari sifatida ham qabul qilinishi mumkin.
Serversiz ishlab chiqarish darajasidagi ma'lumotlar bazalari foydalanish uchun allaqachon mavjud, ular ishlamoqda. Ushbu serversiz ma'lumotlar bazalari OLAP vazifalarini bajarishga tayyor. Afsuski, OLTP vazifalari uchun ular... nuanslar bilan ishlatiladi, chunki cheklovlar mavjud. Bir tomondan, bu minus. Ammo, boshqa tomondan, bu imkoniyat. Ehtimol, o'quvchilardan biri Aurora cheklovlarisiz OLTP ma'lumotlar bazasini butunlay serversiz qilish yo'lini topadi.
Umid qilamanki, sizga qiziqarli bo'ldi. Serversiz kelajak :)
Manba: www.habr.com