Сәлем, Хабаровск қаласының тұрғындары. Курстың бірінші тобында сабақ бүгін басталады . Осыған орай, осы курс бойынша ашық вебинар қалай өткені туралы айтқымыз келеді.
В біз SQL дерекқорлары бұлттар мен Кубернетес дәуірінде кездесетін қиындықтар туралы айттық. Сонымен бірге, біз SQL деректер базасының осы қиындықтардың әсерінен қалай бейімделетінін және мутацияланатынын қарастырдық.
Вебинар өткізілді , EPAM Systems компаниясында Google Cloud Practice Delivery Manager.
Ағаштар кішкентай болған кезде...
Алдымен ДҚБЖ таңдау өткен ғасырдың аяғында қалай басталғанын еске түсірейік. Дегенмен, бұл қиын болмайды, өйткені сол күндері ДҚБЖ таңдау басталып, аяқталды Oracle.
90-шы жылдардың соңы мен 2-шы жылдардың басында өнеркәсіптік масштабталатын дерекқорларға келетін болсақ, іс жүзінде таңдау болмады. Иә, IBM DBXNUMX, Sybase және басқа да деректер базалары келіп-кететін болды, бірақ олар Oracle фонында онша байқалмады. Тиісінше, сол кездегі инженерлердің дағдылары қандай да бір түрде бар жалғыз таңдауға байланысты болды.
Oracle DBA мыналарды білуі керек:
- тарату жинағынан Oracle серверін орнату;
- Oracle серверін конфигурациялау:
- init.ora;
- listener.ora;
- құру:
- кесте кеңістігі;
- Схемалар
- пайдаланушылар;
— сақтық көшірме жасау және қалпына келтіру;
— мониторинг жүргізу;
— оңтайлы емес сұраныстармен айналысу.
Сонымен қатар, Oracle DBA-дан арнайы талап болған жоқ:
- мәліметтерді сақтау мен өңдеудің оңтайлы МҚБЖ немесе басқа технологияны таңдай білу;
- жоғары қолжетімділікті және көлденең ауқымдылықты қамтамасыз ету (бұл әрқашан DBA мәселесі емес);
- пәндік облысты, инфрақұрылымды, қолданбалы архитектураны, ОЖ-ны жақсы білу;
- деректерді жүктеу және түсіру, әртүрлі ДҚБЖ арасында деректерді тасымалдау.
Жалпы, сол күндердегі таңдау туралы айтатын болсақ, ол 80-жылдардың аяғындағы кеңестік дүкендегі таңдауға ұқсайды:
Біздің уақытымыз
Содан бері, әрине, ағаштар өсті, әлем өзгерді және келесідей болды:
ДҚБЖ нарығы да өзгерді, мұны Gartner компаниясының соңғы есебінен анық көруге болады:
Бұл жерде танымалдығы артып келе жатқан бұлттардың өз орнын алғанын атап өткен жөн. Егер сол Gartner есебін оқысақ, келесі қорытындыларды көреміз:
- Көптеген тұтынушылар қолданбаларды бұлтқа көшіру жолында.
- Жаңа технологиялар алдымен бұлтта пайда болады және олардың бұлтты емес инфрақұрылымға көшетіні шындық емес.
- «Қолданған сайын төле» баға моделі үйреншікті жағдайға айналды. Әркім тек қолданатын нәрсесі үшін төлегісі келеді, бұл тіпті тренд емес, жай ғана факт.
Қазір не?
Бүгін бәріміз бұлттың ішіндеміз. Ал біз үшін туындайтын сұрақтар – таңдау сұрақтары. Жергілікті форматта ДҚБЖ технологияларын таңдау туралы ғана айтатын болсақ, бұл өте үлкен. Бізде басқарылатын қызметтер мен SaaS бар. Осылайша, таңдау тек жыл сайын қиындай түседі.
Таңдау сұрақтарымен қатар, сондай-ақ бар шектейтін факторлар:
- баға. Көптеген технологиялар әлі де ақша талап етеді;
- дағдылар. Егер біз еркін бағдарламалық қамтамасыз ету туралы айтатын болсақ, онда дағдылар туралы сұрақ туындайды, өйткені еркін бағдарламалық қамтамасыз ету оны енгізетін және басқаратын адамдардан жеткілікті құзыретті талап етеді;
- функционалды. Бұлтта қол жетімді және, айталық, тіпті бір Postgres-те салынған барлық қызметтер Postgres On-premises сияқты мүмкіндіктерге ие емес. Бұл білу және түсіну қажет маңызды фактор. Сонымен қатар, бұл фактор бір ДҚБЖ кейбір жасырын мүмкіндіктерін білуге қарағанда маңыздырақ болады.
Қазір DA/DE-ден не күтіледі:
- пәндік аймақты және қолданба архитектурасын жақсы түсіну;
- берілген тапсырманы ескере отырып, сәйкес ДҚБЖ технологиясын дұрыс таңдай білу;
- бар шектеулер жағдайында таңдалған технологияны жүзеге асырудың оңтайлы әдісін таңдау мүмкіндігі;
- деректерді тасымалдау мен көшіруді орындау мүмкіндігі;
- таңдалған шешімдерді енгізу және пайдалану мүмкіндігі.
Төмендегі мысал GCP негізінде деректермен жұмыс істеу үшін сол немесе басқа технологияны таңдау оның құрылымына байланысты қалай жұмыс істейтінін көрсетеді:
PostgreSQL схемаға қосылмағанын ескеріңіз және бұл терминологияның астында жасырылғандықтан. Бұлтты SQL. Cloud SQL-ге жеткенде, біз қайтадан таңдау жасауымыз керек:
Айта кету керек, бұл таңдау әрқашан анық емес, сондықтан қолданбаларды әзірлеушілер көбінесе интуицияны басшылыққа алады.
Барлығы:
- Неғұрлым сіз ары қарай жүрсеңіз, таңдау мәселесі соғұрлым өзекті болады. Егер сіз тек GCP, басқарылатын қызметтер мен SaaS-ті қарасаңыз да, RDBMS туралы кейбір ескертулер тек 4-ші қадамда пайда болады (және ол жерде Spanner жақын жерде). Сонымен қатар, PostgreSQL таңдауы 5-ші қадамда пайда болады және оның жанында MySQL және SQL сервері бар, яғни бәрі көп, бірақ таңдау керек.
- Біз азғырулар фонындағы шектеулер туралы ұмытпауымыз керек. Негізінде барлығы кілтті қалайды, бірақ ол қымбат. Нәтижесінде әдеттегі сұрау келесідей болады: «Бізге Spanner жасаңыз, бірақ Cloud SQL бағасына сіз кәсіби мамандарсыз!»
Біз не істеуіміз керек?
Түпкі шындық деп айтпай, мынаны айтайық:
Біз оқуға деген көзқарасымызды өзгертуіміз керек:
- бұрын DBA оқытылатын әдісті оқытудың мағынасы жоқ;
- бір өнімді білу енді жеткіліксіз;
- бірақ бір деңгейде ондаған білу мүмкін емес.
Сіз өнімнің қанша екенін ғана емес, білуіңіз керек, бірақ:
- оны қолданудың пайдалану жағдайы;
- әр түрлі орналастыру әдістері;
- әрбір әдістің артықшылықтары мен кемшіліктері;
- әрқашан таныс өнімнің пайдасына емес, негізделген және оңтайлы таңдау жасау үшін ұқсас және балама өнімдер.
Сондай-ақ деректерді тасымалдау және ETL-мен интеграцияның негізгі принциптерін түсіну мүмкіндігі болуы керек.
нақты жағдай
Жақында мобильді қосымша үшін бэкенд жасау қажет болды. Онымен жұмыс басталған кезде бэкэнд әзірленіп, іске асыруға дайын болды, ал әзірлеушілер тобы бұл жобаға екі жылдай уақыт жұмсады. Келесі міндеттер қойылды:
- CI/CD құрастыру;
- архитектураны қарау;
- барлығын іске қосу.
Қолданбаның өзі микросервистер болды және Python/Django коды нөлден және тікелей GCP-де әзірленді. Мақсатты аудиторияға келетін болсақ, екі аймақ - АҚШ және ЕО болады деп болжанған және трафик Global Load балансизаторы арқылы таратылған. Барлық жұмыс жүктемелері мен есептеу жұмыс жүктемесі Google Kubernetes Engine жүйесінде орындалды.
Деректерге келетін болсақ, 3 құрылым болды:
- Бұлтты сақтау;
- Деректер қоймасы;
- Бұлтты SQL (PostgreSQL).
Неліктен Cloud SQL таңдалды деген сұрақ туындауы мүмкін. Шынымды айтсам, мұндай сұрақ соңғы жылдары қандай да бір ыңғайсыз үзіліс тудырды - адамдар реляциялық дерекқордан ұялып кетті деген сезім бар, бірақ соған қарамастан олар оларды белсенді түрде пайдалануды жалғастыруда ;-).
Біздің жағдайымызға келетін болсақ, Cloud SQL келесі себептерге байланысты таңдалды:
- Жоғарыда айтылғандай, қолданба Django көмегімен жасалған және оның SQL дерекқорынан Python нысандарына (Django ORM) тұрақты деректерді салыстыру үлгісі бар.
- Фреймворктың өзі ДҚБЖ-ның өте шектеулі тізімін қолдады:
- PostgreSQL;
- MariaDB;
- MySQL
- оракулдар;
- SQLite.
Тиісінше, PostgreSQL бұл тізімнен интуитивті түрде таңдалды (жақсы, Oracle таңдауы мүмкін емес).
Не жетіспеді:
- қосымша тек 2 аймақта ғана орналастырылды, ал 3-ші жоспарда (Азия) пайда болды;
- Деректер базасы Солтүстік Америка аймағында (Айова штаты) орналасқан;
- Тапсырыс беруші тарапынан мүмкін деген алаңдаушылық болды қол жеткізу кідірістері Еуропа мен Азиядан және үзілістер қызметте ДҚБЖ тоқтап қалған жағдайда.
Джангоның өзі бірнеше мәліметтер базасымен қатар жұмыс істей алатынына және оларды оқу мен жазуға бөле алатынына қарамастан, қосымшада жазу соншалықты көп болмады (90% -дан астамы оқиды). Және жалпы және жалпы, егер бұл мүмкін болса Еуропа мен Азиядағы негізгі базаның оқу-көшірмесі, бұл компромисстік шешім болар еді. Ал, оның несі күрделі?
Қиындық тұтынушының басқарылатын қызметтер мен Cloud SQL пайдаланудан бас тартқысы келмеуі болды. Ал Cloud SQL мүмкіндіктері қазіргі уақытта шектеулі. Cloud SQL жоғары қолжетімділік (HA) және Оқу репликасын (RR) қолдайды, бірақ бірдей RR бір аймақта ғана қолдау көрсетеді. Американдық аймақта дерекқорды жасағаннан кейін, сіз Cloud SQL арқылы Еуропа аймағында оқу репликасын жасай алмайсыз, дегенмен Postgres өзі мұны істеуге кедергі жасамайды. Google қызметкерлерімен хат алмасу еш нәтиже бермеді және «біз мәселені білеміз және онымен жұмыс істеп жатырмыз, бір күні мәселе шешіледі» стиліндегі уәделермен аяқталды.
Cloud SQL мүмкіндіктерін қысқаша тізімдейтін болсақ, ол келесідей болады:
1. Жоғары қолжетімділік (HA):
- бір аймақта;
- дискіні репликациялау арқылы;
- PostgreSQL қозғалтқыштары пайдаланылмайды;
- автоматты және қолмен басқару мүмкін - ауыстырып қосу/қайта қалпына келтіру;
- Ауыстыру кезінде ДҚБЖ бірнеше минут бойы қолжетімсіз болады.
2. Репликаны оқу (RR):
- бір аймақта;
- ыстық күту режимі;
- PostgreSQL ағынды репликациясы.
Сонымен қатар, әдеттегідей, технологияны таңдаған кезде сіз әрқашан кейбірімен бетпе-бет келесіз шектеулер:
- тұтынушы GKE арқылы басқа нысандарды құруды және IaaS пайдаланғысы келмеді;
- тұтынушы PostgreSQL/MySQL өзіне-өзі қызмет көрсетуді пайдаланғысы келмейді;
- Жалпы, Google Spanner оның бағасы болмаса өте қолайлы болар еді, дегенмен Django ORM онымен жұмыс істей алмайды, бірақ бұл жақсы нәрсе.
Жағдайды ескере отырып, тұтынушы келесі сұрақты алды: «Сіз Google Spanner сияқты, бірақ Django ORM-мен де жұмыс істейтіндей бірдеңе жасай аласыз ба?»
Шешім нұсқасы № 0
Бірінші ойға келгені:
- CloudSQL ішінде болу;
- кез келген нысанда аймақтар арасында кірістірілген репликация болмайды;
- репликаны PostgreSQL арқылы бар Cloud SQL-ге тіркеп көріңіз;
- PostgreSQL данасын бір жерде және қандай да бір жолмен іске қосыңыз, бірақ кем дегенде шеберді ұстамаңыз.
Өкінішке орай, мұны істеу мүмкін емес екені белгілі болды, өйткені хостқа кіру мүмкіндігі жоқ (ол мүлде басқа жобада) - pg_hba және т.б., сонымен қатар суперпайдаланушыға кіру мүмкіндігі жоқ.
Шешім нұсқасы № 1
Әрі қарай ой елегінен өткізгеннен кейін және алдыңғы жағдайларды ескере отырып, ойлар тізбегі біршама өзгерді:
- Біз әлі де CloudSQL ішінде қалуға тырысамыз, бірақ MySQL-ге ауысамыз, өйткені MySQL арқылы Cloud SQL-де сыртқы шебері бар, ол:
— сыртқы MySQL үшін прокси болып табылады;
- MySQL данасына ұқсайды;
- басқа бұлттардан немесе жергілікті жерден деректерді тасымалдау үшін ойлап табылған.
MySQL репликациясын орнату хостқа кіруді қажет етпейтіндіктен, негізінен бәрі жұмыс істеді, бірақ ол өте тұрақсыз және ыңғайсыз болды. Әрі қарай кеткенде, бұл мүлдем қорқынышты болды, өйткені біз бүкіл құрылымды терраформмен орналастырдық, кенеттен сыртқы шеберге терраформ қолдау көрсетпейді. Иә, Google-де CLI бар, бірақ қандай да бір себептермен мұнда бәрі мезгіл-мезгіл жұмыс істеді - кейде ол жасалады, кейде ол жасалмады. Мүмкін, CLI көшірмелер үшін емес, сыртқы деректерді тасымалдау үшін ойлап табылған.
Шындығында, бұл кезде Cloud SQL мүлдем жарамсыз екені белгілі болды. Олар айтқандай, біз қолдан келгеннің бәрін жасадық.
Шешім нұсқасы № 2
Бұлтты SQL шеңберінде қалу мүмкін болмағандықтан, біз компромисстік шешімге қойылатын талаптарды тұжырымдауға тырыстық. Талаптар келесідей болып шықты:
- Kubernetes-те жұмыс, Kubernetes (DCS, ...) және GCP (LB, ...) ресурстары мен мүмкіндіктерін барынша пайдалану;
- HA проксиі сияқты бұлттағы қажетсіз нәрселерден балласттың болмауы;
- негізгі HA аймағында PostgreSQL немесе MySQL іске қосу мүмкіндігі; басқа аймақтарда - негізгі аймақтың РР ХА плюс оның көшірмесі (сенімділік үшін);
- мульти мастер (Мен онымен байланысқым келмеді, бірақ бұл өте маңызды емес еді)
.
Осы талаптардың нәтижесінде бқолайлы ДҚБЖ және байланыстыру опциялары:
- MySQL Galera;
- CockroachDB;
- PostgreSQL құралдары
:
- pgpool-II;
- Патрони.
MySQL Galera
MySQL Galera технологиясы Codership әзірлеген және InnoDB үшін плагин болып табылады. Ерекшеліктер:
- көп мастер;
- синхронды репликация;
- кез келген түйіннен оқу;
- кез келген түйінге жазу;
- кірістірілген HA механизмі;
- Bitnami-ден Helm диаграммасы бар.
ТарақанDB
Сипаттамаға сәйкес, бұл зат мүлдем бомба және Go бағдарламасында жазылған ашық бастапқы жоба. Негізгі қатысушы – тарақан зертханалары (Google компаниясының адамдары негізін қалаған). Бұл реляциялық ДҚБЖ бастапқыда таратуға (қораптан тыс көлденең масштабтаумен) және ақауларға төзімділікпен жасалған. Оның компаниядағы авторлары «SQL функционалдығының байлығын NoSQL шешімдеріне таныс көлденең қол жетімділікпен біріктіру» мақсатын белгіледі.
Жақсы бонус - пост-гресс қосылым протоколын қолдау.
Пгпул
Бұл PostgreSQL қосымшасы, шын мәнінде, барлық қосылымдарды қабылдайтын және оларды өңдейтін жаңа нысан. Оның BSD лицензиясы бойынша лицензияланған жеке жүктеме теңестірушісі және талдаушысы бар. Бұл кең мүмкіндіктер береді, бірақ біршама қорқынышты көрінеді, өйткені жаңа ұйымның болуы кейбір қосымша шытырмандардың көзі болуы мүмкін.
Патрони
Бұл менің көзіме түскен ең соңғы нәрсе, және белгілі болғандай, бекер емес. Patroni – бұл Python демоны болып табылатын ашық бастапқы қызметтік бағдарлама, ол PostgreSQL кластерлерін репликацияның әртүрлі түрлерімен және автоматты рөлдерді ауыстырумен автоматты түрде қолдауға мүмкіндік береді. Бұл өте қызықты болды, өйткені ол кубпен жақсы үйлеседі және ешқандай жаңа нысандарды енгізбейді.
Соңында не таңдадыңыз?
Таңдау оңай болған жоқ:
- ТарақанDB - от, бірақ қараңғы;
- MySQL Galera - сонымен қатар жаман емес, ол көп жерде қолданылады, бірақ MySQL;
- Пгпул — көптеген қажетсіз нысандар, сондықтан бұлтпен және K8s интеграциясы;
- Патрони - K8s-мен тамаша интеграция, қажетсіз нысандар жоқ, GCP LB-мен жақсы интеграцияланады.
Осылайша таңдау Патрониге түсті.
қорытындылар
Қысқаша қорытындылайтын кез келді. Иә, IT-инфрақұрылым әлемі айтарлықтай өзгерді және бұл бастамасы ғана. Ал егер бұрын бұлттар инфрақұрылымның басқа түрі болса, қазір бәрі басқаша. Сонымен қатар, бұлттағы инновациялар үнемі пайда болады, олар пайда болады және мүмкін олар тек бұлттарда пайда болады, содан кейін ғана стартаптардың күшімен олар жергілікті жерге ауыстырылады.
SQL-ге келетін болсақ, SQL өмір сүреді. Бұл PostgreSQL және MySQL-ті білу және олармен жұмыс істей білу керек дегенді білдіреді, бірақ одан да маңыздырақ оларды дұрыс пайдалана білу.
Ақпарат көзі: www.habr.com