Саламатсыздарбы, Хабаровск шаарынын тургундары. Курстун биринчи группасында сабактар бугун башталат . Ушуга байланыштуу бул курс боюнча ачык вебинар кандай өткөнү тууралуу айтып бермекчибиз.
В биз SQL маалымат базалары булуттардын жана Кубернеттердин доорунда туш болгон кыйынчылыктар жөнүндө сүйлөштүк. Ошол эле учурда, биз SQL маалымат базалары бул чакырыктардын таасири астында кантип ыңгайлашарын жана мутацияларын карап көрдүк.
Вебинар өткөрүлдү , EPAM системаларында Google Cloud Practice Delivery Manager.
Дарактар кичинекей болгондо...
Биринчиден, өткөн кылымдын аягында ДББны тандоо кандайча башталганын эстеп көрөлү. Бирок, бул кыйын болбойт, анткени ал мезгилде МББны тандоо башталган жана аяктаган Oracle.
90-жылдардын аягында жана 2-жылдардын башында өнөр жай масштабдуу маалымат базаларына келгенде эч кандай тандоо болгон эмес. Ооба, IBM DBXNUMX, Sybase жана башка маалымат базалары келип-кеткен, бирок жалпысынан алар Oracle фонунда анчалык байкалган эмес. Демек, ошол мезгилдеги инженерлердин көндүмдөрү кандайдыр бир жол менен болгон жалгыз тандоого байланган.
Oracle DBA төмөнкүлөрдү билиши керек:
- бөлүштүрүү комплектинен Oracle Server орнотуу;
- Oracle серверин конфигурациялоо:
- init.ora;
- listener.ora;
- түзүү:
- стол мейкиндиктери;
- схемалар;
- колдонуучулар;
— резервдик көчүрүү жана калыбына келтирүү;
- мониторинг жүргүзүү;
— оптималдуу эмес суроо-талаптар менен иштөө.
Ошол эле учурда, Oracle DBA тарабынан эч кандай өзгөчө талап болгон эмес:
- маалыматтарды сактоо жана иштетүү үчүн оптималдуу МББны же башка технологияны тандай билүү;
- жогорку жеткиликтүүлүгүн жана горизонталдуу масштабдуулугун камсыз кылуу (бул дайыма эле DBA маселеси болгон эмес);
- предметтик аймакты, инфраструктураны, колдонмо архитектурасын, ОСти жакшы билүү;
- маалыматтарды жүктөө жана түшүрүү, ар кандай DBMS ортосунда маалыматтарды көчүрүү.
Жалпысынан алганда, биз ошол күндөрдө тандоо жөнүндө айта турган болсок, анда 80-жылдардын аягында советтик дүкөндө тандоо окшош:
биздин убак
Ошондон бери, албетте, бак-дарактар өсүп, дүйнө өзгөрдү жана мындай болуп калды:
DBMS рыногу да өзгөрдү, муну Gartnerдин акыркы отчетунан айкын көрүүгө болот:
Бул жерде популярдуулугу өсүп жаткан булуттар өз ордун ээлегенин белгилей кетүү керек. Ошол эле Гартнердин отчетун окусак, төмөнкү тыянактарды көрөбүз:
- Көптөгөн кардарлар тиркемелерди булутка көчүрүү жолунда.
- Жаңы технологиялар алгач булутта пайда болот жана алар булуттуу эмес инфраструктурага эч качан көчүп кете тургандыгы чындык эмес.
- Баалоо модели көнүмүш болуп калды. Ар бир адам колдонгону үчүн гана төлөгүсү келет жана бул тенденция эмес, жөн гана факты.
Эми эмне болот?
Бүгүн биз баарыбыз булуттун ичиндебиз. Ал эми биз үчүн пайда болгон суроолор тандоо суроолору. Ал эми жергиликтүү форматта DBMS технологияларын тандоо жөнүндө гана айтсак да, бул абдан чоң. Бизде башкарылган кызматтар жана 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 баасына, сиз профессионалдарсыз!"
Мен эмне кылышым керек?
Эң акыркы чындык деп айтпастан, төмөнкүнү айталы:
Биз окууга болгон мамилебизди өзгөртүшүбүз керек:
- DBAs мурда үйрөтүлгөн жол менен окутуунун эч кандай мааниси жок;
- бир буюмдун билими жетишсиз болуп калды;
- бирок бир денгээлде ондогонду билүү мүмкүн эмес.
Сиз продукт канча экенин гана эмес, билүү керек, бирок:
- анын колдонуу учуру;
- ар кандай жайгаштыруу ыкмалары;
- ар бир ыкманын артыкчылыктары жана кемчиликтери;
- окшош жана альтернативалуу продуктылар ар дайым тааныш буюмдун пайдасына эмес, негизделген жана оптималдуу тандоо үчүн.
Сиз ошондой эле маалыматтарды көчүрө билүү жана ETL менен интеграциянын негизги принциптерин түшүнүү керек.
чыныгы окуя
Жакынкы убакта мобилдик тиркеме үчүн бэкенд түзүү керек болчу. Анын үстүндө иш башталганга чейин, бэкэнд мурунтан эле иштелип чыккан жана ишке ашырууга даяр болгон жана иштеп чыгуу тобу бул долбоорго эки жылдай убакыт короткон. Төмөнкү милдеттер коюлду:
- CI/CD түзүү;
- архитектурасын карап чыгуу;
- бардыгын ишке киргизди.
Колдонмонун өзү микросервистер болгон жана Python/Django коду нөлдөн баштап түз GCPде иштелип чыккан. Максаттуу аудиторияга келсек, анда эки аймак - АКШ жана ЕБ болот деп болжолдонгон жана трафик Global Load баланстоочу аркылуу бөлүштүрүлгөн. Бардык жумуш жүгү жана эсептөө иш жүгү Google Kubernetes Engine'де иштеди.
Маалыматтарга келсек, 3 структура болгон:
- Cloud Storage;
- Datastore;
- Cloud SQL (PostgreSQL).
Эмне үчүн Cloud SQL тандалган деген суроо пайда болушу мүмкүн? Чынын айтканда, мындай суроо акыркы жылдары кандайдыр бир ыңгайсыз паузаны жаратты - адамдар реляциялык маалымат базаларынан уялып калышты деген сезим бар, бирок ошентсе да алар аларды жигердүү колдоно беришет ;-).
Биздин ишибизге келсек, Cloud SQL төмөнкү себептерден улам тандалган:
- Жогоруда айтылгандай, тиркеме Django аркылуу иштелип чыккан жана ал SQL маалымат базасынан Python объекттерине (Django ORM) туруктуу маалыматтарды картага түшүрүү моделине ээ.
- Алкак өзү DBMS бир кыйла чектелген тизмесин колдоду:
- PostgreSQL;
- MariaDB;
- MySQL
- Oracles;
- SQLite.
Демек, PostgreSQL бул тизмеден интуитивдик түрдө тандалган (чындыгында, бул Oracle тандоо эмес).
Эмне жетишпей жатты:
- тиркеме 2 региондо гана жайгаштырылган, ал эми 3-чүсү пландарда пайда болгон (Азия);
- Маалымат базасы Түндүк Америка аймагында (Айова) жайгашкан;
- кардар тарабынан мүмкүн деген кооптонуулар болгон кирүү кечигүүлөрү Европадан жана Азиядан жана үзгүлтүктөр кызматта DBMS иштебей калган учурда.
Джангонун өзү бир нече маалымат базалары менен параллелдүү иштеп, аларды окууга жана жазууга бөлө алганына карабастан, тиркемеде анчалык көп жазуу болгон эмес (90% дан ашыгы окуйт). Жана жалпысынан жана жалпысынан, эгерде муну жасоого мүмкүн болсо Европадагы жана Азиядагы негизги базанын оку-репликасы, бул компромисстик чечим болмок. Мейли, мунун эмнеси мынчалык татаал?
Кыйынчылык кардар башкарылуучу кызматтарды жана Cloud SQLди колдонуудан баш тарткысы келбегенинде болду. Ал эми Cloud SQL мүмкүнчүлүктөрү учурда чектелген. Cloud SQL Жогорку жеткиликтүүлүктү (HA) жана Репликаны окууну (RR) колдойт, бирок ошол эле RR бир аймакта гана колдоого алынат. Америка чөлкөмүндө маалымат базасын түзүп, сиз Cloud SQL аркылуу Европа чөлкөмүндө окуу репликасын жасай албайсыз, бирок Postgres өзү буга тоскоолдук кылбайт. Google кызматкерлери менен кат алышуу эч нерсеге алып келген жок жана "биз көйгөйдү билебиз жана анын үстүндө иштеп жатабыз, качандыр бир күнү маселе чечилет" стилиндеги убадалар менен аяктаган.
Cloud SQL мүмкүнчүлүктөрүн кыскача тизмектеп көрсөк, ал төмөнкүдөй болот:
1. Жогорку жеткиликтүүлүк (HA):
- бир аймактын ичинде;
- дискти репликациялоо аркылуу;
- PostgreSQL кыймылдаткычтары колдонулбайт;
- автоматтык жана кол менен башкаруу мүмкүн - иштен чыгуу/файлбак;
- Которуу учурунда DBMS бир нече мүнөткө жеткиликсиз болот.
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
Cloud SQL алкагында калуу мүмкүн болбогондуктан, биз компромисстик чечим үчүн талаптарды иштеп чыгууга аракет кылдык. Талаптар төмөнкүдөй болуп чыкты:
- Kubernetesте иштөө, Kubernetes (DCS, ...) жана GCP (LB, ...) ресурстарын жана мүмкүнчүлүктөрүн максималдуу пайдалануу;
- HA прокси сыяктуу булуттагы керексиз нерселердин бир тобунан балласттын жоктугу;
- негизги HA аймагында PostgreSQL же MySQL иштетүү мүмкүнчүлүгү; башка региондордо - негизги региондун РР ХА плюс анын көчүрмөсү (ишенимдүүлүк үчүн);
- multi master (мен аны менен байланышкым келген жок, бирок бул өтө маанилүү эмес)
.
Бул талаптардын натыйжасында былайыктуу DBMS жана милдеттүү параметрлери:
- MySQL Galera;
- CockroachDB;
- PostgreSQL куралдары
:
- pgpool-II;
— Патрони.
MySQL Galera
MySQL Galera технологиясы Codership тарабынан иштелип чыккан жана InnoDB үчүн плагин болуп саналат. Өзгөчөлүктөрү:
- көп мастер;
- синхрондуу кайталоо;
- каалаган түйүндөн окуу;
- каалаган түйүнгө жазуу;
- орнотулган HA механизми;
- Bitnamiден Helm диаграммасы бар.
тараканDB
Сүрөттөмө боюнча, нерсе таптакыр бомба жана Go жазылган ачык булак долбоору болуп саналат. Негизги катышуучу - таракан лабораториясы (Google компаниясынын адамдары тарабынан негизделген). Бул реляциялык DBMS адегенде бөлүштүрүлүүчү (кутудан горизонталдуу масштабда) жана каталарга чыдамдуу болуп иштелип чыккан. Компаниянын авторлору "SQL функционалдуулугунун байлыгын NoSQL чечимдерине тааныш горизонталдык жеткиликтүүлүк менен айкалыштыруу" максатын белгилешкен.
Жакшы бонус - пост-гресс байланыш протоколун колдоо.
Pgpool
Бул PostgreSQL кошумчасы, чындыгында, бардык байланыштарды кабыл алган жана аларды иштеткен жаңы объект. Анын BSD лицензиясы боюнча лицензияланган өзүнүн жүк балансы жана анализдөөчүсү бар. Бул кенен мүмкүнчүлүктөрдү берет, бирок бир аз коркунучтуу көрүнөт, анткени жаңы объекттин болушу кошумча укмуштуу окуялардын булагы болуп калышы мүмкүн.
Patroni
Бул менин көзүм түшкөн эң акыркы нерсе, жана белгилүү болгондой, бекер эмес. Patroni бул ачык булак утилитасы, ал Python демону болуп саналат, ал ар кандай түрдөгү репликация жана автоматтык ролду алмаштыруу менен PostgreSQL кластерлерин автоматтык түрдө сактоого мүмкүндүк берет. Бул нерсе абдан кызыктуу болуп чыкты, анткени ал куб менен жакшы биригет жана эч кандай жаңы объекттерди киргизбейт.
Акырында эмнени тандадың?
Тандоо оңой болгон жок:
- тараканDB - от, бирок караңгы;
- MySQL Galera - ошондой эле жаман эмес, ал көп жерлерде колдонулат, бирок MySQL;
- Pgpool — көп керексиз объекттер, ошондуктан булут жана K8s менен интеграция;
- Patroni - K8s менен эң сонун интеграция, эч кандай керексиз объекттер, GCP LB менен жакшы интеграцияланат.
Ошентип, тандоо Патрониге түшкөн.
табылгалары
Кыскача жыйынтыктоого убакыт жетти. Ооба, IT инфраструктурасынын дүйнөсү олуттуу түрдө өзгөрдү жана бул башталышы гана. Ал эми мурда булут инфраструктуранын башка түрү болсо, азыр баары башкача. Анын үстүнө, булуттардагы инновациялар тынымсыз пайда болуп турат, алар пайда болот жана балким, алар булуттарда гана пайда болот жана андан кийин гана стартаптардын аракети менен алар On-premisesке өткөрүлөт.
SQLге келсек, SQL жашайт. Бул PostgreSQL жана MySQLди билишиңиз керек жана алар менен иштей билүүңүз керек дегенди билдирет, бирок андан да маанилүүсү, аларды туура колдоно билүү.
Source: www.habr.com