Halo, wakaazi wa Khabrovsk. Madarasa katika kundi la kwanza la kozi hiyo yanaanza leo . Katika suala hili, tungependa kukuambia kuhusu jinsi mtandao wazi kwenye kozi hii ulifanyika.
Π tulizungumza juu ya changamoto za hifadhidata za SQL katika enzi ya mawingu na Kubernetes. Wakati huo huo, tuliangalia jinsi hifadhidata za SQL zinavyobadilika na kubadilika chini ya ushawishi wa changamoto hizi.
Mtandao ulifanyika , Google Cloud Practice Delivery Manager katika EPAM Systems.
Wakati miti ilikuwa ndogo ...
Kwanza, hebu tukumbuke jinsi uchaguzi wa DBMS ulianza mwishoni mwa karne iliyopita. Hata hivyo, hii haitakuwa vigumu, kwa sababu uchaguzi wa DBMS katika siku hizo ulianza na kumalizika Oracle.
Mwishoni mwa miaka ya 90 na mwanzoni mwa miaka ya 2, kimsingi hakukuwa na chaguo linapokuja suala la hifadhidata za viwandani. Ndio, kulikuwa na IBM DBXNUMX, Sybase na hifadhidata zingine zilizokuja na kwenda, lakini kwa ujumla hazikuonekana sana dhidi ya usuli wa Oracle. Ipasavyo, ustadi wa wahandisi wa nyakati hizo kwa namna fulani ulikuwa umefungwa kwa chaguo pekee lililokuwepo.
Oracle DBA ilibidi iweze:
- weka Seva ya Oracle kutoka kwa kit cha usambazaji;
- sanidi Seva ya Oracle:
- init.ora;
- msikilizaji.ora;
- kuunda:
- nafasi za meza;
- mipango;
- watumiaji;
- fanya nakala rudufu na urejeshe;
- kufanya ufuatiliaji;
- kushughulikia maombi ya chini kabisa.
Wakati huo huo, hakukuwa na mahitaji maalum kutoka kwa Oracle DBA:
- kuwa na uwezo wa kuchagua DBMS mojawapo au teknolojia nyingine ya kuhifadhi na kusindika data;
- kutoa upatikanaji wa juu na usawa wa usawa (hili halikuwa suala la DBA kila wakati);
- ujuzi mzuri wa eneo la somo, miundombinu, usanifu wa maombi, OS;
- pakia na upakue data, hamisha data kati ya DBMS tofauti.
Kwa ujumla, ikiwa tunazungumza juu ya chaguo katika siku hizo, inafanana na chaguo katika duka la Soviet mwishoni mwa miaka ya 80:
Wakati wetu
Tangu wakati huo, kwa kweli, miti imekua, ulimwengu umebadilika, na ikawa kitu kama hiki:
Soko la DBMS pia limebadilika, kama inavyoweza kuonekana wazi kutoka kwa ripoti ya hivi punde kutoka kwa Gartner:
Na hapa ni lazima ieleweke kwamba mawingu, ambao umaarufu wake unakua, wamechukua niche yao. Ikiwa tutasoma ripoti hiyo hiyo ya Gartner, tutaona hitimisho zifuatazo:
- Wateja wengi wako kwenye njia ya kuhamisha programu kwenye wingu.
- Teknolojia mpya huonekana kwanza kwenye wingu na sio ukweli kwamba watawahi kuhamia miundombinu isiyo ya wingu.
- Mtindo wa bei ya kulipa kadri unavyokwenda umekuwa jambo la kawaida. Kila mtu anataka kulipa tu kwa kile anachotumia, na hii sio hata mwenendo, lakini taarifa ya ukweli tu.
Nini sasa?
Leo sisi sote tuko kwenye wingu. Na maswali yanayotokea kwetu ni maswali ya chaguo. Na ni kubwa, hata ikiwa tunazungumza tu juu ya chaguo la teknolojia za DBMS katika umbizo la On-majengo. Pia tumesimamia huduma na SaaS. Kwa hivyo, uchaguzi unakuwa mgumu zaidi kila mwaka.
Pamoja na maswali ya uchaguzi, kuna pia mambo ya kuzuia:
- bei. Teknolojia nyingi bado zinagharimu pesa;
- ujuzi. Ikiwa tunazungumzia kuhusu programu ya bure, basi swali la ujuzi hutokea, kwani programu ya bure inahitaji uwezo wa kutosha kutoka kwa watu wanaoipeleka na kuiendesha;
- kazi. Sio huduma zote zinazopatikana katika wingu na kujengwa, tuseme, hata kwenye Postgres sawa, zina sifa sawa na Postgres On-majengo. Hili ni jambo muhimu linalohitaji kujulikana na kueleweka. Kwa kuongezea, sababu hii inakuwa muhimu zaidi kuliko maarifa ya uwezo fulani uliofichwa wa DBMS moja.
Nini kinatarajiwa sasa kutoka kwa DA/DE:
- uelewa mzuri wa eneo la somo na usanifu wa maombi;
- uwezo wa kuchagua kwa usahihi teknolojia ya DBMS inayofaa, kwa kuzingatia kazi iliyopo;
- uwezo wa kuchagua njia mojawapo ya kutekeleza teknolojia iliyochaguliwa katika mazingira ya mapungufu yaliyopo;
- uwezo wa kufanya uhamisho wa data na uhamiaji;
- uwezo wa kutekeleza na kuendesha suluhisho zilizochaguliwa.
Chini ya mfano kulingana na GCP inaonyesha jinsi uchaguzi wa teknolojia moja au nyingine ya kufanya kazi na data inavyofanya kazi kulingana na muundo wake:
Tafadhali kumbuka kuwa PostgreSQL haijajumuishwa kwenye schema, na hii ni kwa sababu imefichwa chini ya istilahi SQL ya Wingu. Na tunapofika kwenye Cloud SQL, tunahitaji kufanya chaguo tena:
Ikumbukwe kwamba uchaguzi huu sio wazi kila wakati, hivyo watengenezaji wa programu mara nyingi huongozwa na intuition.
Jumla:
- Kadiri unavyoendelea, ndivyo swali la chaguo linavyozidi kuwa kubwa. Na hata ukiangalia tu GCP, huduma zinazosimamiwa na SaaS, basi baadhi ya kutajwa kwa RDBMS inaonekana tu katika hatua ya 4 (na Spanner iko karibu). Pamoja, chaguo la PostgreSQL linaonekana katika hatua ya 5, na karibu nayo kuna MySQL na SQL Server, ambayo ni. kuna mengi ya kila kitu, lakini unapaswa kuchagua.
- Hatupaswi kusahau kuhusu vikwazo dhidi ya historia ya majaribu. Kimsingi kila mtu anataka Spanner, lakini ni ghali. Kama matokeo, ombi la kawaida linaonekana kama hii: "Tafadhali utufanyie Spanner lakini kwa bei ya Cloud SQL, nyinyi ni wataalamu!"
Tunapaswa kufanya nini?
Bila kudai kuwa ndio ukweli mkuu, tuseme yafuatayo:
Tunahitaji kubadilisha mtazamo wetu wa kujifunza:
- hakuna maana katika kufundisha jinsi DBA zilivyofundishwa hapo awali;
- ujuzi wa bidhaa moja haitoshi tena;
- lakini kujua kadhaa katika kiwango cha moja haiwezekani.
Unahitaji kujua sio tu na sio kiasi gani cha bidhaa, lakini:
- matumizi ya kesi ya maombi yake;
- njia tofauti za kupeleka;
- faida na hasara za kila njia;
- bidhaa zinazofanana na mbadala kufanya chaguo sahihi na bora na sio kila wakati kupendelea bidhaa inayojulikana.
Pia unahitaji kuwa na uwezo wa kuhamisha data na kuelewa kanuni za msingi za ujumuishaji na ETL.
Kesi halisi
Katika siku za hivi karibuni, ilikuwa ni lazima kuunda backend kwa ajili ya maombi ya simu. Kufikia wakati kazi ilianza juu yake, sehemu ya nyuma ilikuwa tayari imetengenezwa na ilikuwa tayari kwa utekelezaji, na timu ya maendeleo ilitumia takriban miaka miwili kwenye mradi huu. Kazi zifuatazo ziliwekwa:
- jenga CI/CD;
- angalia usanifu;
- weka yote katika utendaji.
Programu yenyewe ilikuwa huduma ndogo, na nambari ya Python/Django ilitengenezwa kutoka mwanzo na moja kwa moja katika GCP. Kuhusu hadhira inayolengwa, ilichukuliwa kuwa kutakuwa na maeneo mawili - Marekani na Umoja wa Ulaya, na trafiki ilisambazwa kupitia mizani ya Global Load. Mizigo yote ya Kazi na kukokotoa mzigo wa kazi ulifanyika kwenye Google Kubernetes Engine.
Kuhusu data, kulikuwa na miundo 3:
- Hifadhi ya Wingu;
- Hifadhidata;
- Cloud SQL (PostgreSQL).
Mtu anaweza kujiuliza kwa nini Cloud SQL ilichaguliwa? Kusema ukweli, swali kama hilo limesababisha aina fulani ya pause isiyo ya kawaida katika miaka ya hivi karibuni - kuna hisia kwamba watu wamekuwa na aibu juu ya hifadhidata za uhusiano, lakini wanaendelea kuzitumia kikamilifu ;-).
Kwa upande wetu, Cloud SQL ilichaguliwa kwa sababu zifuatazo:
- Kama ilivyotajwa, programu ilitengenezwa kwa kutumia Django, na ina mfano wa kuchora data inayoendelea kutoka kwa hifadhidata ya SQL hadi vitu vya Python (Django ORM).
- Mfumo wenyewe uliunga mkono orodha isiyo na kikomo ya DBMSs:
- PostgreSQL;
- MariaDB;
- MySQL;
- maneno;
- SQLite.
Ipasavyo, PostgreSQL ilichaguliwa kutoka kwa orodha hii badala ya angavu (vizuri, sio Oracle ya kuchagua, kwa kweli).
Ni nini kilikosekana:
- maombi yalitumwa tu katika mikoa 2, na ya 3 ilionekana katika mipango (Asia);
- Database ilikuwa iko katika eneo la Amerika Kaskazini (Iowa);
- kwa upande wa mteja kulikuwa na wasiwasi kuhusu uwezekano ucheleweshaji wa ufikiaji kutoka Ulaya na Asia na usumbufu kwenye huduma katika kesi ya kupungua kwa DBMS.
Licha ya ukweli kwamba Django yenyewe inaweza kufanya kazi na hifadhidata kadhaa sambamba na kuzigawanya katika kusoma na kuandika, hakukuwa na maandishi mengi katika programu (zaidi ya 90% inasoma). Na kwa ujumla, na kwa ujumla, ikiwa inawezekana kufanya soma nakala ya msingi kuu huko Uropa na Asia, hii itakuwa suluhisho la maelewano. Naam, ni nini ngumu kuhusu hilo?
Ugumu ulikuwa kwamba mteja hakutaka kukata tamaa kwa kutumia huduma zinazosimamiwa na Cloud SQL. Na uwezo wa Cloud SQL kwa sasa ni mdogo. Cloud SQL inaauni Upatikanaji wa Juu (HA) na Read Replica (RR), lakini RR sawa inaweza kutumika katika eneo moja pekee. Baada ya kuunda hifadhidata katika eneo la Amerika, huwezi kufanya nakala ya kusoma katika eneo la Ulaya kwa kutumia Cloud SQL, ingawa Postgres yenyewe haikuzuii kufanya hivi. Mawasiliano na wafanyakazi wa Google hayakuongoza popote na kumalizia kwa ahadi kwa mtindo wa "tunajua tatizo na tunalifanyia kazi, siku moja suala hilo litatatuliwa."
Ikiwa tutaorodhesha uwezo wa Cloud SQL kwa ufupi, itaonekana kitu kama hiki:
1. Upatikanaji wa juu (HA):
- ndani ya mkoa mmoja;
- kupitia replication ya diski;
- Injini za PostgreSQL hazitumiki;
- udhibiti wa moja kwa moja na mwongozo iwezekanavyo - kushindwa / kushindwa;
- Wakati wa kubadili, DBMS haipatikani kwa dakika kadhaa.
2. Soma Replica (RR):
- ndani ya mkoa mmoja;
- kusubiri moto;
- Replication ya utiririshaji ya PostgreSQL.
Kwa kuongezea, kama kawaida, wakati wa kuchagua teknolojia kila wakati unakabiliwa na zingine vikwazo:
- mteja hakutaka kuunda vyombo na kutumia IaaS, isipokuwa kupitia GKE;
- mteja hatapenda kupeleka huduma binafsi PostgreSQL/MySQL;
- Kweli, kwa ujumla, Google Spanner ingefaa kabisa ikiwa sio kwa bei yake, hata hivyo, Django ORM haiwezi kufanya kazi nayo, lakini ni jambo jema.
Kwa kuzingatia hali hiyo, mteja alipokea swali la ufuatiliaji: "Je, unaweza kufanya kitu kama hicho ili iwe kama Google Spanner, lakini pia inafanya kazi na Django ORM?"
Chaguo la suluhisho nambari 0
Jambo la kwanza lililokuja akilini:
- kukaa ndani ya CloudSQL;
- hakutakuwa na replication iliyojengwa kati ya mikoa kwa namna yoyote;
- jaribu kuambatisha nakala kwenye SQL iliyopo ya Wingu na PostgreSQL;
- zindua mfano wa PostgreSQL mahali pengine na kwa njia fulani, lakini angalau usiguse bwana.
Ole, ikawa kwamba hii haiwezi kufanywa, kwa sababu hakuna upatikanaji wa mwenyeji (ni katika mradi tofauti kabisa) - pg_hba na kadhalika, na pia hakuna upatikanaji chini ya superuser.
Chaguo la suluhisho nambari 1
Baada ya kutafakari zaidi na kuzingatia hali za awali, treni ya mawazo ilibadilika kiasi fulani:
- Bado tunajaribu kukaa ndani ya CloudSQL, lakini tunabadilisha hadi MySQL, kwa sababu Cloud SQL na MySQL ina ustadi wa nje, ambao:
- ni wakala wa MySQL ya nje;
- inaonekana kama mfano wa MySQL;
- iliyoundwa kwa ajili ya kuhamisha data kutoka kwa mawingu mengine au Juu ya majengo.
Kwa kuwa kusanidi urudiaji wa MySQL hauitaji ufikiaji wa mwenyeji, kimsingi kila kitu kilifanya kazi, lakini haikuwa thabiti na haifai. Na tulipoenda zaidi, ikawa ya kutisha kabisa, kwa sababu tulipeleka muundo mzima na terraform, na ghafla ikawa kwamba bwana wa nje hakuungwa mkono na terraform. Ndio, Google ina CLI, lakini kwa sababu fulani kila kitu kilifanya kazi hapa mara kwa mara - wakati mwingine huundwa, wakati mwingine haujaundwa. Labda kwa sababu CLI ilivumbuliwa kwa uhamiaji wa data ya nje, na sio kwa nakala.
Kwa kweli, katika hatua hii ikawa wazi kuwa Cloud SQL haifai kabisa. Kama wanasema, tulifanya kila tuwezalo.
Chaguo la suluhisho nambari 2
Kwa kuwa haikuwezekana kusalia ndani ya mfumo wa Cloud SQL, tulijaribu kuunda mahitaji ya suluhu la maelewano. Mahitaji yaligeuka kuwa yafuatayo:
- kazi katika Kubernetes, matumizi ya juu ya rasilimali na uwezo wa Kubernetes (DCS, ...) na GCP (LB, ...);
- ukosefu wa ballast kutoka kwa kundi la vitu visivyo vya lazima kwenye wingu kama wakala wa HA;
- uwezo wa kuendesha PostgreSQL au MySQL katika eneo kuu la HA; katika mikoa mingine - HA kutoka kwa RR ya kanda kuu pamoja na nakala yake (kwa kuegemea);
- bwana nyingi (sikutaka kuwasiliana naye, lakini haikuwa muhimu sana)
.
Kutokana na madai hayo, ukDBMS zinazofaa na chaguzi za kumfunga:
- Galera ya MySQL;
- CockroachDB;
- Zana za PostgreSQL
:
- pgpool-II;
- Mchungaji.
Galera ya MySQL
Teknolojia ya MySQL Galera ilitengenezwa na Codership na ni programu-jalizi ya InnoDB. Sifa za kipekee:
- bwana nyingi;
- replication synchronous;
- kusoma kutoka kwa nodi yoyote;
- kurekodi kwa node yoyote;
- utaratibu wa HA uliojengwa;
- Kuna chati ya Helm kutoka Bitnami.
JogooDB
Kulingana na maelezo, jambo hilo ni bomu kabisa na ni mradi wa chanzo wazi ulioandikwa katika Go. Mshiriki mkuu ni Cockroach Labs (iliyoanzishwa na watu kutoka Google). DBMS hii ya uhusiano iliundwa ili kusambazwa (kwa kuongeza mlalo nje ya kisanduku) na kustahimili makosa. Waandishi wake kutoka kampuni walielezea lengo la "kuchanganya utajiri wa utendaji wa SQL na ufikiaji mlalo unaojulikana kwa suluhisho za NoSQL."
Bonasi nzuri ni msaada kwa itifaki ya unganisho la baada ya gress.
Pgpool
Hili ni nyongeza kwa PostgreSQL, kwa kweli, huluki mpya ambayo inachukua miunganisho yote na kuichakata. Ina mizani na kichanganuzi cha mzigo wake, iliyopewa leseni chini ya leseni ya BSD. Inatoa fursa nyingi, lakini inaonekana ya kutisha, kwa sababu uwepo wa chombo kipya unaweza kuwa chanzo cha matukio mengine ya ziada.
Mchungaji
Hili ndilo jambo la mwisho ambalo macho yangu yalianguka, na, kama ilivyotokea, sio bure. Patroni ni matumizi ya chanzo wazi, ambayo kimsingi ni daemon ya Python ambayo hukuruhusu kudumisha kiotomatiki nguzo za PostgreSQL na aina anuwai za urudufishaji na ubadilishaji wa jukumu otomatiki. Jambo hilo liligeuka kuwa la kuvutia sana, kwani linaunganisha vizuri na cuber na haitoi vyombo vipya.
Ulichagua nini mwishoni?
Chaguo haikuwa rahisi:
- JogooDB - moto, lakini giza;
- Galera ya MySQL - pia sio mbaya, hutumiwa katika maeneo mengi, lakini MySQL;
- Pgpool - vyombo vingi visivyohitajika, ushirikiano wa hivyo-hivyo na wingu na K8s;
- Mchungaji - ushirikiano bora na K8s, hakuna vyombo visivyohitajika, inaunganishwa vizuri na GCP LB.
Kwa hivyo, chaguo likaanguka kwa Patroni.
Matokeo
Ni wakati wa kujumlisha kwa ufupi. Ndio, ulimwengu wa miundombinu ya IT umebadilika sana, na huu ni mwanzo tu. Na ikiwa kabla ya mawingu yalikuwa aina nyingine ya miundombinu, sasa kila kitu ni tofauti. Kwa kuongezea, uvumbuzi katika mawingu huonekana kila wakati, utaonekana na, labda, utaonekana tu kwenye mawingu na kisha tu, kwa juhudi za kuanza, watahamishiwa kwenye majengo.
Kama kwa SQL, SQL itaishi. Hii ina maana kwamba unahitaji kujua PostgreSQL na MySQL na uweze kufanya kazi nazo, lakini muhimu zaidi ni kuweza kuzitumia kwa usahihi.
Chanzo: mapenzi.com