Kā SQL datubāze var izdzīvot 21. gadsimtā: mākoni, Kubernetes un PostgreSQL multimaster

Sveiki, Habrārieši. Šodien sākas nodarbības pirmajā kursa grupā. «PostgreSQL». Tāpēc mēs vēlamies pastāstīt jums par to, kā noritēja atklātais vebinārs par šo kursu.

No nākamajā atklātajā stundā runājām par to, ar kādiem izaicinājumiem SQL datu bāzes saskaras mākoņu un Kubernetes laikmetā. Turklāt aplūkojām, kā SQL datu bāzes pielāgojas un mainās šo izaicinājumu ietekmē.

Vebināru vadīja Valērijs Bezrukovs, Google Cloud Practice Delivery Manager uzņēmumā EPAM Systems.

Kad koki bija mazi...

Sāksim ar to, ka atceramies, kā pirmsākumos izvēlējāmies DBMS pagājušā gadsimta beigās. Tomēr tas nebūs grūti, jo izvēle DBMS tajos laikos sākās un beidzās Oracle.

90. gadu beigās – 00. gadu sākumā būtībā nebija īpaša izvēles, ja runājam par rūpnieciskām mērogojām datu bāzēm. Jā, pastāvēja IBM DB2, Sybase un vēl daži citi datu bāzu risinājumi, kas parādījās un pazuda, bet kopumā tie nebija tik redzami pret Oracle. Līdz ar to to laiku inženieru prasmes bija saistītas ar to vienīgo izvēli, kas pastāvēja.

Oracle DBA vajadzēja spēt:

• instalēt Oracle Server no izplatījuma;
• konfigurēt Oracle Server:

• init.ora;
• listener.ora;

– radīt:

• tabulu telpas;
• shēmas;
• lietotājus;

– veikt dublēšanu un atjaunošanu;
– veikt monitoringu;
– cīnīties ar neoptimāliem vaicājumiem.

Tomēr no Oracle DBA īpaši neprasīja:

• spēt izvēlēties optimālu DBMS vai citu datu glabāšanas un apstrādes tehnoloģiju;
• nodrošināt augstu pieejamību un horizontālo mērogojamību (tas ne vienmēr bija DBA jautājums);
• labi pārzināt priekšmetu jomu, infrastruktūru, lietojumprogrammu arhitektūru, OS;
• veikt datu ielādi un izlādi, migrāciju starp dažādām DBMS.

Ja runājam par izvēli tajos laikos, tā atgādināja izvēli padomju veikalā 80. gadu beigās:

Mūsu laiks

Kopš tā laika, protams, koki ir paaugušies, pasaule ir mainījusies, un tagad ir apmēram tā:

Ir mainījušās arī DBMS tirgus, ko labi parāda jaunā Gartner uzņēmuma ziņojums:

Šeit nevar nepieminēt, ka savu nišu ieņem mākoņi, kuru popularitāte pieaug. Ja izlasīsiet to pašu Gartner ziņojumu, mēs redzēsim šādus secinājumus:

1. Daudzi klienti ir ceļā uz lietojumprogrammu pārcelšanu mākoņos.
2. Jaunas tehnoloģijas vispirms parādās mākoņos, un nav skaidrs, vai tās vispār kādreiz pāries uz ne-mākoņa infrastruktūru.
3. Pay-as-you-go cenas noteikšanas modelis ir kļuvis ierasts. Visi vēlas maksāt tikai par to, ko izmanto, un tas jau nav pat trends, bet gan vienkārša fakta konstatācija.

Ko tagad?

Mūsdienās mēs visi esam mākoņos. Bet jautājumi, kas mums rodas, ir saistīti ar izvēli. Un tās ir plašas, pat ja runājam tikai par DBMS tehnoloģiju izvēli On-premises formātā. Turklāt mums ir arī pārvaldīti pakalpojumi un SaaS. Tādējādi izvēle katru gadu kļūst aizvien sarežģītāka.

Līdztekus izvēles jautājumiem darbojas arī ierobežojošie faktori:

• cena. Daudzas tehnoloģijas joprojām maksā naudu;
• prasmes. Runājot par brīvā programmatūra, rodas jautājums par prasmēm, jo bezmaksas programmatūra prasa no cilvēkiem, kuri to ievieš un ekspluatē, pietiekamu kompetenci;
• funkcionalitāte. Ne visiem pakalpojumiem, kas pieejami mākoņos un būvēti, piemēram, uz Postgres pamata, ir tās pašas iespējas kā Postgres On-premises. Tas ir būtisks faktors, kas jāzina un jāsaprot. Turklāt šis faktors iegūst vēl lielāku nozīmi nekā zināšanas par kādām noslēptām iespējām atsevišķai DBMS.

Ko pašlaik sagaida no DA/DE:

• labas izpratnes par tematu un pielietojuma arhitektūru;
• spēju pareizi izvēlēties atbilstošu DBMS tehnoloģiju, ņemot vērā uzdoto uzdevumu;
• spēju izveidot optimālo metodi izvēlētās tehnoloģijas īstenošanai esošo ierobežojumu kontekstā;
• spēju pārvietot un migrēt datus;
• spēju īstenot un ekspluatēt izvēlētos risinājumus.

Zemāk minētais piemērs uz GCP bāzes demonstrē, kā tiek veikta datu tehnoloģiju izvēle atkarībā no to struktūras:

Lūdzu, ņemiet vērā, ka shēmā nav PostgreSQL, jo tas slēpjas zem terminoloģijas Mākoņu SQL. Un kad mēs nonākam Cloud SQL, mums atkal jāveic izvēle:

Jāatzīmē, ka šī izvēle ne vienmēr ir skaidra, tādēļ lietojumprogrammošanas izstrādātāji bieži vadās pēc intuitīvas sajūtas.

Kopā:

1. Jo tālāk, jo aktuālāks kļūst izvēles jautājums. Un pat ja skatāmies tikai uz GCP, pārvaldītajiem pakalpojumiem un SaaS, tad kāds RDBMS pieminējums parādās tikai 4. solī (un tur blakus ir Spanner). Turklāt PostgreSQL izvēle parādās vispār tikai 5. solī, un tur blakus vēl ir MySQL un SQL Server, tas ir. Visam ir daudz, taču jāizvēlas..
2. Nedrīkst aizmirst par ierobežojumiem, kas parādās kā kārdinājumi. Pamatā visi grib Spanner, bet tas ir dārgs. Rezultātā tipisks pieprasījums izskatās apmēram šādi: „Lūdzu, izveidojiet mums Spanner, bet par Cloud SQL cenu, nu, jūs taču esat profesionāļi!”

Ko darīt?

Neizvirzot sevi par pēdējo patiesību, teiksim sekojošo:

Ir jāmaina pieeja mācīšanai:

• mācīt, kā iepriekš mācīja DBA, nav jēgas;
• zināšanas par vienu produktu šobrīd jau nav pietiekamas;
• bet pazīt desmitus vienā līmenī — nav iespējams.

Jāzina ne tikai un ne cik daudz par produktu, bet:

• tā pielietojuma gadījumi;
• dažādas izvietošanas metodes;
• katras metodes priekšrocības un trūkumi;
• līdzīgi un alternatīvi produkti, lai izdarītu apzinātu un optimālu izvēli un ne vienmēr par labu iepazītajam produktam.

Un vēl ir jāspēj migrēt datus un saprast pamata principus integrācijai ar ETL.

Reāls gadījums

Nesen nācās izveidot aizmuguri mobilai lietotnei. Pirms darba uzsākšanas aizmugure jau bija izstrādāta un gatava ieviešanai, un izstrādātāju komanda šo projektu izstrādāja apmēram divus gadus. Tika izvirzītas šādas uzdevumi:

• izveidot CI/CD;
• veikt arhitektūras pārskatu;
• palaist visu šo ekspluatācijā.

Pats lietotne bija mikroservisa, un kods tika izstrādāts Python/Django no nulles un uzreiz GCP. Attiecībā uz mērķauditoriju tika paredzēti divi reģioni — ASV un ES, un satiksme tika sadalīta caur globālo slodzes balansētāju. Visas slodzes un skaitļošanas jauda darbojās Google Kubernetes Engine.

Attiecībā uz datiem bija trīs struktūras:

• Cloud Storage;
• Datastore;
• Cloud SQL (PostgreSQL).

Var rasties jautājums, kāpēc tika izvēlēts Cloud SQL? Patiesību sakot, šāds jautājums pēdējos gados izraisa kādu neērtu pauzi — rodas sajūta, ka cilvēki kļuvuši kautrīgi par relāciju datu bāzēm, taču tās joprojām tiek aktīvi izmantotas ;-).

Attiecībā uz mūsu gadījumu Cloud SQL tika izvēlēts sekojošo iemeslu dēļ:

1. Kā jau minēts, lietotne tika izstrādāta ar Django, un tajā ir pastāvīgo datu attēlošanas modelis no SQL datu bāzes Python objektos (Django ORM).
2. Pats rīks atbalstīja pietiekami beigu CDB sarakstu:

• PostgreSQL;
• MariaDB;
• MySQL;
• Oracle;
• SQLite.

Attiecīgi, PostgreSQL tika izvēlēts no šī saraksta drīzāk instinktīvi (nu, ne jau Oracle taču izvēlēties, tiešām).

Kas trūka:

• lietotne tika izvērsta tikai 2 reģionos, bet plānos parādījās 3. (Āzija);
• DB atradās Ziemeļamerikas reģionā (Iowa);
• klienta pusē pastāvēja bažas par iespējamiem piekļuves aizkavējumiem no Eiropas un Āzijas un traucējumiem iekārtu apkalpošanā ja SUD būtu dīkstāve.

Lai gan pats Django var darboties ar vairākiem DB paralēli un dalīt tos pēc lasīšanas un rakstīšanas, ierakstu lietotnē nebija tik daudz (vairāk nekā 90 % — lasīšana). Kopumā, ja būtu iespējams izveidot read-repliku galvenajā datubāzē Eiropā un Āzijā, tas būtu kompromisa risinājums. Kas tur ir sarežģīts?

Bet sarežģītība bija tāda, ka klients nevēlējās atteikties no pārvaldītajām pakalpojumu programmām un Cloud SQL. Taču Cloud SQL iespējas šobrīd ir ierobežotas. Cloud SQL atbalsta augstu pieejamību (HA) un lasīšanas repliku (RR), bet tā pati RR tiek atbalstīta tikai vienā reģionā. Izveidojot DB Amerikas reģionā, nav iespējams izveidot lasīšanas repliku Eiropas reģionā, izmantojot Cloud SQL, lai gan pats Postgres to neierobežo. Sarakste ar Google darbiniekiem nekādu rezultātu nenesa un beidzās ar solījumiem „mēs zinām par problēmu un strādājam pie tās, kādreiz jautājums tiks atrisināts”.

Ja uzskaita Cloud SQL iespējas punktos, tad tās izskatīsies apmēram šādi:

1. Augsta pieejamība (HA):

• vienā reģionā;
• izmantojot diska repliku;
• netiek izmantoti PostgreSQL mehānismi;
• iespējama automātiska un manuāla pārvaldība — failover/failback;
• datubāzes pārslēgšanas laikā tā nav pieejama vairākas minūtes.

2. Lasīšanas replika (RR):

• vienā reģionā;
• karstā rezervācija;
• PostgreSQL straumēšanas replika.

Turklāt, kā jau ierasts, izvēloties tehnoloģiju, vienmēr saskaras ar dažādām ierobežojumiem:

• klients nevēlējās radīt entītus un izmantot IaaS, izņemot caur GKE;
• klients nevēlējās izvērst self service PostgreSQL/MySQL;
• un vispār, Google Spanner būtu pilnīgi piemērots, ja vien cena nebūtu tik augsta, tomēr ar to Django ORM nevar strādāt, taču tas ir labs risinājums.

Ņemot vērā situāciju, klients uzdeva negaidītu jautājumu: „Vai jūs varat izveidot kaut ko līdzīgu tam, lai tas būtu kā Google Spanner, bet darbināms arī ar Django ORM?”

Risinājuma variants Nr. 0

Pirmais, kas nāca prātā:

• palikt CloudSQL ietvaros;
• iebūvēta replikācija starp reģioniem nebūs nekādos veidos;
• mēģināt pievienot replikāciju esošajam Cloud SQL, izmantojot PostgreSQL;
• kur kādā brīdī sākt PostgreSQL instance, bet vismaz nemainīt master.

Diemžēl izrādījās, ka to izdarīt nevar, jo nav piekļuves hostam (tas vispār ir citā projektā) — pg_hba un tamlīdzīgi, un vēl nav piekļuves superlietotājam.

Risinājuma variants № 1

Pēc vēlreiz pārrunāšanas un ņemot vērā iepriekšējās apstākļu, domāšanas gaita nedaudz mainījās:

• vēl joprojām cenšamies palikt CloudSQL, bet pārejam uz MySQL, jo Cloud SQL, izmantojot MySQL, ir ārējais master, kurš:

— ir proxy ārējam MySQL;
— izskatās pēc MySQL instances;
— ir izstrādāts datu migrācijai no citiem mākoņiem vai On-premises.

Tā kā MySQL replikācijas iestatīšanai nav nepieciešama piekļuve hostam, principā viss strādāja, taču bija ļoti nestabils un neērts. Kad gājām tālāk, situācija palika patiešām biedējoša, jo mēs visu struktūru izveidojām ar terraform, bet izrādījās, ka ārējais master netiek atbalstīts ar terraform. Jā, Google ir CLI, bet kaut kāpēc arī tur viss strādāja ne visai stabilā kārtībā — reizēm izveidojas, reizēm ne. Iespējams, tāpēc, ka CLI tika izstrādāts datu migrācijai no ārpuses, nevis replikām.

Vairāk vai mazāk, tajā brīdī kļuva skaidrs, ka Cloud SQL vispār nav piemērots. Kā jau teikts, mēs izdarījuši visu, ko varējām.

Risinājuma variants № 2

Tā kā palikt Cloud SQL neizdevās, mēģinājām formulēt prasības kompromisa risinājumam. Prasības izrādījās šādas:

• darbs Kubernetes, maksimāla Kubernetes (DCS, …) un GCP (LB, …) resursu un iespēju izmantošana;
• nevajadzīgo lietu trūkums mākoņos, piemēram, HA proxy;
• iespēja palaist HA PostgreSQL vai MySQL galvenajā reģionā; citos reģionos — HA no galvenā reģiona RR plus tās kopija (uzticamībai);
• multi master (saistīties ar to negribējās, bet tas nebija ļoti būtiski)

.
Uz šo prasību fona beidzot parādījāspiemēroti DBMS un saistīšanas varianti:

• MySQL Galera;
• CockroachDB;
• PostgreSQL rīki

:
— pgpool-II;
— Patroni.

MySQL Galera

MySQL Galera tehnoloģiju izstrādājusi uzņēmums Codership un tā ir plugin for InnoDB. Īpašības:

• multi master;
• sinhronā replikācija;
• lasīt no jebkura mezgla;
• rakstīt uz jebkuru mezglu;
• iebūvēta HA mehānisms;
• ir Helm chart no Bitnami.

CockroachDB

Saskaņā ar aprakstu šī lieta ir pilnīgi lieliska un ir open source projekts, kas rakstīts Go valodā. Galvenais dalībnieks — Cockroach Labs (dibināta bijušajiem Google darbiniekiem). Šī relāciju datubāze sākotnēji izveidota kā izplatīta (ar horizontālo mērogošanu «no kastes») un izturīga pret kļūdām. Tās autori no uzņēmuma izvirzījuši mērķi «apvienot SQL bagātības funkcionalitāti ar horizontālo pieejamību, kas raksturīga NoSQL risinājumiem».

No patīkamā bonusa — atbalsts PostgreSQL pieslēgšanas protokolam.

Pgpool

Tas ir slānis virs PostgreSQL, patiesībā jauna būtība, kas uzņem visas pieslēgšanās un tās apstrādā. Tam ir savs slodzes balansētājs un parsers, tas licencēts saskaņā ar BSD licenci. Piedāvā plašas iespējas, taču izskatās nedaudz biedējoši, jo jaunas būtības esamība varētu radīt dažas papildu grūtības.

Patroni

Tas ir pēdējais, uz ko krita acs, un, izrādās, ne velti. Patroni — open-source rīks, kas būtībā ir demons Python valodā, kas ļauj automātiski apkalpot PostgreSQL klasterus ar dažādiem replikācijas veidiem un automātisku lomu pārslēgšanos. Šī lieta izrādījās ļoti interesanta, jo tā labi integrējas ar Kubernetes un nenes nekādas jaunas būtnes.

Kādu galu galā izvēlējās

Izvēle nebija viegla:

1. CockroachDB — uguns, bet biedējoši;
2. MySQL Galera — arī nav slikti, tiek plaši izmantots, bet MySQL;
3. Pgpool — daudz lieku būtnes, tāda kā integrācija ar mākoņiem un K8s;
4. Patroni — lieliska integrācija ar K8s, nav lieku būtnes, labi integrējas ar GCP LB.

Tādējādi izvēle krita uz Patroni.

Secinājumi

Ir pienācis laiks izdarīt īsus secinājumus. Jā, IT infrastruktūras pasaule ievērojami mainījusies, un tas ir tikai sākums. Ja iepriekš mākoņi bija tikai cits infrastruktūras veids, tad tagad viss ir savādāk. Vēl vairāk, inovācijas mākoņos parādās pastāvīgi, tās parādīsies un, iespējams, tās parādīsies tikai mākoņos un tikai pēc tam, pateicoties startupiem, tiks pārnestas uz On-premises.

Kas attiecas uz SQL, tad SQL turpinās dzīvot. Tas nozīmē, ka PostgreSQL un MySQL jāzina un jāspēj strādāt ar tām, bet vēl svarīgāk ir prast tās pareizi pielietot.

Avots: habr.com