Salom, Xabrovsk aholisi. Kursning birinchi guruhida darslar bugundan boshlanadi . Shu munosabat bilan ushbu kurs bo'yicha ochiq vebinar qanday o'tgani haqida so'zlab bermoqchimiz.
В Biz bulutlar va Kubernetes davrida SQL ma'lumotlar bazalari duch keladigan qiyinchiliklar haqida gaplashdik. Shu bilan birga, biz SQL ma'lumotlar bazalarining ushbu qiyinchiliklar ta'sirida qanday moslashishi va mutatsiyaga uchrashini ko'rib chiqdik.
Vebinar bo'lib o'tdi , EPAM Systems kompaniyasida Google Cloud Practice Delivery Manager.
Daraxtlar kichkina bo'lganda ...
Avvalo, o'tgan asrning oxirida ma'lumotlar bazasini tanlash qanday boshlanganini eslaylik. Biroq, bu qiyin bo'lmaydi, chunki o'sha kunlarda ma'lumotlar bazasini tanlash boshlandi va tugadi Oracle.
90-yillarning oxiri va 2-yillarning boshlarida sanoat uchun kengaytiriladigan maʼlumotlar bazalari haqida gap ketganda, aslida hech qanday tanlov yoʻq edi. Ha, IBM DBXNUMX, Sybase va boshqa ba'zi ma'lumotlar bazalari kelib-ketdi, lekin umuman olganda, ular Oracle fonida unchalik sezilmadi. Shunga ko'ra, o'sha davr muhandislarining mahorati qandaydir tarzda mavjud bo'lgan yagona tanlov bilan bog'liq edi.
Oracle DBA quyidagilarni bilishi kerak edi:
- tarqatish to'plamidan Oracle Serverni o'rnating;
- Oracle serverini sozlang:
- init.ora;
- listener.ora;
- yaratmoq:
- stol maydonlari;
- Sxemalar
- foydalanuvchilar;
— zaxira nusxasini yaratish va tiklash;
— monitoringni amalga oshirish;
— suboptimal so'rovlar bilan shug'ullanish.
Shu bilan birga, Oracle DBA-dan hech qanday maxsus talab yo'q edi:
- ma'lumotlarni saqlash va qayta ishlash uchun optimal DBMS yoki boshqa texnologiyani tanlay olish;
- yuqori mavjudlik va gorizontal o'lchovni ta'minlash (bu har doim ham DBA muammosi emas edi);
- fan sohasi, infratuzilma, dastur arxitekturasi, OT ni yaxshi bilish;
- ma'lumotlarni yuklash va tushirish, turli ma'lumotlar bazalari o'rtasida ma'lumotlarni ko'chirish.
Umuman olganda, agar biz o'sha kunlarda tanlov haqida gapiradigan bo'lsak, u 80-yillarning oxirida Sovet do'konidagi tanlovga o'xshaydi:
Bizning vaqtimiz
O'shandan beri, albatta, daraxtlar o'sdi, dunyo o'zgardi va shunday bo'ldi:
Gartnerning so'nggi hisobotidan aniq ko'rinib turganidek, DBMS bozori ham o'zgargan:
Va bu erda shuni ta'kidlash kerakki, mashhurligi ortib borayotgan bulutlar o'z o'rnini egalladi. Xuddi shu Gartner hisobotini o'qisak, quyidagi xulosalarni ko'ramiz:
- Ko'pgina mijozlar ilovalarni bulutga ko'chirish yo'lida.
- Yangi texnologiyalar birinchi marta bulutda paydo bo'ladi va ular bulutli bo'lmagan infratuzilmaga o'tishlari haqiqat emas.
- “Ishlaganingizcha to‘lang” narxlash modeli odatiy holga aylandi. Har bir inson faqat foydalanadigan narsasi uchun to'lashni xohlaydi va bu hatto tendentsiya emas, balki shunchaki haqiqat bayonoti.
Endi nima?
Bugun hammamiz bulut ichidamiz. Biz uchun paydo bo'ladigan savollar esa tanlov savollaridir. Va bu juda katta, hatto biz faqat mahalliy formatda DBMS texnologiyalarini tanlash haqida gapiradigan bo'lsak ham. Bizda boshqariladigan xizmatlar va SaaS ham bor. Shunday qilib, har yili tanlov faqat qiyinlashadi.
Tanlov savollari bilan bir qatorda, ular ham mavjud cheklovchi omillar:
- narxlari. Ko'pgina texnologiyalar hali ham pul talab qiladi;
- ko'nikmalar. Agar biz bepul dasturiy ta'minot haqida gapiradigan bo'lsak, unda ko'nikmalar haqida savol tug'iladi, chunki bepul dasturiy ta'minot uni joylashtiradigan va boshqaradigan odamlardan etarli malakani talab qiladi;
- funktsional. Bulutda mavjud bo'lgan va, aytaylik, hatto bitta Postgres-da qurilgan barcha xizmatlar Postgres On-premises bilan bir xil xususiyatlarga ega emas. Bu bilish va tushunish kerak bo'lgan muhim omil. Bundan tashqari, bu omil bitta DBMSning ba'zi yashirin imkoniyatlarini bilishdan ko'ra muhimroq bo'ladi.
DA/DE dan hozir nima kutilmoqda:
- mavzu sohasi va dastur arxitekturasini yaxshi tushunish;
- topshirilgan vazifani hisobga olgan holda tegishli DBMS texnologiyasini to'g'ri tanlash qobiliyati;
- mavjud cheklovlar sharoitida tanlangan texnologiyani amalga oshirishning optimal usulini tanlash qobiliyati;
- ma'lumotlarni uzatish va migratsiyani amalga oshirish qobiliyati;
- tanlangan echimlarni amalga oshirish va ishlatish qobiliyati.
Quyida misol GCP asosida ma'lumotlar bilan ishlash uchun u yoki bu texnologiyani tanlash uning tuzilishiga qarab qanday ishlashini ko'rsatadi:
E'tibor bering, PostgreSQL sxemaga kiritilmagan va bu terminologiya ostida yashiringanligi sababli. Bulutli SQL. Va Cloud SQL-ga kelganimizda, biz yana tanlov qilishimiz kerak:
Shuni ta'kidlash kerakki, bu tanlov har doim ham aniq emas, shuning uchun dastur ishlab chiquvchilari ko'pincha sezgi bilan boshqariladi.
Jami:
- Qanchalik uzoqqa borsangiz, tanlov masalasi shunchalik dolzarb bo'lib qoladi. Va agar siz faqat GCP, boshqariladigan xizmatlar va SaaS-ga qarasangiz ham, RDBMS haqida ba'zi eslatmalar faqat 4-bosqichda paydo bo'ladi (va u erda Spanner yaqin joyda). Bundan tashqari, PostgreSQL tanlovi 5-bosqichda paydo bo'ladi va uning yonida MySQL va SQL Server ham mavjud, ya'ni hamma narsa juda ko'p, lekin siz tanlashingiz kerak.
- Vasvasalar fonida cheklovlar haqida unutmasligimiz kerak. Asosan hamma kalitni xohlaydi, lekin bu qimmat. Natijada, odatiy so'rov quyidagicha ko'rinadi: "Iltimos, bizga kalit yarating, ammo Cloud SQL narxiga siz professionalsiz!"
Nima qilishim kerak?
O'zini yakuniy haqiqat deb da'vo qilmasdan, keling, quyidagilarni aytaylik:
Biz o'rganishga yondashuvimizni o'zgartirishimiz kerak:
- ilgari DBA o'qitilgan usulni o'rgatishning ma'nosi yo'q;
- bitta mahsulot haqida bilim endi etarli emas;
- lekin bir darajada o'nlab bilish mumkin emas.
Siz nafaqat mahsulot qancha ekanligini bilishingiz kerak, balki:
- uni qo'llashdan foydalanish holati;
- turli xil joylashtirish usullari;
- har bir usulning afzalliklari va kamchiliklari;
- o'xshash va muqobil mahsulotlar xabardor va maqbul tanlov qilish va har doim ham tanish mahsulot foydasiga emas.
Shuningdek, siz ma'lumotlarni ko'chirishingiz va ETL bilan integratsiyaning asosiy tamoyillarini tushunishingiz kerak.
haqiqiy holat
Yaqin o'tmishda mobil ilova uchun backend yaratish kerak edi. U ustida ish boshlangan vaqtga kelib, backend allaqachon ishlab chiqilgan va amalga oshirishga tayyor edi va ishlab chiqish guruhi ushbu loyihaga taxminan ikki yil vaqt sarfladi. Quyidagi vazifalar belgilandi:
- CI/CD yaratish;
- arxitekturani ko'rib chiqish;
- hammasini ishga tushiring.
Ilovaning o'zi mikroservislar edi va Python/Django kodi noldan va to'g'ridan-to'g'ri GCPda ishlab chiqilgan. Maqsadli auditoriyaga kelsak, ikkita mintaqa - AQSh va Evropa Ittifoqi bo'lishi taxmin qilingan va trafik Global Load balanslagich orqali taqsimlangan. Barcha ish yuklari va hisoblash ish yuki Google Kubernetes Engine’da ishlagan.
Ma'lumotlarga kelsak, 3 ta tuzilma mavjud edi:
- Bulutli saqlash;
- Ma'lumotlar ombori;
- Bulutli SQL (PostgreSQL).
Nima uchun Cloud SQL tanlanganligi qiziq bo'lishi mumkin? Rostini aytsam, bunday savol so'nggi yillarda qandaydir noqulay pauzani keltirib chiqardi - odamlar relyatsion ma'lumotlar bazalaridan tortinchoq bo'lishdi, ammo shunga qaramay ular ulardan faol foydalanishda davom etmoqdalar ;-).
Bizning holatimizga kelsak, Cloud SQL quyidagi sabablarga ko'ra tanlangan:
- Yuqorida aytib o'tilganidek, dastur Django yordamida ishlab chiqilgan va u SQL ma'lumotlar bazasidan Python ob'ektlariga (Django ORM) doimiy ma'lumotlarni xaritalash uchun modelga ega.
- Ramkaning o'zi DBMSlarning juda cheklangan ro'yxatini qo'llab-quvvatladi:
- PostgreSQL;
- MariaDB;
- MySQL
- Oracles;
- SQLite.
Shunga ko'ra, PostgreSQL ushbu ro'yxatdan intuitiv ravishda tanlangan (yaxshi, Oracle emas, albatta).
Nima etishmayotgan edi:
- ilova faqat 2 ta mintaqada joylashtirildi va uchinchisi rejalarda (Osiyo) paydo bo'ldi;
- Ma'lumotlar bazasi Shimoliy Amerika mintaqasida (Ayova shtati) joylashgan edi;
- mijoz tomonidan mumkin bo'lgan xavotirlar bor edi kirish kechikishlari Yevropa va Osiyodan va uzilishlar xizmatda DBMS ishlamay qolganda.
Django-ning o'zi bir nechta ma'lumotlar bazalari bilan parallel ravishda ishlashi va ularni o'qish va yozishga bo'lishi mumkinligiga qaramay, ilovada unchalik ko'p yozuv bo'lmagan (90% dan ortig'i o'qiydi). Va umuman, va umuman olganda, agar buni qilish mumkin bo'lsa Evropa va Osiyodagi asosiy bazaning o'qish-replikasi, bu murosali yechim bo'ladi. Xo'sh, buning nimasi murakkab?
Qiyinchilik shundaki, mijoz boshqariladigan xizmatlar va Cloud SQL-dan voz kechishni istamadi. Va Cloud SQL imkoniyatlari hozirda cheklangan. Cloud SQL yuqori mavjudlik (HA) va o'qish replikasini (RR) qo'llab-quvvatlaydi, lekin bir xil RR faqat bitta mintaqada qo'llab-quvvatlanadi. Amerika mintaqasida ma'lumotlar bazasini yaratganingizdan so'ng, siz Cloud SQL-dan foydalangan holda Evropa mintaqasida o'qish nusxasini yarata olmaysiz, garchi Postgresning o'zi buni amalga oshirishga to'sqinlik qilmasa ham. Google xodimlari bilan yozishmalar hech qanday natija bermadi va "biz muammoni bilamiz va uning ustida ishlayapmiz, bir kun kelib muammo hal qilinadi" tarzidagi va'dalar bilan yakunlandi.
Agar Cloud SQL imkoniyatlarini qisqacha sanab olsak, u quyidagicha ko'rinadi:
1. Yuqori mavjudlik (HA):
- bir hududda;
- diskni replikatsiya qilish orqali;
- PostgreSQL dvigatellari ishlatilmaydi;
- avtomatik va qo'lda boshqarish mumkin - o'chirish/failback;
- O'tish paytida DBMS bir necha daqiqa davomida mavjud bo'lmaydi.
2. Replika (RR) ni o‘qing:
- bir hududda;
- issiq kutish;
- PostgreSQL oqimli replikatsiya.
Bundan tashqari, odatdagidek, texnologiyani tanlashda siz doimo ba'zilariga duch kelasiz cheklovlar:
- mijoz ob'ektlar yaratishni va IaaS-dan foydalanishni xohlamadi, faqat GKE orqali;
- mijoz o'z-o'ziga xizmat ko'rsatish PostgreSQL/MySQL-ni qo'llashni xohlamaydi;
- Umuman olganda, Google Spanner uning narxi bo'lmaganda juda mos bo'lar edi, ammo Django ORM u bilan ishlay olmaydi, lekin bu yaxshi narsa.
Vaziyatni hisobga olgan holda, mijoz keyingi savolni oldi: "Siz Google Spanner kabi, lekin Django ORM bilan ham ishlashi uchun shunga o'xshash narsani qila olasizmi?"
Yechim varianti № 0
Aqlga kelgan birinchi narsa:
- CloudSQL ichida qolish;
- mintaqalar o'rtasida hech qanday shaklda o'rnatilgan replikatsiya bo'lmaydi;
- PostgreSQL tomonidan mavjud Cloud SQL-ga nusxasini biriktirishga harakat qiling;
- qaerdadir va qandaydir tarzda PostgreSQL misolini ishga tushiring, lekin hech bo'lmaganda masterga tegmang.
Afsuski, buni amalga oshirish mumkin emasligi ma'lum bo'ldi, chunki xostga kirish imkoni yo'q (u umuman boshqa loyihada) - pg_hba va boshqalar, shuningdek, superuser ostida ham kirish imkoni yo'q.
Yechim varianti № 1
Keyinchalik mulohaza yuritish va oldingi holatlarni hisobga olgan holda, fikrlash poyezdi biroz o'zgardi:
- Biz hali ham CloudSQL ichida qolishga harakat qilmoqdamiz, lekin MySQL-ga o'tmoqdamiz, chunki MySQL tomonidan Cloud SQL tashqi masterga ega, bu:
— tashqi MySQL uchun proksi-server;
- MySQL misoliga o'xshaydi;
- boshqa bulutlardan yoki mahalliy joylardan ma'lumotlarni ko'chirish uchun ixtiro qilingan.
MySQL replikatsiyasini sozlash xostga kirishni talab qilmaganligi sababli, printsipial jihatdan hamma narsa ishladi, lekin u juda beqaror va noqulay edi. Va biz oldinga borganimizda, bu butunlay qo'rqinchli bo'ldi, chunki biz butun tuzilmani terraform bilan joylashtirdik va to'satdan tashqi usta terraform tomonidan qo'llab-quvvatlanmagani ma'lum bo'ldi. Ha, Google-da CLI bor, lekin negadir bu yerda hamma narsa vaqti-vaqti bilan ishlagan - ba'zida u yaratilgan, ba'zida esa yaratilmagan. Ehtimol, CLI nusxalar uchun emas, balki tashqi ma'lumotlarni ko'chirish uchun ixtiro qilinganligi sababli.
Aslida, Cloud SQL umuman mos kelmasligi aniq bo'ldi. Ular aytganidek, biz qo'limizdan kelganini qildik.
Yechim varianti № 2
Cloud SQL doirasida qolishning iloji bo'lmagani uchun biz murosali yechim uchun talablarni shakllantirishga harakat qildik. Talablar quyidagilar bo'lib chiqdi:
- Kubernetesda ishlash, Kubernetes (DCS, ...) va GCP (LB, ...) resurslari va imkoniyatlaridan maksimal darajada foydalanish;
- HA proksi kabi bulutdagi keraksiz narsalar to'plamidan balast yo'qligi;
- asosiy HA hududida PostgreSQL yoki MySQL-ni ishga tushirish qobiliyati; boshqa hududlarda - asosiy mintaqaning RR dan HA va uning nusxasi (ishonchliligi uchun);
- multi master (men u bilan bog'lanishni xohlamadim, lekin bu juda muhim emas edi)
.
Bu talablar natijasida bmos DBMS va bog'lash variantlari:
- MySQL Galera;
- CockroachDB;
- PostgreSQL vositalari
:
- pgpool-II;
- Patroni.
MySQL Galera
MySQL Galera texnologiyasi Codership tomonidan ishlab chiqilgan va InnoDB uchun plagin hisoblanadi. Xususiyatlari:
- multi master;
- sinxron replikatsiya;
- har qanday tugundan o'qish;
- har qanday tugunga yozib olish;
- o'rnatilgan HA mexanizmi;
- Bitnami-dan Helm diagrammasi mavjud.
HamamböceğiDB
Ta'rifga ko'ra, bu narsa mutlaqo bomba va Go'da yozilgan ochiq manbali loyihadir. Asosiy ishtirokchi - Cockroach Labs (Google'dan odamlar tomonidan asos solingan). Ushbu relyatsion DBMS dastlab tarqatish (qutidan gorizontal o'lchov bilan) va xatolarga chidamli bo'lish uchun ishlab chiqilgan. Kompaniyaning mualliflari "SQL funksionalligining boyligini NoSQL yechimlari bilan tanish bo'lgan gorizontal foydalanish imkoniyati bilan birlashtirish" maqsadini belgilab qo'ydilar.
Yaxshi bonus - bu post-gress ulanish protokolini qo'llab-quvvatlash.
Pgpool
Bu PostgreSQL qo'shimchasi, aslida barcha ulanishlarni o'z zimmasiga oladigan va ularni qayta ishlovchi yangi ob'ekt. U BSD litsenziyasi ostida litsenziyalangan o'zining yuk balansi va tahlilchisiga ega. Bu keng imkoniyatlar beradi, lekin biroz qo'rqinchli ko'rinadi, chunki yangi shaxsning mavjudligi ba'zi qo'shimcha sarguzashtlarning manbai bo'lishi mumkin.
Patroni
Bu mening ko'zlarimga tushgan oxirgi narsa va ma'lum bo'lishicha, behuda emas. Patroni ochiq kodli yordamchi dastur bo'lib, u Python dasturi bo'lib, u sizga PostgreSQL klasterlarini turli xil replikatsiya va avtomatik rol almashish bilan avtomatik ravishda saqlash imkonini beradi. Bu narsa juda qiziq bo'lib chiqdi, chunki u kub bilan yaxshi birlashadi va hech qanday yangi ob'ektlarni kiritmaydi.
Oxirida nimani tanladingiz?
Tanlov oson emas edi:
- HamamböceğiDB - olov, lekin qorong'i;
- MySQL Galera - ham yomon emas, u ko'p joylarda ishlatiladi, lekin MySQL;
- Pgpool — juda ko'p keraksiz ob'ektlar, shuning uchun bulut va K8s bilan integratsiya;
- Patroni - K8s bilan mukammal integratsiya, keraksiz ob'ektlar yo'q, GCP LB bilan yaxshi integratsiya.
Shunday qilib, tanlov Patroniga tushdi.
topilmalar
Qisqacha xulosa qilish vaqti keldi. Ha, IT infratuzilmasi dunyosi sezilarli darajada o'zgardi va bu faqat boshlanishi. Va agar oldin bulutlar boshqa turdagi infratuzilma bo'lsa, endi hamma narsa boshqacha. Bundan tashqari, bulutlardagi innovatsiyalar doimiy ravishda paydo bo'ladi, ular paydo bo'ladi va, ehtimol, ular faqat bulutlarda paydo bo'ladi va shundan keyingina startaplarning sa'y-harakatlari bilan ular On-premises-ga o'tkaziladi.
SQL-ga kelsak, SQL yashaydi. Bu shuni anglatadiki, siz PostgreSQL va MySQL-ni bilishingiz va ular bilan ishlashingiz kerak, lekin undan ham muhimi, ulardan to'g'ri foydalana bilishdir.
Manba: www.habr.com