Здравейте, жители на Хабровск. От днес започват занятията в първа група от курса . В тази връзка бихме искали да ви разкажем как протече откритият уебинар по този курс.
В говорихме за предизвикателствата, пред които са изправени SQL базите данни в ерата на облаците и Kubernetes. В същото време разгледахме как SQL базите данни се адаптират и мутират под влиянието на тези предизвикателства.
Уебинарът се проведе , Google Cloud Practice Delivery Manager в EPAM Systems.
Когато дърветата бяха малки...
Първо, нека си припомним как започна изборът на СУБД в края на миналия век. Това обаче няма да е трудно, защото изборът на СУБД в онези дни започна и приключи Оракул.
В края на 90-те и началото на 2-те по същество нямаше избор, когато става дума за индустриални мащабируеми бази данни. Да, имаше IBM DBXNUMX, Sybase и някои други бази данни, които идваха и си отиваха, но като цяло не бяха толкова забележими на фона на Oracle. Съответно, уменията на инженерите от онези времена по някакъв начин са били обвързани с единствения съществуващ избор.
Oracle DBA трябваше да може да:
- инсталирайте Oracle Server от комплекта за разпространение;
- конфигуриране на Oracle сървър:
- init.ora;
- слушател.ora;
- създайте:
- таблични пространства;
- схеми;
- потребители;
— извършване на архивиране и възстановяване;
— извършва мониторинг;
— справяне с неоптимални заявки.
В същото време нямаше специално изискване от Oracle DBA:
- да може да избира оптималната СУБД или друга технология за съхраняване и обработка на данни;
- осигуряват висока достъпност и хоризонтална мащабируемост (това не винаги е проблем на DBA);
- добро познаване на предметната област, инфраструктура, архитектура на приложенията, ОС;
- зареждане и разтоварване на данни, мигриране на данни между различни СУБД.
Като цяло, ако говорим за избора в онези дни, той прилича на избора в съветски магазин в края на 80-те:
Нашето време
Оттогава, разбира се, дърветата пораснаха, светът се промени и стана нещо подобно:
Пазарът на СУБД също се промени, както ясно се вижда от последния доклад на Gartner:
И тук трябва да се отбележи, че облаците, чиято популярност нараства, заеха своята ниша. Ако прочетем същия доклад на Gartner, ще видим следните заключения:
- Много клиенти са на път да преместят приложения в облака.
- Новите технологии се появяват за първи път в облака и не е факт, че някога ще преминат към необлачна инфраструктура.
- Моделът на ценообразуване на разплащане се превърна в нещо обичайно. Всеки иска да плаща само за това, което използва и това дори не е тенденция, а просто изявление на факта.
Сега какво?
Днес всички сме в облака. И въпросите, които възникват пред нас, са въпроси на избор. И то е огромно, дори ако говорим само за избора на СУБД технологии във формат On-premises. Имаме и управлявани услуги и SaaS. Така изборът става все по-труден всяка година.
Наред с въпросите по избор има и ограничаващи фактори:
- цена. Много технологии все още струват пари;
- умения. Ако говорим за безплатен софтуер, тогава възниква въпросът за уменията, тъй като свободният софтуер изисква достатъчна компетентност от хората, които го внедряват и работят с него;
- функционален. Не всички услуги, които са налични в облака и изградени, да речем, дори на същия Postgres, имат същите функции като Postgres On-premises. Това е съществен фактор, който трябва да се знае и разбира. Освен това този фактор става по-важен от познаването на някои скрити възможности на една СУБД.
Какво се очаква от DA/DE сега:
- добро разбиране на предметната област и архитектурата на приложението;
- способността за правилен избор на подходяща СУБД технология, като се вземе предвид поставената задача;
- способност за избор на оптимален метод за внедряване на избраната технология в контекста на съществуващите ограничения;
- възможност за извършване на трансфер и миграция на данни;
- способност за внедряване и експлоатация на избрани решения.
Пример по-долу въз основа на GCP демонстрира как протича изборът на една или друга технология за работа с данни в зависимост от тяхната структура:
Моля, имайте предвид, че PostgreSQL не е включен в схемата и това е така, защото е скрит под терминологията Облачен SQL. И когато стигнем до Cloud SQL, трябва да направим избор отново:
Трябва да се отбележи, че този избор не винаги е ясен, така че разработчиците на приложения често се ръководят от интуицията.
Общо:
- Колкото по-напред отивате, толкова по-належащ става въпросът за избора. И дори ако погледнете само GCP, управлявани услуги и SaaS, тогава известно споменаване на RDBMS се появява само на 4-та стъпка (и там Spanner е наблизо). Плюс това изборът на PostgreSQL се появява в 5-та стъпка, а до него има и MySQL и SQL Server, т.е. има от всичко по много, но трябва да изберете.
- Не трябва да забравяме за ограниченията на фона на изкушенията. По принцип всеки иска Spanner, но е скъп. В резултат на това една типична заявка изглежда така: „Моля, направете ни Spanner, но за цената на Cloud SQL вие сте професионалисти!“
Какво трябва да направя?
Без да претендираме за истина от последна инстанция, нека кажем следното:
Трябва да променим подхода си към ученето:
- няма смисъл да се преподава по начина, по който се преподаваше на DBA преди;
- познаването на един продукт вече не е достатъчно;
- но познаването на десетки на ниво едно е невъзможно.
Трябва да знаете не само и не колко е продуктът, но:
- случай на използване на неговото приложение;
- различни методи за разгръщане;
- предимства и недостатъци на всеки метод;
- подобни и алтернативни продукти, за да направите информиран и оптимален избор, а не винаги в полза на познат продукт.
Също така трябва да можете да мигрирате данни и да разбирате основните принципи на интеграция с ETL.
Реален случай
В близкото минало беше необходимо да се създаде бекенд за мобилно приложение. Докато започна работата по него, бекендът вече беше разработен и готов за внедряване, а екипът за разработка прекара около две години в този проект. Бяха поставени следните задачи:
- изграждане на CI/CD;
- преглед на архитектурата;
- пуснете всичко в действие.
Самото приложение беше микроуслуга, а кодът на Python/Django беше разработен от нулата и директно в GCP. Що се отнася до целевата аудитория, се предполагаше, че ще има два региона - САЩ и ЕС, а трафикът се разпределяше чрез Global Load balancer. Всички работни натоварвания и изчислително натоварване се изпълняваха на Google Kubernetes Engine.
Що се отнася до данните, имаше 3 структури:
- Съхранение в облака;
- Datastore;
- Cloud SQL (PostgreSQL).
Човек може да се чуди защо е избран Cloud SQL? Честно казано, такъв въпрос предизвика някаква неудобна пауза през последните години - има усещането, че хората са се срамували от релационните бази данни, но въпреки това продължават активно да ги използват ;-).
Що се отнася до нашия случай, Cloud SQL беше избран поради следните причини:
- Както споменахме, приложението е разработено с помощта на Django и има модел за картографиране на постоянни данни от SQL база данни към обекти на Python (Django ORM).
- Самата рамка поддържаше доста краен списък от СУБД:
- PostgreSQL;
- MariaDB;
- MySQL;
- оракули;
- SQLite.
Съответно, PostgreSQL беше избран от този списък доста интуитивно (е, не Oracle трябва да избира, наистина).
Какво липсваше:
- приложението беше разгърнато само в 2 региона, а 3-ти се появи в плановете (Азия);
- Базата данни се намираше в района на Северна Америка (Айова);
- от страна на клиента имаше притеснения за възможно забавяне на достъпа от Европа и Азия и прекъсвания в сервиз в случай на прекъсване на СУБД.
Въпреки факта, че самият Django може да работи с няколко бази данни паралелно и да ги разделя на четене и писане, в приложението нямаше толкова много писане (повече от 90% е четене). И като цяло, и като цяло, ако беше възможно да се направи read-реплика на основната база в Европа и Азия, това би било компромисно решение. Е, какво му е сложното?
Трудността беше, че клиентът не искаше да се откаже от използването на управлявани услуги и Cloud SQL. А възможностите на Cloud SQL в момента са ограничени. Cloud SQL поддържа висока наличност (HA) и реплика за четене (RR), но същият RR се поддържа само в един регион. След като сте създали база данни в американския регион, не можете да направите реплика за четене в европейския регион с помощта на Cloud SQL, въпреки че самият Postgres не ви пречи да направите това. Кореспонденцията със служители на Google не доведе до никъде и завърши с обещания в стил „знаем проблема и работим по него, някой ден проблемът ще бъде решен“.
Ако изброим накратко възможностите на Cloud SQL, ще изглежда по следния начин:
1. Висока наличност (HA):
- в рамките на един регион;
- чрез репликация на диск;
- Не се използват двигатели на PostgreSQL;
- възможно автоматично и ръчно управление - failover/failback;
- При превключване СУБД е недостъпна за няколко минути.
2. Прочетете реплика (RR):
- в рамките на един регион;
- горещ режим на готовност;
- Поточно репликиране на PostgreSQL.
Освен това, както е обичайно, при избора на технология винаги се сблъсквате с някои ограничения:
- клиентът не искаше да създава обекти и да използва IaaS, освен чрез GKE;
- клиентът не би искал да внедри PostgreSQL/MySQL за самообслужване;
- Е, като цяло Google Spanner би бил доста подходящ, ако не беше цената му, но Django ORM не може да работи с него, но е хубаво нещо.
Имайки предвид ситуацията, клиентът получи последващ въпрос: „Можете ли да направите нещо подобно, така че да е като Google Spanner, но да работи и с Django ORM?“
Вариант на решение № 0
Първото нещо, което ми дойде наум:
- останете в CloudSQL;
- няма да има вградена репликация между регионите под никаква форма;
- опитайте да прикачите реплика към съществуващ Cloud SQL от PostgreSQL;
- стартирайте екземпляр на PostgreSQL някъде и по някакъв начин, но поне не докосвайте master.
Уви, оказа се, че това не може да стане, защото няма достъп до хоста (съвсем в друг проект е) - pg_hba и т.н., а също така няма достъп под superuser.
Вариант на решение № 1
След по-нататъшен размисъл и като се вземат предвид предишните обстоятелства, ходът на мисли се промени донякъде:
- Все още се опитваме да останем в рамките на CloudSQL, но преминаваме към MySQL, защото Cloud SQL от MySQL има външен мастер, който:
— е прокси за външен MySQL;
- изглежда като екземпляр на MySQL;
- изобретен за мигриране на данни от други облаци или локални.
Тъй като настройката на MySQL репликация не изисква достъп до хоста, по принцип всичко работи, но беше много нестабилно и неудобно. И когато отидохме по-нататък, стана напълно страшно, защото разгърнахме цялата конструкция с тераформа и изведнъж се оказа, че външният мастер не се поддържа от тераформа. Да, Google има CLI, но по някаква причина всичко работи тук от време на време - понякога се създава, понякога не се създава. Може би защото CLI е измислен за външна миграция на данни, а не за реплики.
Всъщност в този момент стана ясно, че Cloud SQL изобщо не е подходящ. Както се казва, направихме всичко възможно.
Вариант на решение № 2
Тъй като не беше възможно да останем в рамките на Cloud SQL, ние се опитахме да формулираме изисквания за компромисно решение. Изискванията се оказаха следните:
- работа в Kubernetes, максимално използване на ресурсите и възможностите на Kubernetes (DCS, ...) и GCP (LB, ...);
- липса на баласт от куп ненужни неща в облака като HA прокси;
- възможност за стартиране на PostgreSQL или MySQL в основния HA регион; в други региони - HA от RR на основния регион плюс неговото копие (за надеждност);
- мулти майстор (не исках да се свързвам с него, но не беше много важно)
.
В резултат на тези искания, тподходящи СУБД и опции за свързване:
- MySQL Galera;
- CockroachDB;
- Инструменти на PostgreSQL
:
- pgpool-II;
— Патрони.
MySQL Galera
Технологията MySQL Galera е разработена от Codership и е плъгин за InnoDB. Особености:
- мулти мастер;
- синхронна репликация;
- четене от всеки възел;
- запис на всеки възел;
- вграден HA механизъм;
- Има диаграма на Helm от Bitnami.
Хлебарка DB
Според описанието нещото е абсолютна бомба и е проект с отворен код, написан на Go. Основният участник е Cockroach Labs (основан от хора от Google). Тази релационна СУБД първоначално е проектирана да бъде разпределена (с хоризонтално мащабиране от кутията) и устойчива на грешки. Неговите автори от компанията очертаха целта за „комбиниране на богатството на SQL функционалността с хоризонталната достъпност, позната на NoSQL решенията“.
Приятен бонус е поддръжката на протокола за връзка след преминаване.
Pgpool
Това е добавка към PostgreSQL, всъщност нов обект, който поема всички връзки и ги обработва. Има собствен балансьор на натоварването и парсер, лицензиран под BSD лиценз. Предоставя много възможности, но изглежда някак плашещо, защото присъствието на нов обект може да се превърне в източник на някои допълнителни приключения.
Патрони
Това е последното нещо, на което очите ми паднаха и, както се оказа, не напразно. Patroni е помощна програма с отворен код, която по същество е демон на Python, който ви позволява автоматично да поддържате PostgreSQL клъстери с различни видове репликация и автоматично превключване на роли. Нещото се оказа много интересно, тъй като се интегрира добре с cuber и не въвежда нови обекти.
Какво избрахте в крайна сметка?
Изборът не беше лесен:
- Хлебарка DB - огън, но тъмен;
- MySQL Galera - също не е лошо, използва се на много места, но MySQL;
- Pgpool — много ненужни обекти, толкова интеграция с облака и K8s;
- Патрони - отлична интеграция с K8s, без ненужни обекти, интегрира се добре с GCP LB.
Така изборът падна върху Patroni.
Данни
Време е да обобщим накратко. Да, светът на ИТ инфраструктурата се промени значително и това е само началото. И ако преди облаците бяха просто друг вид инфраструктура, сега всичко е различно. Освен това иновациите в облаците постоянно се появяват, те ще се появят и може би ще се появят само в облаците и едва тогава с усилията на стартиращите компании ще бъдат прехвърлени на място.
Що се отнася до SQL, SQL ще живее. Това означава, че трябва да познавате PostgreSQL и MySQL и да можете да работите с тях, но още по-важно е да можете да ги използвате правилно.
Източник: www.habr.com