Halló, íbúar Khabrovsk. Kennsla í fyrsta hópi námskeiðsins hefst í dag . Í þessu sambandi viljum við segja þér frá því hvernig opna vefnámskeiðið um þetta námskeið fór fram.
В við ræddum um þær áskoranir sem SQL gagnagrunnar standa frammi fyrir á tímum skýja og Kubernetes. Á sama tíma skoðuðum við hvernig SQL gagnagrunnar aðlagast og stökkbreytast undir áhrifum þessara áskorana.
Vefnámskeiðið var haldið , Google Cloud Practice Delivery Manager hjá EPAM Systems.
Þegar trén voru lítil...
Fyrst skulum við muna hvernig val á DBMS hófst í lok síðustu aldar. Hins vegar verður þetta ekki erfitt, því valið á DBMS í þá daga hófst og endaði Oracle.
Seint á tíunda áratugnum og snemma á tíunda áratugnum var í rauninni ekkert val þegar kemur að stigstæranlegum gagnagrunnum í iðnaði. Já, það voru IBM DB90, Sybase og einhverjir aðrir gagnagrunnar sem komu og fóru, en almennt voru þeir ekki svo áberandi miðað við bakgrunn Oracle. Samkvæmt því var kunnátta verkfræðinga þeirra tíma á einhvern hátt bundin við eina valið sem var til.
Oracle DBA þurfti að geta:
- setja upp Oracle Server úr dreifingarsettinu;
- stilla Oracle Server:
- init.ora;
- hlustandi.ora;
- búa til:
- borðpláss;
- kerfi;
- notendur;
— выполнять резервное копирование и восстановление;
— framkvæma eftirlit;
— takast á við óskýrar beiðnir.
Á sama tíma var engin sérstök krafa frá Oracle DBA:
- geta valið ákjósanlegasta DBMS eða aðra tækni til að geyma og vinna gögn;
- veita mikið framboð og láréttan sveigjanleika (þetta var ekki alltaf DBA mál);
- góð þekking á viðfangsefninu, innviðum, forritaarkitektúr, stýrikerfi;
- hlaða og afferma gögn, flytja gögn á milli mismunandi DBMS.
Almennt séð, ef við tölum um valið í þá daga, líkist það valinu í sovéskri verslun seint á níunda áratugnum:
Okkar tími
Síðan þá hafa trén auðvitað stækkað, heimurinn hefur breyst og hann varð eitthvað á þessa leið:
DBMS markaðurinn hefur einnig breyst, eins og greinilega má sjá af nýjustu skýrslu Gartner:
Og hér skal tekið fram að ský, sem vinsældir þeirra eru að aukast, hafa hertekið sess þeirra. Ef við lesum sömu Gartner skýrsluna munum við sjá eftirfarandi niðurstöður:
- Margir viðskiptavinir eru á leiðinni til að flytja forrit í skýið.
- Ný tækni birtist fyrst í skýinu og það er ekki staðreynd að hún muni nokkurn tíma fara yfir í innviði sem ekki eru ský.
- Verðlagningarlíkanið sem greitt er fyrir er orðið algengt. Allir vilja borga aðeins fyrir það sem þeir nota, og þetta er ekki einu sinni stefna, heldur einfaldlega staðhæfing um staðreyndir.
Hvað nú?
Í dag erum við öll í skýinu. Og spurningarnar sem vakna fyrir okkur eru spurningar um val. Og það er gríðarstórt, jafnvel þótt við tölum aðeins um val á DBMS tækni á staðnum sniði. Við erum líka með stýrða þjónustu og SaaS. Þannig verður valið aðeins erfiðara með hverju árinu.
Ásamt spurningum um val eru það líka takmarkandi þættir:
- verð. Mörg tækni kostar enn peninga;
- færni. Ef við erum að tala um frjálsan hugbúnað, þá vaknar spurningin um færni, þar sem frjáls hugbúnaður krefst nægilegrar hæfni frá þeim sem dreifa og reka hann;
- hagnýtur. Ekki öll þjónusta sem er fáanleg í skýinu og byggð, til dæmis, jafnvel á sama Postgres, hefur sömu eiginleika og Postgres On-premises. Þetta er mikilvægur þáttur sem þarf að vita og skilja. Þar að auki verður þessi þáttur mikilvægari en þekking á einhverjum falnum getu eins DBMS.
Hvað er búist við frá DA/DE núna:
- góðan skilning á viðfangsefninu og notkunararkitektúr;
- hæfni til að velja rétta DBMS tækni, að teknu tilliti til verkefnisins sem fyrir hendi er;
- getu til að velja ákjósanlegasta aðferð til að innleiða valda tækni í samhengi við núverandi takmarkanir;
- getu til að framkvæma gagnaflutning og flutning;
- getu til að innleiða og reka valdar lausnir.
Fyrir neðan dæmi byggt á GCP sýnir hvernig val á einni eða annarri tækni til að vinna með gögn virkar eftir uppbyggingu þess:
Vinsamlegast athugaðu að PostgreSQL er ekki innifalið í skemanu og það er vegna þess að það er falið undir hugtökum Ský SQL. Og þegar við komum að Cloud SQL þurfum við að velja aftur:
Það skal tekið fram að þetta val er ekki alltaf skýrt, þannig að forritarar hafa oft innsæi að leiðarljósi.
Samtals:
- Því lengra sem þú ferð, því áleitnari verður spurningin um val. Og jafnvel ef þú horfir aðeins á GCP, stýrða þjónustu og SaaS, þá birtist eitthvað minnst á RDBMS aðeins í 4. skrefi (og þar er Spanner nálægt). Auk þess birtist valið á PostgreSQL í 5. skrefi, og við hliðina á því eru líka MySQL og SQL Server, þ.e. það er mikið af öllu en þú verður að velja.
- Við megum ekki gleyma höftum gegn bakgrunni freistinga. Í grundvallaratriðum vilja allir hafa Spanner, en það er dýrt. Fyrir vikið lítur dæmigerð beiðni eitthvað svona út: „Vinsamlegast gerðu okkur að lykil en fyrir verðið á Cloud SQL eruð þið fagmenn!
Hvað ættum við að gera?
Án þess að segjast vera hinn fullkomni sannleikur skulum við segja eftirfarandi:
Við þurfum að breyta nálgun okkar á nám:
- það þýðir ekkert að kenna eins og DBA var kennt áður;
- þekking á einni vöru er ekki lengur nóg;
- en að þekkja tugi á stigi eins er ómögulegt.
Þú þarft að vita ekki aðeins og ekki hversu mikið varan er, heldur:
- notkunartilvik umsóknar þess;
- mismunandi dreifingaraðferðir;
- kostir og gallar hverrar aðferðar;
- svipaðar og aðrar vörur til að gera upplýst og ákjósanlegt val og ekki alltaf í hag fyrir kunnuglega vöru.
Þú þarft líka að geta flutt gögn og skilið grundvallarreglur samþættingar við ETL.
Raunverulegt mál
Í seinni tíð var nauðsynlegt að búa til bakenda fyrir farsímaforrit. Þegar vinna hófst við það var bakendinn þegar búinn að þróa og tilbúinn til innleiðingar og eyddi þróunarteymið um tvö ár í þetta verkefni. Eftirfarandi verkefni voru sett:
- byggja CI/CD;
- endurskoða arkitektúrinn;
- setja þetta allt í gang.
Forritið sjálft var örþjónusta og Python/Django kóðinn var þróaður frá grunni og beint í GCP. Hvað markhópinn varðar, var gert ráð fyrir að það yrðu tvö svæði - Bandaríkin og ESB, og umferð var dreift í gegnum Global Load balancer. Allt vinnuálag og tölvuvinnuálag keyrðu á Google Kubernetes Engine.
Hvað gögnin varðar voru 3 mannvirki:
- Cloud Geymsla;
- Datastore;
- Cloud SQL (PostgreSQL).
Maður gæti velt því fyrir sér hvers vegna Cloud SQL var valið? Satt best að segja hefur slík spurning valdið einhvers konar óþægilegu hléi undanfarin ár - það er tilfinning að fólk sé orðið feimið við tengslagagnagrunna, en engu að síður heldur það áfram að nota þá á virkan hátt ;-).
Hvað okkar tilfelli varðar var Cloud SQL valið af eftirfarandi ástæðum:
- Eins og fram hefur komið var forritið þróað með Django og það hefur líkan til að kortleggja viðvarandi gögn úr SQL gagnagrunni yfir á Python hluti (Django ORM).
- Ramminn sjálfur studdi nokkuð takmarkaðan lista yfir DBMS:
- PostgreSQL;
- MariaDB;
- MySQL;
- véfrétt;
- SQLite.
Í samræmi við það var PostgreSQL valið af þessum lista frekar innsæi (jæja, það er ekki Oracle að velja, í raun).
Það sem vantaði:
- forritið var aðeins sent á 2 svæðum og það þriðja birtist í áætlunum (Asíu);
- Gagnagrunnurinn var staðsettur á Norður-Ameríku svæðinu (Iowa);
- af hálfu viðskiptavinarins voru áhyggjur af mögulegum tafir á aðgangi frá Evrópu og Asíu og truflanir í þjónustu ef um er að ræða niður í DBMS.
Þrátt fyrir að Django sjálft geti unnið með nokkra gagnagrunna samhliða og skipt þeim í lestur og ritun var ekki svo mikið af skrifum í forritinu (meira en 90% er lestur). Og almennt, og almennt, ef það var hægt að gera lesa eftirlíkingu af aðalstöðinni í Evrópu og Asíu, þetta væri málamiðlunarlausn. Jæja, hvað er svona flókið við það?
Erfiðleikarnir voru þeir að viðskiptavinurinn vildi ekki gefast upp á að nota stýrða þjónustu og Cloud SQL. Og geta Cloud SQL er takmörkuð eins og er. Cloud SQL styður High framboð (HA) og Read Replica (RR), en sama RR er aðeins stutt á einu svæði. Eftir að hafa búið til gagnagrunn á Ameríkusvæðinu geturðu ekki búið til aflestrar eftirmynd á Evrópusvæðinu með því að nota Cloud SQL, þó að Postgres sjálft komi ekki í veg fyrir að þú gerir þetta. Bréfaskipti við starfsmenn Google leiddu hvergi og enduðu með loforðum í stíl við „við þekkjum vandamálið og erum að vinna í því, einhvern tíma verður málið leyst.
Ef við listum upp getu Cloud SQL í stuttu máli mun það líta eitthvað svona út:
1. Mikið framboð (HA):
- innan eins svæðis;
- í gegnum diskafritun;
- PostgreSQL vélar eru ekki notaðar;
- sjálfvirk og handvirk stjórn möguleg - bilun/bilun;
- Þegar skipt er um er DBMS ekki tiltækt í nokkrar mínútur.
2. Lestu eftirmynd (RR):
- innan eins svæðis;
- heitur biðstaða;
- PostgreSQL straumafritun.
Þar að auki, eins og venja er, þegar þú velur tækni stendur þú alltaf frammi fyrir einhverjum takmarkanir:
- viðskiptavinurinn vildi ekki búa til einingar og nota IaaS, nema í gegnum GKE;
- viðskiptavinurinn vill ekki nota sjálfsafgreiðslu PostgreSQL/MySQL;
- Jæja, almennt séð væri Google Spanner mjög hentugur ef það væri ekki fyrir verðið, hins vegar getur Django ORM ekki unnið með það, en það er gott.
Í ljósi aðstæðna fékk viðskiptavinurinn eftirfarandi spurningu: "Geturðu gert eitthvað svipað þannig að það sé eins og Google Spanner, en virkar líka með Django ORM?"
Lausnarkostur nr. 0
Það fyrsta sem mér datt í hug:
- vertu innan CloudSQL;
- það verður engin innbyggð afritun milli svæða í neinni mynd;
- reyndu að hengja eftirmynd við núverandi Cloud SQL af PostgreSQL;
- ræstu PostgreSQL tilvik einhvers staðar og einhvern veginn, en að minnsta kosti ekki snerta meistara.
Því miður, það kom í ljós að þetta er ekki hægt að gera, vegna þess að það er enginn aðgangur að gestgjafanum (hann er í öðru verkefni) - pg_hba og svo framvegis, og það er heldur enginn aðgangur undir ofurnotanda.
Lausnarkostur nr. 1
Eftir nánari umhugsun og að teknu tilliti til fyrri aðstæðna breyttist hugsunarleiðin nokkuð:
- Við erum enn að reyna að vera innan CloudSQL, en við erum að skipta yfir í MySQL, vegna þess að Cloud SQL eftir MySQL er með ytri meistara, sem:
— er umboð fyrir ytri MySQL;
- lítur út eins og MySQL dæmi;
- fundið upp til að flytja gögn frá öðrum skýjum eða á staðnum.
Þar sem uppsetning MySQL afritunar krefst ekki aðgangs að gestgjafanum virkaði í grundvallaratriðum allt, en það var mjög óstöðugt og óþægilegt. Og þegar við fórum lengra varð þetta alveg skelfilegt, því við settum upp allt mannvirkið með terraform, og skyndilega kom í ljós að ytri meistarinn var ekki studdur af terraform. Já, Google er með CLI, en af einhverjum ástæðum virkaði allt hér annað slagið - stundum er það búið til, stundum er það ekki búið til. Kannski vegna þess að CLI var fundið upp fyrir ytri gagnaflutning, en ekki fyrir eftirlíkingar.
Reyndar, á þessum tímapunkti varð ljóst að Cloud SQL hentar alls ekki. Eins og þeir segja, við gerðum allt sem við gátum.
Lausnarkostur nr. 2
Þar sem ekki var hægt að vera innan Cloud SQL rammans reyndum við að móta kröfur um málamiðlunarlausn. Kröfurnar reyndust vera eftirfarandi:
- vinna í Kubernetes, hámarksnotkun auðlinda og getu Kubernetes (DCS, ...) og GCP (LB, ...);
- skortur á kjölfestu frá fullt af óþarfa hlutum í skýinu eins og HA proxy;
- getu til að keyra PostgreSQL eða MySQL á aðal HA svæðinu; á öðrum svæðum - HA frá RR aðalsvæðisins auk eintaks þess (fyrir áreiðanleika);
- multi master (ég vildi ekki hafa samband við hann, en það var ekki mjög mikilvægt)
.
Vegna þessara krafna, blsviðeigandi DBMS og bindandi valkosti:
- MySQL Galera;
- KakkalakkiDB;
- PostgreSQL verkfæri
:
- pgpool-II;
— Patroni.
MySQL Galera
MySQL Galera tæknin var þróuð af Codership og er viðbót fyrir InnoDB. Sérkenni:
- fjölmeistari;
- samstillt afritun;
- lestur úr hvaða hnút sem er;
- upptaka á hvaða hnút sem er;
- innbyggður HA vélbúnaður;
- Það er til hjálmtöflu frá Bitnami.
KakkalakkiDB
Samkvæmt lýsingunni er hluturinn algjör sprengja og er opinn uppspretta verkefni skrifað í Go. Aðal þátttakandi er Cockroach Labs (stofnað af fólki frá Google). Þetta vensla DBMS var upphaflega hannað til að vera dreift (með láréttri stærðarstærð úr kassanum) og bilunarþolið. Höfundar þess frá fyrirtækinu lýstu því markmiði að „sameina auðlegð SQL virkni við lárétta aðgengið sem NoSQL lausnir þekkja.
Ágætur bónus er stuðningur við samskiptareglur um tengingu eftir sókn.
Pgpool
Þetta er viðbót við PostgreSQL, í rauninni ný eining sem tekur yfir allar tengingar og vinnur úr þeim. Það hefur sinn eigin hleðslujafnara og flokkunaraðila, með leyfi samkvæmt BSD leyfinu. Það gefur næg tækifæri, en lítur nokkuð ógnvekjandi út, vegna þess að tilvist nýrrar einingar gæti orðið uppspretta nokkurra viðbótarævintýra.
Patroni
Þetta er það síðasta sem ég rak augun í, og eins og það kom í ljós, ekki til einskis. Patroni er opinn uppspretta tól, sem er í raun Python púkinn sem gerir þér kleift að viðhalda PostgreSQL klösum sjálfkrafa með ýmsum gerðum af afritun og sjálfvirkri hlutverkaskipti. Hluturinn reyndist mjög áhugaverður, þar sem hann fellur vel að kúbernum og kynnir engar nýjar einingar.
Hvað valdir þú á endanum?
Valið var ekki auðvelt:
- KakkalakkiDB - eldur, en dimmur;
- MySQL Galera - heldur ekki slæmt, það er notað víða, en MySQL;
- Pgpool — mikið af óþarfa einingum, svo sem samþætting við skýið og K8s;
- Patroni - framúrskarandi samþætting við K8s, engin óþarfa einingar, samþættast vel við GCP LB.
Valið féll því á Patroni.
Niðurstöður
Það er kominn tími til að draga saman í stuttu máli. Já, heimur upplýsingatækniinnviða hefur breyst verulega og þetta er bara byrjunin. Og ef áður voru skýin bara önnur tegund innviða, þá er allt öðruvísi núna. Þar að auki birtast nýjungar í skýjunum stöðugt, þær munu birtast og ef til vill munu þær aðeins birtast í skýjunum og aðeins þá, með viðleitni sprotafyrirtækja, verða þær fluttar á staðnum.
Hvað SQL varðar mun SQL lifa. Þetta þýðir að þú þarft að kunna PostgreSQL og MySQL og geta unnið með þau, en enn mikilvægara er að geta notað þau rétt.
Heimild: www.habr.com