Helo, trigolion Khabrovsk. Mae dosbarthiadau grŵp cyntaf y cwrs yn dechrau heddiw . Yn hyn o beth, hoffem ddweud wrthych sut y cynhaliwyd y gweminar agored ar y cwrs hwn.
В buom yn siarad am yr heriau y mae cronfeydd data SQL yn eu hwynebu yn oes y cymylau a Kubernetes. Ar yr un pryd, buom yn edrych ar sut mae cronfeydd data SQL yn addasu ac yn treiglo o dan ddylanwad yr heriau hyn.
Cynhaliwyd y gweminar , Rheolwr Cyflenwi Ymarfer Google Cloud yn EPAM Systems.
Pan oedd y coed yn fach...
Yn gyntaf, gadewch i ni gofio sut y dechreuodd y dewis o DBMS ar ddiwedd y ganrif ddiwethaf. Fodd bynnag, ni fydd hyn yn anodd, oherwydd dechreuodd a daeth y dewis o DBMS yn y dyddiau hynny i ben Oracle.
Ar ddiwedd y 90au a dechrau'r 2au, yn y bôn nid oedd unrhyw ddewis o ran cronfeydd data graddadwy diwydiannol. Oedd, roedd IBM DBXNUMX, Sybase a rhai cronfeydd data eraill a ddaeth ac a aeth, ond yn gyffredinol nid oeddent mor amlwg yn erbyn cefndir Oracle. Yn unol â hynny, roedd sgiliau peirianwyr yr amseroedd hynny rywsut ynghlwm wrth yr unig ddewis a oedd yn bodoli.
Roedd yn rhaid i Oracle DBA allu:
- gosod Oracle Server o'r pecyn dosbarthu;
- ffurfweddu Gweinydd Oracle:
- init.ora;
- gwrandäwr.ora;
- creu:
- gofodau bwrdd;
- cynlluniau;
- defnyddwyr;
- perfformio copi wrth gefn ac adfer;
— monitro;
— delio â cheisiadau is-optimaidd.
Ar yr un pryd, nid oedd unrhyw ofyniad arbennig gan Oracle DBA:
- gallu dewis y DBMS gorau posibl neu dechnoleg arall ar gyfer storio a phrosesu data;
- darparu argaeledd uchel a scalability llorweddol (nid oedd hyn bob amser yn broblem DBA);
- gwybodaeth dda o'r maes pwnc, seilwaith, pensaernïaeth cymhwysiad, OS;
- llwytho a dadlwytho data, mudo data rhwng gwahanol DBMSs.
Yn gyffredinol, os byddwn yn siarad am y dewis yn y dyddiau hynny, mae'n debyg i'r dewis mewn siop Sofietaidd ar ddiwedd yr 80au:
Ein hamser
Ers hynny, wrth gwrs, mae'r coed wedi tyfu, mae'r byd wedi newid, a daeth yn rhywbeth fel hyn:
Mae'r farchnad DBMS hefyd wedi newid, fel y gwelir yn glir o'r adroddiad diweddaraf gan Gartner:
Ac yma dylid nodi bod cymylau, y mae eu poblogrwydd yn tyfu, wedi meddiannu eu cilfach. Os byddwn yn darllen yr un adroddiad Gartner, byddwn yn gweld y casgliadau a ganlyn:
- Mae llawer o gwsmeriaid ar y llwybr i symud cymwysiadau i'r cwmwl.
- Mae technolegau newydd yn ymddangos gyntaf yn y cwmwl ac nid yw'n ffaith y byddant byth yn symud i seilwaith di-gwmwl.
- Mae'r model prisio talu-wrth-fynd wedi dod yn gyffredin. Mae pawb eisiau talu am yr hyn maen nhw'n ei ddefnyddio yn unig, ac nid yw hyn hyd yn oed yn duedd, ond yn syml yn ddatganiad o ffaith.
Beth nawr?
Heddiw rydyn ni i gyd yn y cwmwl. Ac mae'r cwestiynau sy'n codi i ni yn gwestiynau o ddewis. Ac mae'n enfawr, hyd yn oed os ydym yn siarad yn unig am y dewis o dechnolegau DBMS yn y fformat Ar y safle. Rydym hefyd wedi rheoli gwasanaethau a SaaS. Felly, dim ond bob blwyddyn y daw'r dewis yn anoddach.
Ynghyd â chwestiynau o ddewis, mae yna hefyd ffactorau cyfyngol:
- pris. Mae llawer o dechnolegau yn dal i gostio arian;
- sgiliau. Os ydym yn sôn am feddalwedd rhad ac am ddim, yna mae'r cwestiwn o sgiliau yn codi, gan fod meddalwedd rhydd yn gofyn am gymhwysedd digonol gan y bobl sy'n ei ddefnyddio a'i weithredu;
- swyddogaethol. Nid oes gan bob gwasanaeth sydd ar gael yn y cwmwl ac wedi'i adeiladu, dyweder, hyd yn oed ar yr un Postgres, yr un nodweddion â Postgres On-premises. Mae hwn yn ffactor hanfodol y mae angen ei wybod a'i ddeall. Ar ben hynny, mae'r ffactor hwn yn dod yn bwysicach na gwybodaeth am rai galluoedd cudd un DBMS.
Beth a ddisgwylir gan DA/DE nawr:
- dealltwriaeth dda o'r maes pwnc a phensaernïaeth cymhwyso;
- y gallu i ddewis y dechnoleg DBMS briodol yn gywir, gan ystyried y dasg dan sylw;
- y gallu i ddewis y dull gorau posibl ar gyfer gweithredu'r dechnoleg a ddewiswyd yng nghyd-destun cyfyngiadau presennol;
- y gallu i drosglwyddo data a mudo;
- y gallu i weithredu a gweithredu datrysiadau dethol.
Isod enghraifft yn seiliedig ar GCP yn dangos sut mae dewis un dechnoleg neu’r llall ar gyfer gweithio gyda data yn gweithio yn dibynnu ar ei strwythur:
Sylwch nad yw PostgreSQL wedi'i gynnwys yn y sgema, ac mae hyn oherwydd ei fod wedi'i guddio o dan y derminoleg Cloud SQL. A phan gyrhaeddwn Cloud SQL, mae angen i ni wneud dewis eto:
Dylid nodi nad yw'r dewis hwn bob amser yn glir, felly mae datblygwyr cymwysiadau yn aml yn cael eu harwain gan greddf.
Cyfanswm:
- Po bellaf yr ewch, y mwyaf dybryd y daw'r cwestiwn o ddewis. A hyd yn oed os edrychwch ar GCP yn unig, gwasanaethau a reolir a SaaS, yna mae rhywfaint o sôn am RDBMS yn ymddangos ar y 4ydd cam yn unig (ac mae Spanner gerllaw). Hefyd, mae'r dewis o PostgreSQL yn ymddangos yn y 5ed cam, ac wrth ei ymyl mae MySQL a SQL Server hefyd, hynny yw mae yna lawer o bopeth, ond mae'n rhaid i chi ddewis.
- Rhaid inni beidio ag anghofio am gyfyngiadau yn erbyn cefndir o demtasiynau. Yn y bôn mae pawb eisiau Sbaner, ond mae'n ddrud. O ganlyniad, mae cais nodweddiadol yn edrych fel hyn: “Gwnewch ni yn Sbaner ond am bris Cloud SQL, rydych chi'n weithwyr proffesiynol!”
Beth ddylwn i ei wneud?
Heb honni mai dyma'r gwir eithaf, gadewch i ni ddweud y canlynol:
Mae angen i ni newid ein hagwedd at ddysgu:
- nid oes diben addysgu'r ffordd y cafodd DBAs eu haddysgu o'r blaen;
- nid yw gwybodaeth am un cynnyrch yn ddigon bellach;
- ond mae gwybod dwsinau ar lefel un yn amhosibl.
Mae angen i chi wybod nid yn unig ac nid faint yw'r cynnyrch, ond:
- achos defnydd o'i gais;
- gwahanol ddulliau lleoli;
- manteision ac anfanteision pob dull;
- cynhyrchion tebyg ac amgen i wneud dewis gwybodus a gorau posibl ac nid bob amser o blaid cynnyrch cyfarwydd.
Mae angen i chi hefyd allu mudo data a deall egwyddorion sylfaenol integreiddio ag ETL.
achos go iawn
Yn y gorffennol diweddar, roedd angen creu backend ar gyfer cais symudol. Erbyn i'r gwaith ddechrau arno, roedd y backend eisoes wedi'i ddatblygu ac yn barod i'w weithredu, a threuliodd y tîm datblygu tua dwy flynedd ar y prosiect hwn. Gosodwyd y tasgau canlynol:
- adeiladu CI/CD;
- adolygu'r bensaernïaeth;
- rhoi'r cyfan ar waith.
Roedd y cymhwysiad ei hun yn ficrowasanaethau, a datblygwyd y cod Python / Django o'r dechrau ac yn uniongyrchol yn GCP. O ran y gynulleidfa darged, rhagdybiwyd y byddai dau ranbarth - UDA a'r UE, a dosbarthwyd traffig trwy'r Global Load balancer. Roedd pob Llwyth Gwaith a llwyth gwaith cyfrifo yn rhedeg ar Google Kubernetes Engine.
O ran y data, roedd 3 strwythur:
- Storio Cwmwl;
- Storfa Ddata;
- Cloud SQL (PostgreSQL).
Efallai y bydd rhywun yn meddwl tybed pam y dewiswyd Cloud SQL? A dweud y gwir, mae cwestiwn o'r fath wedi achosi rhyw fath o saib lletchwith yn ystod y blynyddoedd diwethaf - mae yna deimlad bod pobl wedi mynd yn swil ynghylch cronfeydd data perthynol, ond serch hynny maent yn parhau i'w defnyddio'n weithredol ;-).
O ran ein hachos ni, dewiswyd Cloud SQL am y rhesymau canlynol:
- Fel y crybwyllwyd, datblygwyd y cymhwysiad gan ddefnyddio Django, ac mae ganddo fodel ar gyfer mapio data parhaus o gronfa ddata SQL i wrthrychau Python (Django ORM).
- Roedd y fframwaith ei hun yn cefnogi rhestr weddol gyfyngedig o DBMSs:
- PostgreSQL;
- MariaDB;
- MySQL;
- Oracl;
- SQLite.
Yn unol â hynny, dewiswyd PostgreSQL o'r rhestr hon yn reddfol braidd (wel, nid Oracle yw'r dewis, mewn gwirionedd).
Beth oedd ar goll:
- dim ond mewn 2 ranbarth y defnyddiwyd y cais, ac ymddangosodd 3ydd un mewn cynlluniau (Asia);
- Lleolwyd y gronfa ddata yn rhanbarth Gogledd America (Iowa);
- ar ran y cwsmer roedd pryderon am bosibilrwydd oedi mynediad o Ewrop ac Asia a ymyraethau mewn gwasanaeth rhag ofn y bydd amser segur DBMS.
Er gwaethaf y ffaith y gall Django ei hun weithio gyda nifer o gronfeydd data yn gyfochrog a'u rhannu'n ddarllen ac ysgrifennu, nid oedd cymaint o ysgrifennu yn y cais (mae mwy na 90% yn darllen). Ac yn gyffredinol, ac yn gyffredinol, os oedd modd gwneud darllen-replica o'r prif ganolfan yn Ewrop ac Asia, byddai hwn yn ateb cyfaddawd. Wel, beth sydd mor gymhleth amdano?
Yr anhawster oedd nad oedd y cwsmer am roi'r gorau i ddefnyddio gwasanaethau a reolir a Cloud SQL. Ac mae galluoedd Cloud SQL yn gyfyngedig ar hyn o bryd. Mae Cloud SQL yn cefnogi argaeledd Uchel (HA) a Read Replica (RR), ond dim ond mewn un rhanbarth y cefnogir yr un RR. Ar ôl creu cronfa ddata yn rhanbarth America, ni allwch wneud replica wedi'i ddarllen yn y rhanbarth Ewropeaidd gan ddefnyddio Cloud SQL, er nad yw Postgres ei hun yn eich atal rhag gwneud hyn. Nid arweiniodd gohebiaeth â gweithwyr Google i unman a daeth i ben gydag addewidion yn arddull “rydym yn gwybod y broblem ac yn gweithio arni, ryw ddydd bydd y mater yn cael ei ddatrys.”
Os byddwn yn rhestru galluoedd Cloud SQL yn fyr, bydd yn edrych fel hyn:
1. Argaeledd uchel (HA):
- o fewn un rhanbarth;
- trwy ddyblygu disg;
- Ni ddefnyddir peiriannau PostgreSQL;
- rheolaeth awtomatig a llaw yn bosibl - methiant/methu yn ôl;
- Wrth newid, nid yw'r DBMS ar gael am rai munudau.
2. Darllenwch Replica (RR):
- o fewn un rhanbarth;
- wrth gefn poeth;
- Dyblygiad ffrydio PostgreSQL.
Yn ogystal, fel sy'n arferol, wrth ddewis technoleg rydych chi bob amser yn wynebu rhai cyfyngiadau:
- nid oedd y cwsmer eisiau creu endidau a defnyddio IaaS, ac eithrio trwy GKE;
- ni fyddai'r cwsmer yn hoffi defnyddio PostgreSQL/MySQL hunanwasanaeth;
- Wel, yn gyffredinol, byddai Google Spanner yn eithaf addas pe na bai am ei bris, fodd bynnag, ni all Django ORM weithio gydag ef, ond mae'n beth da.
O ystyried y sefyllfa, derbyniodd y cwsmer gwestiwn dilynol: “Allwch chi wneud rhywbeth tebyg fel ei fod fel Google Spanner, ond hefyd yn gweithio gyda Django ORM?”
Opsiwn ateb Rhif 0
Y peth cyntaf a ddaeth i'r meddwl:
- aros o fewn CloudSQL;
- ni fydd unrhyw atgynhyrchu wedi'i ymgorffori rhwng rhanbarthau mewn unrhyw ffurf;
- ceisio atodi replica i Cloud SQL sy'n bodoli eisoes gan PostgreSQL;
- lansiwch enghraifft PostgreSQL yn rhywle a rhywsut, ond o leiaf peidiwch â chyffwrdd â meistr.
Ysywaeth, mae'n troi allan na ellir gwneud hyn, oherwydd nid oes mynediad i'r gwesteiwr (mae mewn prosiect gwahanol yn gyfan gwbl) - pg_hba ac yn y blaen, ac nid oes mynediad o dan superuser ychwaith.
Opsiwn ateb Rhif 1
Ar ôl myfyrio ymhellach a chymryd i ystyriaeth amgylchiadau blaenorol, newidiodd y syniad o feddwl ychydig:
- Rydym yn dal i geisio aros o fewn CloudSQL, ond rydym yn newid i MySQL, oherwydd mae gan Cloud SQL gan MySQL feistr allanol, sydd:
— yn ddirprwy ar gyfer MySQL allanol;
- yn edrych fel enghraifft MySQL;
- wedi'i ddyfeisio ar gyfer mudo data o gymylau eraill neu Ar y Safle.
Gan nad oes angen mynediad i'r gwesteiwr ar gyfer sefydlu dyblygiad MySQL, mewn egwyddor fe weithiodd popeth, ond roedd yn ansefydlog ac yn anghyfleus iawn. A phan aethom ymhellach, daeth yn gwbl frawychus, oherwydd fe wnaethom ddefnyddio'r strwythur cyfan gyda theras, ac yn sydyn daeth yn amlwg nad oedd y meistr allanol yn cael ei gefnogi gan terraform. Oes, mae gan Google CLI, ond am ryw reswm roedd popeth yn gweithio yma o bryd i'w gilydd - weithiau mae'n cael ei greu, weithiau nid yw'n cael ei greu. Efallai oherwydd bod y CLI wedi'i ddyfeisio ar gyfer mudo data allanol, ac nid ar gyfer atgynyrchiadau.
Mewn gwirionedd, ar y pwynt hwn daeth yn amlwg nad yw Cloud SQL yn addas o gwbl. Fel maen nhw'n dweud, fe wnaethon ni bopeth o fewn ein gallu.
Opsiwn ateb Rhif 2
Gan nad oedd yn bosibl aros o fewn fframwaith Cloud SQL, fe wnaethom geisio llunio gofynion ar gyfer datrysiad cyfaddawd. Trodd y gofynion fel a ganlyn:
- gweithio yn Kubernetes, y defnydd mwyaf posibl o adnoddau a galluoedd Kubernetes (DCS, ...) a GCP (LB, ...);
- diffyg balast o griw o bethau diangen yn y cwmwl fel dirprwy HA;
- y gallu i redeg PostgreSQL neu MySQL yn y prif ranbarth HA; mewn rhanbarthau eraill - HA o RR y prif ranbarth ynghyd â'i gopi (ar gyfer dibynadwyedd);
- amlfeistr (doeddwn i ddim eisiau cysylltu ag ef, ond nid oedd yn bwysig iawn)
.
O ganlyniad i'r gofynion hyn, tDBMS addas a dewisiadau rhwymo:
- MySQL Galera;
- CockroachDB;
- Offer PostgreSQL
:
- pgpool-II;
— Patroni.
MySQL Galera
Datblygwyd technoleg MySQL Galera gan Codership ac mae'n ategyn ar gyfer InnoDB. Nodweddion arbennig:
- amlfeistr;
- atgynhyrchu cydamserol;
- darllen o unrhyw nod;
- recordio i unrhyw nod;
- mecanwaith HA adeiledig;
- Mae siart Helm o Bitnami.
Chwilod Duon
Yn ôl y disgrifiad, mae'r peth yn hollol fom ac mae'n brosiect ffynhonnell agored a ysgrifennwyd yn Go. Y prif gyfranogwr yw Cockroach Labs (a sefydlwyd gan bobl o Google). Dyluniwyd y DBMS perthynol hwn yn wreiddiol i'w ddosbarthu (gyda graddiad llorweddol allan o'r blwch) ac yn gallu goddef diffygion. Amlinellodd ei awduron o’r cwmni y nod o “gyfuno cyfoeth ymarferoldeb SQL â’r hygyrchedd llorweddol sy’n gyfarwydd i atebion NoSQL.”
Bonws braf yw cefnogaeth i'r protocol cysylltiad ôl-gress.
pgpwl
Mae hwn yn ychwanegiad i PostgreSQL, mewn gwirionedd, endid newydd sy'n cymryd drosodd yr holl gysylltiadau ac yn eu prosesu. Mae ganddo'i gydbwysydd a pharser llwyth ei hun, wedi'i drwyddedu o dan y drwydded BSD. Mae'n darparu digon o gyfleoedd, ond mae'n edrych braidd yn frawychus, oherwydd gallai presenoldeb endid newydd ddod yn ffynhonnell rhai anturiaethau ychwanegol.
Patroni
Dyma'r peth olaf y syrthiodd fy llygaid arno, ac, fel y digwyddodd, nid yn ofer. Cyfleustodau ffynhonnell agored yw Patroni, sydd yn ei hanfod yn daemon Python sy'n eich galluogi i gynnal clystyrau PostgreSQL yn awtomatig gyda gwahanol fathau o ddyblygu a newid rôl awtomatig. Trodd y peth yn ddiddorol iawn, gan ei fod yn integreiddio'n dda â'r ciwb ac nid yw'n cyflwyno unrhyw endidau newydd.
Beth wnaethoch chi ei ddewis yn y diwedd?
Nid oedd y dewis yn hawdd:
- Chwilod Duon — tân, ond tywyll ;
- MySQL Galera - hefyd nid yn ddrwg, fe'i defnyddir mewn llawer o leoedd, ond MySQL;
- pgpwl - llawer o endidau diangen, felly integreiddio â'r cwmwl a K8s;
- Patroni - integreiddio rhagorol gyda K8s, dim endidau diangen, yn integreiddio'n dda â GCP LB.
Felly, disgynnodd y dewis ar Patroni.
Canfyddiadau
Mae'n bryd crynhoi'n fyr. Ydy, mae byd seilwaith TG wedi newid yn sylweddol, a dim ond y dechrau yw hyn. Ac os o'r blaen roedd y cymylau yn fath arall o seilwaith, nawr mae popeth yn wahanol. Ar ben hynny, mae arloesiadau yn y cymylau yn ymddangos yn gyson, byddant yn ymddangos ac, efallai, dim ond yn y cymylau y byddant yn ymddangos a dim ond wedyn, trwy ymdrechion cychwyniadau, y byddant yn cael eu trosglwyddo i Ar-safle.
Fel ar gyfer SQL, bydd SQL yn fyw. Mae hyn yn golygu bod angen i chi wybod PostgreSQL a MySQL a gallu gweithio gyda nhw, ond hyd yn oed yn bwysicach yw gallu eu defnyddio'n gywir.
Ffynhonnell: hab.com