Здраво, жители на Хабровск. Наставата во првата група на курсот започнува денеска . Во овој поглед, би сакале да ви кажеме како се одвиваше отворениот вебинар на овој курс.
В зборувавме за предизвиците со кои се соочуваат базите на податоци на SQL во ерата на облаците и Кубернетите. Во исто време, разгледавме како SQL базите на податоци се прилагодуваат и мутираат под влијание на овие предизвици.
Се одржа вебинарот , Google Cloud Practice Delivery Manager во EPAM Systems.
Кога дрвјата беа мали ...
Прво, да се потсетиме како започна изборот на DBMS на крајот на минатиот век. Сепак, ова нема да биде тешко, бидејќи изборот на DBMS во тие денови започна и заврши Oracle.
Во доцните 90-ти и раните 2-ти, во суштина немаше избор кога станува збор за индустриски скалабилни бази на податоци. Да, имаше IBM DBXNUMX, Sybase и некои други бази на податоци кои доаѓаа и одеа, но генерално тие не беа толку забележливи на позадината на Oracle. Според тоа, вештините на инженерите од тоа време беа некако врзани за единствениот избор што постоеше.
Oracle DBA мораше да може:
- инсталирај Oracle Server од комплетот за дистрибуција;
- конфигурирајте го Oracle Server:
- init.ora;
- слушател.ора;
- креирајте:
- простори за маса;
- шема;
- корисници;
— направете резервна копија и обновување;
— врши мониторинг;
— справување со неоптимални барања.
Во исто време, немаше посебни барања од Oracle DBA:
- да може да избере оптимален DBMS или друга технологија за складирање и обработка на податоци;
- обезбеди висока достапност и хоризонтална приспособливост (ова не беше секогаш проблем со DBA);
- добро познавање на предметната област, инфраструктура, архитектура на апликации, ОС;
- вчитувајте и растоварувајте податоци, мигрирајте податоци помеѓу различни DBMS.
Во принцип, ако зборуваме за изборот во тие денови, тоа наликува на изборот во советска продавница во доцните 80-ти:
Нашето време
Оттогаш, се разбира, дрвјата пораснаа, светот се промени и стана вака:
Пазарот на DBMS исто така се промени, како што може јасно да се види од најновиот извештај од Гартнер:
И тука треба да се забележи дека облаците, чија популарност расте, ја окупираа нивната ниша. Ако го прочитаме истиот извештај на Гартнер, ќе ги видиме следните заклучоци:
- Многу клиенти се на пат да ги преместат апликациите во облакот.
- Новите технологии прво се појавуваат во облакот и не е факт дека тие некогаш ќе се преселат во инфраструктура без облак.
- Моделот на цени што се плаќа како што треба стана вообичаен. Секој сака да плати само за тоа што го користи, а тоа не е ниту тренд, туку едноставно констатација на фактите.
Што сега?
Денес сите сме во облакот. А прашањата што ни се наметнуваат се прашања на избор. И тоа е огромно, дури и ако зборуваме само за изборот на технологии DBMS во формат On-premises. Имаме и управувани услуги и SaaS. Така, изборот станува само потежок секоја година.
Заедно со прашања на избор, има и ограничувачки фактори:
- цена. Многу технологии сè уште чинат пари;
- вештини. Ако зборуваме за слободен софтвер, тогаш се поставува прашањето за вештините, бидејќи слободниот софтвер бара доволна компетентност од луѓето кои го распоредуваат и управуваат со него;
- функционална. Не сите услуги што се достапни во облакот и изградени, да речеме, дури и на истиот Postgres, ги имаат истите карактеристики како Postgres On-premises. Ова е суштински фактор што треба да се знае и разбере. Покрај тоа, овој фактор станува поважен од знаењето за некои скриени способности на еден DBMS.
Што се очекува од DA/DE сега:
- добро разбирање на предметната област и архитектура на апликации;
- способноста за правилно избирање на соодветната технологија DBMS, земајќи ја предвид задачата што е при рака;
- способноста да се избере оптималниот метод за имплементација на избраната технологија во контекст на постоечките ограничувања;
- способност за извршување на пренос на податоци и миграција;
- способност за имплементација и управување со избрани решенија.
Подолу пример врз основа на GCP покажува како функционира изборот на една или друга технологија за работа со податоци во зависност од нејзината структура:
Ве молиме имајте предвид дека PostgreSQL не е вклучена во шемата, а тоа е затоа што е скриено под терминологијата Облак SQL. И кога ќе стигнеме до Cloud SQL, треба повторно да направиме избор:
Треба да се напомене дека овој избор не е секогаш јасен, така што развивачите на апликации често се водени од интуиција.
Вкупно:
- Колку подалеку одите, толку попритиснато станува прашањето за избор. И дури и ако ги погледнете само GCP, управуваните услуги и SaaS, тогаш некое спомнување на RDBMS се појавува само на 4-тиот чекор (а таму е Spanner во близина). Плус, изборот на PostgreSQL се појавува во 5-тиот чекор, а до него се и MySQL и SQL Server, т.е. има многу од сè, но треба да изберете.
- Не смееме да заборавиме на ограничувањата наспроти позадината на искушенијата. Во основа секој сака клуч, но тој е скап. Како резултат на тоа, типично барање изгледа вака: „Ве молиме направете ни клуч, но за цената на Cloud SQL, вие сте професионалци!
Што треба да правиме?
Без да тврдиме дека е крајната вистина, да го кажеме следново:
Треба да го промениме нашиот пристап кон учењето:
- нема смисла да се предава на начинот на кој DBA се предавале претходно;
- знаењето за еден производ веќе не е доволно;
- но да се познаваат десетици на ниво на еден е невозможно.
Треба да знаете не само и не колку е производот, туку:
- употреба случај на неговата примена;
- различни методи на распоредување;
- предности и недостатоци на секој метод;
- слични и алтернативни производи за да се направи информиран и оптимален избор и не секогаш во корист на познат производ.
Исто така, треба да бидете во можност да мигрирате податоци и да ги разберете основните принципи на интеграција со ETL.
Вистински случај
Во неодамнешното минато, беше неопходно да се создаде бекенд за мобилна апликација. До моментот кога започна работата на него, задниот дел веќе беше развиен и подготвен за имплементација, а тимот за развој потроши околу две години на овој проект. Беа поставени следните задачи:
- изгради CI/CD;
- преглед на архитектурата;
- стави сето тоа во функција.
Самата апликација беше микросервис, а кодот Python/Django беше развиен од нула и директно во GCP. Што се однесува до целната публика, се претпоставуваше дека ќе има два региони - САД и ЕУ, а сообраќајот се дистрибуираше преку Global Load balancer. Сите оптоварувања и пресметување на обемот на работа работеа на Google Kubernetes Engine.
Што се однесува до податоците, имаше 3 структури:
- Складирање во облак;
- Продавница за податоци;
- Облак SQL (PostgreSQL).
Некој може да се запраша зошто е избран Cloud SQL? Да ја кажеме вистината, таквото прашање предизвика некаква непријатна пауза во последниве години - постои чувство дека луѓето се срамат од релационите бази на податоци, но сепак тие продолжуваат активно да ги користат ;-).
Што се однесува до нашиот случај, Cloud SQL беше избран од следниве причини:
- Како што споменавме, апликацијата е развиена со помош на Django и има модел за мапирање на постојани податоци од базата на податоци SQL на објекти на Python (Django ORM).
- Самата рамка поддржуваше прилично конечен список на DBMS:
- PostgreSQL;
- MariaDB;
- MySQL;
- пророци;
- SQLite.
Според тоа, PostgreSQL беше избран од оваа листа прилично интуитивно (добро, не е Oracle да се избере, навистина).
Што недостасуваше:
- апликацијата беше распоредена само во 2 региони, а третата се појави во плановите (Азија);
- Базата на податоци се наоѓаше во северноамериканскиот регион (Ајова);
- од страна на клиентот имаше загриженост за можно одложувања на пристапот од Европа и Азија и прекини во употреба во случај на прекин на DBMS.
И покрај тоа што самиот Џанго може да работи со неколку бази на податоци паралелно и да ги дели на читање и пишување, немаше толку многу пишување во апликацијата (повеќе од 90% читаат). И воопшто, и воопшто, ако беше можно да се направи читање-реплика на главната база во Европа и Азија, ова би било компромисно решение. Па, што е толку комплицирано во тоа?
Тешкотијата беше што клиентот не сакаше да се откаже од користење на управувани услуги и Cloud SQL. И можностите на Cloud SQL во моментов се ограничени. Cloud SQL поддржува висока достапност (HA) и Read Replica (RR), но истиот RR е поддржан само во еден регион. Откако создадовте база на податоци во американскиот регион, не можете да направите реплика за читање во европскиот регион користејќи Cloud SQL, иако самиот Postgres не ве спречува да го направите ова. Преписката со вработените во Гугл не водеше никаде и заврши со ветувања во стилот „го знаеме проблемот и работиме на него, еден ден проблемот ќе се реши“.
Ако накратко ги наведеме можностите на Cloud SQL, тоа ќе изгледа вака:
1. Висока достапност (HA):
- во еден регион;
- преку репликација на дискот;
- PostgreSQL моторите не се користат;
- можна е автоматска и рачна контрола - Failover/failback;
- При префрлување, DBMS е недостапен неколку минути.
2. Прочитајте ја репликата (RR):
- во еден регион;
- топло мирување;
- Репликација на стриминг PostgreSQL.
Покрај тоа, како што е вообичаено, при изборот на технологија секогаш се соочувате со некои ограничувања:
- клиентот не сакаше да создава ентитети и да користи IaaS, освен преку GKE;
- клиентот не би сакал да користи самоуслуга PostgreSQL/MySQL;
- Па, генерално, Google Spanner би бил сосема соодветен ако не е за неговата цена, сепак, Django ORM не може да работи со него, но тоа е добра работа.
Со оглед на ситуацијата, клиентот доби следно прашање: „Можете ли да направите нешто слично за да биде како Google Spanner, но да работи и со Django ORM?
Опција за решение бр. 0
Првото нешто што ми падна на ум:
- останете во CloudSQL;
- нема да има вградена репликација помеѓу регионите во која било форма;
- обидете се да прикачите реплика на постоечки Cloud SQL од PostgreSQL;
- лансирајте пример на PostgreSQL некаде и некако, но барем не допирајте го господарот.
За жал, се покажа дека тоа не може да се направи, бидејќи нема пристап до домаќинот (тој е целосно во друг проект) - pg_hba и така натаму, а исто така нема пристап под суперкорисник.
Опција за решение бр. 1
По понатамошното размислување и земајќи ги предвид претходните околности, возот на мислите малку се промени:
- Сè уште се обидуваме да останеме во CloudSQL, но се префрламе на MySQL, бидејќи Cloud SQL од MySQL има надворешен господар, кој:
— е прокси за надворешен MySQL;
- изгледа како пример на MySQL;
- измислен за мигрирање на податоци од други облаци или On-premises.
Бидејќи поставувањето на репликацијата на MySQL не бара пристап до домаќинот, во принцип сè функционираше, но беше многу нестабилно и незгодно. И кога отидовме подалеку, стана сосема страшно, бидејќи ја распоредивме целата структура со тераформ, и одеднаш се покажа дека надворешниот мајстор не е поддржан од тераформ. Да, Google има CLI, но поради некоја причина сè функционираше овде одвреме-навреме - понекогаш се создава, понекогаш не се создава. Можеби затоа што CLI е измислен за надворешна миграција на податоци, а не за реплики.
Всушност, во овој момент стана јасно дека Cloud SQL воопшто не е соодветен. Како што велат, направивме се што можевме.
Опција за решение бр. 2
Бидејќи не беше можно да се остане во рамките на Cloud SQL, се обидовме да формулираме барања за компромисно решение. Барањата се покажаа како што следува:
- работа во Kubernetes, максимално искористување на ресурсите и можностите на Kubernetes (DCS, ...) и GCP (LB, ...);
- недостаток на баласт од еден куп непотребни работи во облакот како HA прокси;
- можност за извршување на PostgreSQL или MySQL во главниот HA регион; во други региони - HA од RR на главниот регион плус неговата копија (за сигурност);
- мулти мајстор (не сакав да контактирам со него, но не беше многу важно)
.
Како резултат на овие барања, стрсоодветни DBMS и опции за врзување:
- MySQL Galera;
- ТавтабитаДБ;
- PostgreSQL алатки
:
- pgpool-II;
- Патрони.
MySQL Galera
Технологијата MySQL Galera е развиена од Codership и е приклучок за InnoDB. Особености:
- мулти мајстор;
- синхрона репликација;
- читање од кој било јазол;
- снимање на кој било јазол;
- вграден HA механизам;
- Постои дијаграм на Helm од Bitnami.
Лебарка ДБ
Според описот, работата е апсолутно бомба и е проект со отворен код напишан во Go. Главниот учесник е Cockroach Labs (основана од луѓе од Google). Овој релациски DBMS првично беше дизајниран да биде дистрибуиран (со хоризонтално скалирање надвор од кутијата) и толерантен на грешки. Нејзините автори од компанијата ја истакнаа целта за „комбинирање на богатството на функционалноста на SQL со хоризонталната пристапност позната на решенијата NoSQL“.
Убав бонус е поддршката за протоколот за поврзување после напредување.
Пгпул
Ова е додаток на PostgreSQL, всушност, нов ентитет кој ги презема сите врски и ги обработува. Има сопствен балансирач и парсер, лиценциран под лиценцата BSD. Обезбедува многу можности, но изгледа малку застрашувачки, бидејќи присуството на нов ентитет може да стане извор на некои дополнителни авантури.
Покровител
Ова е последното нешто на што ми паднаа очите и, како што се испостави, не залудно. Patroni е алатка со отворен код, која во суштина е Python демон кој ви овозможува автоматски да одржувате PostgreSQL кластери со различни типови на репликација и автоматско префрлување на улоги. Работата се покажа како многу интересна, бидејќи добро се интегрира со куберот и не воведува нови ентитети.
Што избравте на крајот?
Изборот не беше лесен:
- Лебарка ДБ - оган, но темно;
- MySQL Galera - исто така не е лошо, се користи на многу места, но MySQL;
- Пгпул — многу непотребни ентитети, така-така интеграција со облакот и K8s;
- Покровител - одлична интеграција со K8, без непотребни ентитети, добро се интегрира со GCP LB.
Така, изборот падна на Патрони.
Наоди
Време е накратко да сумираме. Да, светот на ИТ инфраструктурата значително се промени, и ова е само почеток. И ако порано облаците беа само друг тип на инфраструктура, сега сè е поинаку. Згора на тоа, иновациите во облаците постојано се појавуваат, тие ќе се појавуваат и, можеби, ќе се појават само во облаците и дури тогаш, со напорите на стартапите, ќе бидат префрлени во On-premises.
Што се однесува до SQL, SQL ќе живее. Ова значи дека треба да ги знаете PostgreSQL и MySQL и да можете да работите со нив, но уште поважно е да можете правилно да ги користите.
Извор: www.habr.com