Сайн байна уу, Хабаровскийн оршин суугчид. Тус курсын нэгдүгээр бүлгийн хичээл өнөөдрөөс эхэлж байна . Үүнтэй холбогдуулан энэхүү хичээлийн нээлттэй вебинар хэрхэн явагдсан талаар танд хүргэж байна.
В Бид үүл болон Кубернетын эрин үед SQL мэдээллийн санд тулгарч буй бэрхшээлүүдийн талаар ярилцлаа. Үүний зэрэгцээ, бид эдгээр сорилтуудын нөлөөн дор SQL мэдээллийн сан хэрхэн дасан зохицож, мутацид ордогийг авч үзсэн.
Вебинар боллоо , EPAM Systems дахь Google Клоуд Практик хүргэлтийн менежер.
Мод жижиг байхад...
Нэгдүгээрт, өнгөрсөн зууны сүүлчээр DBMS-ийн сонголт хэрхэн эхэлснийг санацгаая. Гэсэн хэдий ч энэ нь тийм ч хэцүү биш байх болно, учир нь тэр үед DBMS-ийн сонголт эхэлж, дууссан Oracle-ийн.
90-ээд оны сүүл, 2-аад оны эхэн үед үйлдвэрлэлийн өргөтгөх боломжтой мэдээллийн сангийн тухайд үндсэндээ ямар ч сонголт байгаагүй. Тийм ээ, IBM DBXNUMX, Sybase болон бусад мэдээллийн сангууд ирж, явсан боловч ерөнхийдөө Oracle-ийн дэвсгэр дээр тийм ч мэдэгдэхүйц биш байв. Үүний дагуу тухайн үеийн инженерүүдийн ур чадвар одоо байгаа цорын ганц сонголттой ямар нэгэн байдлаар холбоотой байв.
Oracle DBA нь дараахь зүйлийг хийх чадвартай байх ёстой.
- түгээлтийн багцаас Oracle серверийг суулгах;
- Oracle серверийг тохируулах:
- init.ora;
- listener.ora;
- үүсгэх:
- хүснэгтийн зай;
- схем;
- хэрэглэгчид;
- нөөцлөх, сэргээх;
- хяналт тавих;
- оновчтой бус хүсэлтийг шийдвэрлэх.
Үүний зэрэгцээ Oracle DBA-аас тусгай шаардлага байгаагүй:
- өгөгдөл хадгалах, боловсруулах оновчтой DBMS эсвэл бусад технологийг сонгох чадвартай байх;
- өндөр хүртээмжтэй, хэвтээ өргөтгөх чадварыг хангах (энэ нь үргэлж DBA асуудал биш байсан);
- сэдэв, дэд бүтэц, хэрэглээний архитектур, үйлдлийн системийн талаар сайн мэдлэгтэй;
- өгөгдлийг ачаалах, буулгах, өөр өөр DBMS хооронд өгөгдөл шилжүүлэх.
Ерөнхийдөө хэрэв бид тухайн үеийн сонголтын талаар ярих юм бол 80-аад оны сүүлчээр Зөвлөлтийн дэлгүүрийн сонголттой төстэй юм.
Бидний цаг
Түүнээс хойш мэдээж мод ургаж, дэлхий өөрчлөгдөж, ийм зүйл болсон.
DBMS зах зээл мөн өөрчлөгдсөнийг Gartner-ийн хамгийн сүүлийн тайлангаас тодорхой харж болно.
Нэр хүнд нь өсөн нэмэгдэж буй үүлнүүд өөрсдийн байр сууриа эзэлснийг энд тэмдэглэх нь зүйтэй. Хэрэв бид ижил Gartner тайланг уншвал дараахь дүгнэлтийг харах болно.
- Олон хэрэглэгчид програмуудыг үүлэн рүү шилжүүлэх зам дээр байна.
- Шинэ технологиуд анх үүлэн дээр гарч ирдэг бөгөөд тэд хэзээ ч үүлэн бус дэд бүтэц рүү шилжих нь үнэн биш юм.
- Төлбөрөө төлдөг үнэ тогтоох загвар түгээмэл болсон. Хүн бүр зөвхөн ашигладаг зүйлийнхээ төлөө мөнгө төлөхийг хүсдэг бөгөөд энэ нь чиг хандлага биш, харин зүгээр л бодит байдлын мэдэгдэл юм.
Одоо яах вэ?
Өнөөдөр бид бүгд үүлэн дотор байна. Мөн бидний өмнө гарч буй асуултууд нь сонголтын асуултууд юм. Бид зөвхөн DBMS технологиудыг on-premises форматаар сонгох тухай ярьж байгаа ч гэсэн энэ нь асар том юм. Бид бас удирддаг үйлчилгээ болон SaaS-тай. Тиймээс сонголт нь жил бүр улам хэцүү болж байна.
Сонголттой холбоотой асуултуудаас гадна бас байдаг хязгаарлах хүчин зүйлүүд:
- үнэ. Олон технологи нь мөнгөтэй хэвээр байна;
- ур чадвар. Хэрэв бид үнэгүй програм хангамжийн тухай ярьж байгаа бол үнэгүй програм хангамж нь түүнийг байрлуулж, ажиллуулж буй хүмүүсээс хангалттай ур чадвар шаарддаг тул ур чадварын тухай асуулт гарч ирнэ;
- функциональ. Клоуд дээр байдаг, нэг Postgres дээр бүтээгдсэн бүх үйлчилгээ нь Postgres On-premises-тэй ижил шинж чанартай байдаггүй. Энэ бол мэдэж, ойлгох шаардлагатай чухал хүчин зүйл юм. Түүнээс гадна энэ хүчин зүйл нь нэг DBMS-ийн зарим далд чадамжийн талаарх мэдлэгээс илүү чухал болж байна.
Одоо DA/DE-ээс юу хүлээж байна вэ:
- сэдвийн талбар болон хэрэглээний архитектурын талаар сайн ойлголттой байх;
- даалгаврыг харгалзан зохих DBMS технологийг зөв сонгох чадвар;
- одоо байгаа хязгаарлалтын нөхцөлд сонгосон технологийг хэрэгжүүлэх оновчтой аргыг сонгох чадвар;
- өгөгдөл дамжуулах, шилжүүлэх чадвар;
- сонгосон шийдлүүдийг хэрэгжүүлэх, ажиллуулах чадвар.
Доорх жишээ GCP дээр суурилсан Өгөгдөлтэй ажиллах нэг буюу өөр технологийг сонгох нь түүний бүтцээс хамааран хэрхэн ажилладагийг харуулж байна.
PostgreSQL нь схемд ороогүй бөгөөд энэ нь нэр томъёоны дор нуугдаж байгааг анхаарна уу. Cloud SQL. Cloud SQL-д орохдоо бид дахин сонголт хийх хэрэгтэй болно:
Энэ сонголт үргэлж тодорхой байдаггүй тул програм хөгжүүлэгчид ихэвчлэн зөн совингоор удирддаг гэдгийг тэмдэглэх нь зүйтэй.
Нийт:
- Та цааш явах тусам сонголтын асуудал улам хурцдах болно. Хэрэв та зөвхөн GCP, удирддаг үйлчилгээ, SaaS-ийг харвал RDBMS-ийн тухай зарим нэг дурдагдсан зүйл зөвхөн 4-р алхам дээр гарч ирнэ (мөн тэнд Spanner ойрхон байна). Нэмж дурдахад PostgreSQL-ийн сонголт 5-р алхам дээр гарч ирэх бөгөөд түүний хажууд MySQL болон SQL Server байдаг. бүх зүйл маш их байдаг, гэхдээ та сонгох хэрэгтэй.
- Бид уруу таталтын арын эсрэг хязгаарлалтыг мартаж болохгүй. Үндсэндээ хүн бүр Түлхүүр авахыг хүсдэг ч үнэтэй байдаг. Үүний үр дүнд ердийн хүсэлт дараах байдалтай байна. "Бидэнд түлхүүр үүсгэнэ үү, гэхдээ Cloud SQL-ийн үнээр та мэргэжлийн хүмүүс юм!"
Би юу хийх хэрэгтэй вэ?
Өөрийгөө туйлын үнэн гэж хэлэхгүйгээр дараахь зүйлийг хэлье.
Бид суралцах арга барилаа өөрчлөх хэрэгтэй:
- Өмнө нь DBA-г заадаг байсан арга барилыг заах нь утгагүй;
- нэг бүтээгдэхүүний талаархи мэдлэг хангалтгүй болсон;
- гэхдээ нэг түвшинд олон арван мэдэх боломжгүй юм.
Та зөвхөн бүтээгдэхүүн хэр их байгааг мэдэх биш, харин:
- түүний хэрэглээний тохиолдол;
- янз бүрийн байршуулах арга;
- арга тус бүрийн давуу болон сул талууд;
- ижил төстэй болон өөр бүтээгдэхүүнүүд нь мэдээлэлтэй, оновчтой сонголт хийх бөгөөд танил бүтээгдэхүүнийг үргэлж дэмждэггүй.
Та мөн өгөгдлийг шилжүүлж, ETL-тэй нэгтгэх үндсэн зарчмуудыг ойлгох чадвартай байх хэрэгтэй.
Бодит хэрэг
Ойрын үед гар утасны програмын backend үүсгэх шаардлагатай болсон. Үүн дээр ажиллаж эхлэх үед арын хэсгийг аль хэдийн боловсруулж, хэрэгжүүлэхэд бэлэн болсон бөгөөд хөгжүүлэлтийн баг энэ төсөлд хоёр жил орчим зарцуулсан. Дараах ажлуудыг тавьсан.
- CI/CD бүтээх;
- архитектурыг хянах;
- бүгдийг нь ашиглалтад оруулна.
Уг програм нь өөрөө микро үйлчилгээ байсан бөгөөд Python/Django кодыг эхнээс нь, шууд GCP дээр боловсруулсан. Зорилтот үзэгчдийн хувьд АНУ, ЕХ гэсэн хоёр бүс байх болно гэж таамаглаж байсан бөгөөд урсгалыг Global Load тэнцвэржүүлэгчээр дамжуулан хуваарилсан. Бүх ажлын ачаалал болон тооцооллын ачааллыг Google Kubernetes Engine дээр ажиллуулсан.
Мэдээллийн хувьд 3 бүтэцтэй байсан:
- Үүл хадгалах;
- Мэдээллийн сан;
- Cloud SQL (PostgreSQL).
Яагаад Cloud SQL-г сонгосон юм бол гэж гайхаж магадгүй юм. Үнэнийг хэлэхэд, ийм асуулт сүүлийн жилүүдэд зарим нэг эвгүй түр зогсолтыг үүсгэсэн - хүмүүс харилцааны мэдээллийн сангаас ичимхий болсон гэсэн мэдрэмж байдаг ч тэд үүнийг идэвхтэй ашигласаар байна ;-).
Бидний хувьд Cloud SQL-ийг дараах шалтгааны улмаас сонгосон.
- Өмнө дурьдсанчлан уг программыг Django ашиглан боловсруулсан бөгөөд SQL мэдээллийн сангаас Python объектууд (Django ORM) руу тогтмол өгөгдлийг буулгах загвартай.
- Энэхүү хүрээ нь өөрөө DBMS-ийн нэлээд хязгаарлагдмал жагсаалтыг дэмждэг:
- PostgreSQL;
- MariaDB;
- MySQL;
- oracles;
- SQLite.
Үүний дагуу PostgreSQL-ийг энэ жагсаалтаас зөн совингоор сонгосон (үнэхээр Oracle сонгох боломжгүй).
Юу дутагдаж байсан:
- програмыг зөвхөн 2 бүс нутагт байрлуулсан бөгөөд 3 дахь нь төлөвлөгөөнд (Ази) гарч ирэв;
- Мэдээллийн сан нь Хойд Америкийн бүс нутагт (Айова) байрладаг;
- Үйлчлүүлэгчийн зүгээс боломжийн талаар санаа зовж байсан хандалтын саатал Европ, Азиас болон тасалдал үйлчилгээнд DBMS сул зогсолтын үед.
Хэдийгээр Django өөрөө хэд хэдэн өгөгдлийн сантай зэрэгцэн ажиллаж, тэдгээрийг унших, бичихэд хувааж чаддаг ч програмд тийм ч их бичээгүй (90 гаруй хувь нь уншиж байна). Тэгээд ерөнхийдөө, ерөнхийд нь, хэрэв үүнийг хийх боломжтой байсан бол Европ, Ази дахь үндсэн баазыг уншсан хуулбар, энэ нь буулт хийх шийдэл байх болно. За, энэ юунд тийм төвөгтэй байдаг вэ?
Хэцүү тал нь үйлчлүүлэгч удирдлагатай үйлчилгээ болон Cloud SQL-г ашиглахаас татгалзахыг хүсээгүй явдал байв. Мөн Cloud SQL-ийн боломжууд одоогоор хязгаарлагдмал байна. Cloud SQL нь өндөр хүртээмжтэй (HA) болон Read Replica (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-ийн Cloud SQL нь гадаад мастертай тул MySQL рүү шилжиж байна.
— гадаад MySQL-ийн прокси;
- MySQL жишээ шиг харагдаж байна;
- бусад үүл эсвэл газар дээрх өгөгдлийг шилжүүлэх зорилгоор зохион бүтээсэн.
MySQL хуулбарыг тохируулах нь хост руу хандах шаардлагагүй тул зарчмын хувьд бүх зүйл ажилласан боловч энэ нь маш тогтворгүй, тохиромжгүй байсан. Тэгээд цааш явахад бид бүхэл бүтэн бүтцийг terraform-аар байрлуулсан тул гэнэт гадны мастер терраформоор дэмжигдээгүй болох нь үнэхээр аймшигтай болсон. Тийм ээ, Google-д CLI байдаг, гэхдээ ямар нэг шалтгааны улмаас энд бүх зүйл хааяа ажиллаж байсан - заримдаа үүнийг үүсгэсэн, заримдаа үүнийг үүсгэдэггүй. Магадгүй CLI-г хуулбарлахын тулд бус харин гадны өгөгдөл шилжүүлэх зорилгоор зохион бүтээсэн байж магадгүй юм.
Үнэндээ энэ үед Cloud SQL нь огт тохирохгүй нь тодорхой болсон. Тэдний хэлснээр бид чадах бүхнээ хийсэн.
Шийдлийн сонголт № 2
Cloud SQL-ийн хүрээнд үлдэх боломжгүй байсан тул бид буулт хийх шийдлийн шаардлагыг томъёолохыг хичээсэн. Шаардлагууд нь дараах байдалтай болсон.
- Kubernetes-д ажиллах, Kubernetes (DCS, ...) болон GCP (LB, ...)-ийн нөөц, чадавхийг дээд зэргээр ашиглах;
- HA прокси гэх мэт үүлэн доторх шаардлагагүй зүйлсээс тогтворжуулагч дутагдалтай;
- үндсэн HA бүсэд PostgreSQL эсвэл MySQL ажиллуулах чадвар; бусад бүс нутагт - үндсэн бүсийн RR-ийн HA, түүний хуулбар (найдвартай байдлын үүднээс);
- олон мастер (би түүнтэй холбоо барихыг хүсээгүй, гэхдээ энэ нь тийм ч чухал биш байсан)
.
Эдгээр шаардлагын үр дүнд хтохиромжтой DBMS болон холбох сонголтууд:
- MySQL Галера;
- жоомDB;
- PostgreSQL хэрэгслүүд
:
- pgpool-II;
- Патрони.
MySQL Галера
MySQL Galera технологийг Codership боловсруулсан бөгөөд InnoDB-д зориулсан залгаас юм. Онцлог:
- олон мастер;
- синхрон хуулбар;
- дурын зангилаанаас унших;
- дурын зангилаа руу бичлэг хийх;
- суурилуулсан HA механизм;
- Bitnami-аас Helm график байдаг.
Жоом
Тодорхойлолтоор бол энэ зүйл үнэхээр тэсрэх бөмбөг бөгөөд Go дээр бичигдсэн нээлттэй эхийн төсөл юм. Гол оролцогч нь Cockroach Labs (Google-ийн хүмүүс үүсгэн байгуулсан) юм. Энэхүү харилцааны DBMS нь анх түгээх (хайрцагнаас хэвтээ масштабтай) бөгөөд алдааг тэсвэрлэх чадвартай байхаар бүтээгдсэн. Тус компанийн зохиогчид "SQL функцийн баялагийг NoSQL шийдлүүдэд танил болсон хэвтээ хүртээмжтэй хослуулах" зорилгыг тодорхойлсон.
Сайхан урамшуулал бол конгрессийн дараах холболтын протоколыг дэмжих явдал юм.
Пгпул
Энэ бол PostgreSQL-ийн нэмэлт бөгөөд үнэн хэрэгтээ бүх холболтыг авч, тэдгээрийг боловсруулдаг шинэ байгууллага юм. Энэ нь BSD лицензийн дагуу лицензлэгдсэн өөрийн ачаалал тэнцвэржүүлэгч, задлагчтай. Энэ нь маш их боломжийг олгодог боловч зарим талаараа аймшигтай харагдаж байна, учир нь шинэ байгууллага байгаа нь нэмэлт адал явдлын эх үүсвэр болж магадгүй юм.
Патрони
Энэ бол миний нүдэнд хамгийн сүүлд унасан зүйл бөгөөд энэ нь дэмий хоосон биш юм. Patroni нь нээлттэй эхийн хэрэгсэл бөгөөд үндсэндээ Python демон бөгөөд PostgreSQL кластеруудыг янз бүрийн хуулбарлах, автоматаар дүрд шилжүүлэх боломжийг олгодог. Энэ нь кубтай сайн уялдаж, ямар ч шинэ байгууллагыг нэвтрүүлдэггүй тул энэ зүйл маш сонирхолтой болсон.
Та эцэст нь юу сонгосон бэ?
Сонголт нь амаргүй байсан:
- Жоом - гал, гэхдээ харанхуй;
- MySQL Галера - бас муу биш, үүнийг олон газар ашигладаг, гэхдээ MySQL;
- Пгпул - маш олон шаардлагагүй байгууллагууд, тиймээс үүлэн болон K8-тай нэгтгэх;
- Патрони - K8s-тэй маш сайн интеграцчилал, шаардлагагүй нэгж байхгүй, GCP LB-тэй сайн нэгдсэн.
Тиймээс сонголт нь Патронид унав.
үр дүн нь
Товчхон дүгнэх цаг болжээ. Тийм ээ, мэдээллийн технологийн дэд бүтцийн ертөнц ихээхэн өөрчлөгдсөн бөгөөд энэ бол зөвхөн эхлэл юм. Хэрэв өмнө нь үүл нь өөр төрлийн дэд бүтэц байсан бол одоо бүх зүйл өөр болжээ. Түүгээр ч барахгүй үүлэн доторх инноваци байнга гарч ирдэг, тэдгээр нь гарч ирэх бөгөөд магадгүй тэд зөвхөн үүлэн дээр гарч ирэх бөгөөд зөвхөн дараа нь стартапуудын хүчин чармайлтаар тэдгээрийг газар дээр нь шилжүүлэх болно.
SQL-ийн хувьд SQL амьдрах болно. Энэ нь та PostgreSQL болон MySQL-ийг мэддэг, тэдэнтэй ажиллах чадвартай байх хэрэгтэй гэсэн үг боловч тэдгээрийг зөв ашиглах нь илүү чухал юм.
Эх сурвалж: www.habr.com