Kumaha salamet database SQL dina abad ka-21: awan, Kubernetes sareng PostgreSQL multimaster

Halo, warga Khabrovsk. Kelas dina grup kahiji tina kursus dimimitian kiwari "PostgreSQL". Dina hal ieu, kami hoyong nyarioskeun ka anjeun kumaha webinar kabuka dina kursus ieu lumangsung.

В palajaran muka salajengna urang ngobrol ngeunaan tantangan database SQL nyanghareupan dina jaman awan na Kubernetes. Dina waktos anu sami, urang ningali kumaha database SQL adaptasi sareng mutasi dina pangaruh tantangan ieu.

webinar dilaksanakeun Valery Bezrukov, Manajer Pangiriman Praktek Google Cloud di EPAM Systems.

Nalika tangkal leutik ...

Mimiti, hayu urang émut kumaha pilihan DBMS dimimitian dina ahir abad ka tukang. Nanging, ieu moal sesah, sabab pilihan DBMS dina waktos éta mimiti sareng réngsé Oracle.

Dina ahir taun 90an sareng awal 2an, dasarna henteu aya pilihan nalika datang ka pangkalan data skala industri. Sumuhun, aya IBM DBXNUMX, Sybase sarta sababaraha databés séjén datang jeung indit, tapi sacara umum maranéhanana éta teu jadi noticeable ngalawan latar tukang Oracle. Sasuai, kaahlian insinyur jaman éta kumaha bae dihijikeun ka hijina pilihan nu aya.

Oracle DBA kedah tiasa:

• install Oracle Server tina kit distribution;
• Konpigurasikeun Oracle Server:

• init.ora;
• listener.ora;

- nyiptakeun:

• spasi méja;
• skéma;
• pamaké;

- ngalakukeun cadangan tur malikkeun;
- ngalaksanakeun monitoring;
- nungkulan requests suboptimal.

Dina waktos anu sami, teu aya sarat khusus ti Oracle DBA:

• bisa milih DBMS optimal atawa téhnologi séjén pikeun nyimpen jeung ngolah data;
• nyadiakeun kasadiaan tinggi na scalability horizontal (ieu teu salawasna masalah DBA);
• pangaweruh alus ngeunaan wewengkon poko, infrastruktur, arsitéktur aplikasi, OS;
• ngamuat jeung ngabongkar momotanana data, migrasi data antara DBMSs béda.

Sacara umum, lamun urang ngobrol ngeunaan pilihan dina mangsa éta, éta nyarupaan pilihan di toko Soviét dina 80s ahir:

Kami waktos

Saprak harita, tangtosna, tangkal geus tumuwuh, dunya geus robah, sarta eta jadi kawas kieu:

Pasar DBMS ogé parantos robih, sapertos anu jelas katingali tina laporan panganyarna ti Gartner:

Sarta di dieu eta kudu dicatet yén awan, anu popularitas tumuwuh, nempatan Ecological maranéhanana. Upami urang maca laporan Gartner anu sami, urang bakal ningali kasimpulan ieu:

1. Seueur palanggan nuju jalan pikeun mindahkeun aplikasi kana méga.
2. Téknologi anyar mimiti muncul dina awan sareng sanés kanyataan yén aranjeunna bakal kantos ngalih ka infrastruktur non-awan.
3. Modél harga pay-as-you-go geus jadi lumrah. Sarerea hayang mayar ngan pikeun naon maranéhna ngagunakeun, sarta ieu teu sanajan trend, tapi ngan hiji pernyataan kanyataan.

Naon ayeuna?

Dinten ieu urang sadayana dina awan. Sareng patarosan anu timbul pikeun urang mangrupikeun patarosan pilihan. Sareng éta ageung, sanaos urang ngan ukur nyarioskeun ngeunaan pilihan téknologi DBMS dina format Di tempat. Kami ogé parantos ngatur jasa sareng SaaS. Ku kituna, pilihan ngan jadi leuwih hese unggal taun.

Salian patarosan pilihan, aya ogé faktor ngawatesan:

• harga. Loba téknologi masih ngarugikeun duit;
• kaahlian. Upami urang nyarioskeun ngeunaan parangkat lunak gratis, maka timbul patarosan ngeunaan kaahlian, sabab parangkat lunak gratis peryogi kompeténsi anu cekap ti jalma anu nyebarkeun sareng ngoperasikeunana;
• fungsional. Henteu sakabéh jasa anu sadia dina awan tur diwangun, sebutkeun, sanajan dina Postgres sarua, boga fitur anu sarua sakumaha Postgres Dina enggon. Ieu mangrupikeun faktor penting anu kedah dipikanyaho sareng kahartos. Leuwih ti éta, faktor ieu jadi leuwih penting batan pangaweruh sababaraha kamampuhan disumputkeun tina hiji DBMS tunggal.

Naon anu dipiharep tina DA / DE ayeuna:

• pamahaman anu hadé ngeunaan daérah subjek sareng arsitéktur aplikasi;
• Kamampuhan pikeun leres milih téknologi DBMS anu luyu, kalayan nganggap tugas anu aya;
• kamampuan pikeun milih metodeu optimal pikeun nerapkeun téknologi anu dipilih dina konteks watesan anu aya;
• kamampuan pikeun mindahkeun data sareng migrasi;
• kamampuan pikeun nerapkeun sareng ngoperasikeun solusi anu dipilih.

Conto di handap dumasar kana GCP nunjukkeun kumaha pilihan hiji atanapi téknologi sanés pikeun damel sareng data tiasa dianggo gumantung kana strukturna:

Punten dicatet yén PostgreSQL henteu kalebet dina skéma, sareng ieu kusabab disumputkeun dina terminologi. Awan SQL. Sareng nalika urang dugi ka Cloud SQL, urang kedah milih deui:

Ieu kudu dicatet yén pilihan ieu teu salawasna jelas, jadi pamekar aplikasi mindeng dipandu ku intuisi.

total:

1. Beuki jauh anjeun, beuki pencét patarosan pilihan. Sareng upami anjeun ngan ukur ningali GCP, jasa anu diurus sareng SaaS, maka sababaraha nyebut RDBMS ngan ukur muncul dina léngkah ka-4 (sareng aya Spanner caket dieu). Tambih Deui, pilihan PostgreSQL muncul dina lengkah ka-5, sareng di gigireunana aya ogé MySQL sareng SQL Server, nyaéta aya loba sagalana, tapi anjeun kudu milih.
2. Urang teu kedah hilap ngeunaan larangan ngalawan latar tukang temptations. Dasarna sadayana hoyong Spanner, tapi éta mahal. Hasilna, hiji pamundut has kasampak kawas kieu: "Punten jantenkeun kami Spanner tapi pikeun harga Cloud SQL, anjeun profésional!"

Naon anu kedah abdi lakukeun?

Tanpa ngaku janten bebeneran pamungkas, hayu urang ucapkeun kieu:

Urang kedah ngarobih pendekatan kana diajar:

• teu aya gunana pikeun ngajarkeun cara diajarkeun DBA sateuacanna;
• pangaweruh ngeunaan hiji produk geus euweuh cukup;
• tapi nyaho puluhan di tingkat hiji mustahil.

Anjeun kedah terang henteu ngan ukur sabaraha produkna, tapi:

• kasus pamakéan aplikasi na;
• métode deployment béda;
• kaunggulan jeung kalemahan unggal métode;
• produk sarupa jeung alternatif pikeun nyieun hiji pilihan informed tur optimal sarta henteu salawasna dina ni'mat produk akrab.

Anjeun ogé kedah tiasa migrasi data sareng ngartos prinsip dasar integrasi sareng ETL.

Kasus nyata

Baheula panganyarna, perlu nyieun backend pikeun aplikasi mobile. Nalika damel di dinya, backend parantos dikembangkeun sareng siap pikeun palaksanaan, sareng tim pamekaran nyéépkeun dua taun pikeun proyék ieu. Tugas di handap ieu diatur:

• ngawangun CI / CD;
• marios arsitéktur;
• nempatkeun eta sadayana kana operasi.

Aplikasi sorangan éta microservices, sarta Python / kode Django dikembangkeun ti scratch tur langsung di GCP. Sedengkeun pikeun panongton targétna, éta dianggap yén bakal aya dua wewengkon - AS jeung EU, sarta lalulintas disebarkeun ngaliwatan Global Load balancer. Sadaya Beban Gawé sareng beban kerja ngitung dijalankeun dina Google Kubernetes Engine.

Sedengkeun pikeun data, aya 3 struktur:

• Panyimpenan awan;
• Datastore;
• Cloud SQL (PostgreSQL).

Anu tiasa heran naha Cloud SQL dipilih? Pikeun nyarioskeun kaleresan, patarosan sapertos kitu nyababkeun sababaraha jeda kagok dina taun-taun ayeuna - aya perasaan yén jalma-jalma janten isin ngeunaan pangkalan data relasional, tapi aranjeunna tetep aktip ngagunakeunana ;-).

Sedengkeun pikeun kasus urang, Cloud SQL dipilih pikeun alesan ieu:

1. Sakumaha didadarkeun di, aplikasi ieu dikembangkeun maké Django, sarta mibanda modél pikeun pemetaan data pengkuh tina database SQL pikeun objék Python (Django ORM).
2. Kerangka sorangan ngadukung daptar DBMS anu cukup terbatas:

• PostgreSQL;
• MariaDB;
• MySQL;
• oracles;
• SQLite.

Sasuai, PostgreSQL dipilih tina daptar ieu rada intuitif (saleresna, sanés Oracle milih, nyaan).

Naon anu leungit:

• aplikasi ieu deployed ngan di 2 wewengkon, sarta 3rd mucunghul dina rencana (Asia);
• database ieu lokasina di wewengkon Amérika Kalér (Iowa);
• dina bagian tina nasabah aya kasalempang mungkin aksés reureuh ti Éropa jeung Asia jeung interupsi dina layanan bisi DBMS downtime.

Sanaos kanyataan yén Django sorangan tiasa damel sareng sababaraha pangkalan data paralel sareng ngabagi kana bacaan sareng tulisan, teu aya seueur tulisan dina aplikasina (leuwih ti 90% nyaéta maca). Sarta sacara umum, sarta sacara umum, lamun éta mungkin pikeun ngalakukeun baca-replika pangkalan utama di Éropa sareng Asia, ieu bakal jadi solusi kompromi. Muhun, naon anu jadi pajeulit ngeunaan eta?

Kasusah éta yén nasabah henteu hoyong nyerah nganggo jasa anu diurus sareng Cloud SQL. Sareng kamampuan Cloud SQL ayeuna terbatas. Cloud SQL ngarojong kasadiaan High (HA) jeung Read Replica (RR), tapi RR sarua ngan dirojong dina hiji wewengkon. Saanggeus dijieun database di wewengkon Amérika, anjeun moal bisa nyieun replica dibaca di wewengkon Éropa ngagunakeun Cloud SQL, najan Postgres sorangan teu nyegah anjeun ngalakukeun ieu. Korespondensi sareng karyawan Google henteu kamana-mana sareng ditungtungan ku janji dina gaya "kami terang masalahna sareng nuju ngusahakeunana, hiji dinten masalahna bakal direngsekeun."

Upami urang daptar kamampuan Cloud SQL sakedap, éta bakal katingali sapertos kieu:

1. kasadiaan tinggi (HA):

• dina hiji wewengkon;
• via réplikasi disk;
• Mesin PostgreSQL henteu dianggo;
• kontrol otomatis tur manual mungkin - failover / failback;
• Nalika gentos, DBMS henteu sayogi sababaraha menit.

2. Baca Réplika (RR):

• dina hiji wewengkon;
• siaga panas;
• PostgreSQL réplikasi streaming.

Salaku tambahan, sakumaha adat, nalika milih téknologi anjeun sok disanghareupan sababaraha larangan:

• nasabah teu hayang nyieun éntitas sarta ngagunakeun IaaS, iwal ngaliwatan GKE;
• palanggan teu hoyong nyebarkeun layanan diri PostgreSQL / MySQL;
• Nya, sacara umum, Google Spanner bakal cocog upami sanés hargana, tapi Django ORM henteu tiasa damel sareng éta, tapi éta mangrupikeun hal anu saé.

Ningali kaayaan éta, palanggan nampi patarosan susulan: "Naha anjeun tiasa ngalakukeun anu sami supados sapertos Google Spanner, tapi ogé tiasa dianggo sareng Django ORM?"

Pilihan solusi No 0

Hal kahiji anu datang ka pikiran:

• tetep dina CloudSQL;
• moal aya réplikasi anu diwangun antara daérah dina bentuk naon waé;
• coba ngagantelkeun réplika ka Cloud SQL anu tos aya ku PostgreSQL;
• ngaluncurkeun conto PostgreSQL dimana waé sareng kumaha waé, tapi sahenteuna henteu toél master.

Alas, tétéla yén ieu teu bisa dipigawé, sabab euweuh aksés ka host (éta dina proyék béda sakabehna) - pg_hba jeung saterusna, sarta aya ogé euweuh aksés handapeun superuser.

Pilihan solusi No 1

Saatos réfléksi salajengna sareng tumut kana kaayaan samemehna, kareta pamikiran rada robih:

• Kami masih nyobian tetep dina CloudSQL, tapi urang ngalih ka MySQL, sabab Cloud SQL ku MySQL gaduh master éksternal, nyaéta:

- mangrupakeun proxy pikeun MySQL éksternal;
- Sigana mah conto MySQL;
- diciptakeun pikeun migrasi data tina méga sanés atanapi di tempat.

Kusabab nyetel réplikasi MySQL teu merlukeun aksés ka host, prinsipna mah sagalana digawé, tapi éta pisan teu stabilna jeung teu nyaman. Sareng nalika urang langkung jauh, éta janten pikasieuneun, sabab urang nyebarkeun sadayana struktur kalayan terraform, sareng ujug-ujug tétéla yén master éksternal henteu dirojong ku terraform. Leres, Google gaduh CLI, tapi pikeun sababaraha alesan sadayana damel di dieu unggal waktos - sakapeung diciptakeun, sakapeung henteu didamel. Panginten kusabab CLI diciptakeun pikeun migrasi data éksternal, sanés pikeun réplika.

Sabenerna, dina waktos ieu janten jelas yén Cloud SQL henteu cocog pisan. Sakumaha aranjeunna nyarios, urang ngalakukeun sadayana anu urang tiasa.

Pilihan solusi No 2

Kusabab teu mungkin tetep dina kerangka Cloud SQL, kami nyobian ngarumuskeun syarat pikeun solusi kompromi. Saratna tétéla kieu:

• gawé di Kubernetes, pamakéan maksimum sumberdaya jeung kamampuhan Kubernetes (DCS, ...) jeung GCP (LB, ...);
• kurangna ballast tina kebat hal teu perlu dina awan kawas HA proxy;
• kamampuhan pikeun ngajalankeun PostgreSQL atanapi MySQL di wewengkon HA utama; di wewengkon séjén - HA ti RR wewengkon utama ditambah salinan na (pikeun reliabilitas);
• multi master (Kuring henteu hoyong ngahubungi anjeunna, tapi éta henteu penting pisan)

.
Salaku hasil tina tungtutan ieu, pDBMS cocog sareng pilihan ngariung:

• MySQL Galera;
• CockroachDB;
• Alat PostgreSQL

:
- pgpool-II;
- Patroni.

MySQL Galera

Téknologi MySQL Galera dikembangkeun ku Codership sareng mangrupikeun plugin pikeun InnoDB. Keunikan:

• multi master;
• réplikasi sinkron;
• maca tina titik mana waé;
• ngarékam ka titik mana waé;
• mékanisme HA diwangun-di;
• Aya bagan Helm ti Bitnami.

cockroachDB

Numutkeun katerangan, hal éta leres-leres bom sareng mangrupikeun proyék open source anu ditulis dina Go. Pamilon utama nyaéta Cockroach Labs (diadegkeun ku jalma ti Google). DBMS relational ieu asalna dirancang pikeun disebarkeun (kalawan skala horizontal out of the box) jeung lepat-toleran. Panulisna ti perusahaan ngajelaskeun tujuan "ngagabungkeun kabeungharan fungsionalitas SQL sareng aksésibilitas horizontal anu akrab sareng solusi NoSQL."

Bonus anu saé nyaéta dukungan pikeun protokol sambungan post-gress.

Pgpool

Ieu mangrupikeun tambihan pikeun PostgreSQL, saleresna, éntitas énggal anu ngawasa sadaya sambungan sareng ngolahna. Éta gaduh kasaimbangan beban sareng parser sorangan, dilisensikeun ku lisénsi BSD. Éta nyayogikeun kasempetan anu ageung, tapi katingalina rada pikasieuneun, sabab ayana éntitas énggal tiasa janten sumber sababaraha petualangan tambahan.

Patroni

Ieu mangrupikeun hal anu terakhir ku panon kuring, sareng, tétéla, henteu sia-sia. Patroni mangrupikeun utilitas open source, anu dasarna mangrupikeun daemon Python anu ngamungkinkeun anjeun sacara otomatis ngajaga klaster PostgreSQL kalayan sababaraha jinis réplikasi sareng switching peran otomatis. Hal éta tétéla pisan metot, sabab integrates ogé kalawan cuber sarta henteu ngenalkeun sagala éntitas anyar.

Naon anu anjeun pilih dina tungtungna?

Pilihan éta henteu gampang:

1. cockroachDB - seuneu, tapi poék;
2. MySQL Galera - ogé teu goréng, dipaké di loba tempat, tapi MySQL;
3. Pgpool - loba éntitas teu perlu, kitu-kitu integrasi jeung awan na K8s;
4. Patroni - integrasi alus teuing jeung K8s, euweuh éntitas perlu, integrates ogé kalawan GCP LB.

Ku kituna, pilihan murag kana Patroni.

papanggihan

Geus waktuna nyimpulkeun sakeudeung. Leres, dunya infrastruktur IT parantos robih sacara signifikan, sareng ieu mangrupikeun awal. Tur upami sateuacan awan éta ngan tipe séjén infrastruktur, ayeuna sagalana geus béda. Sumawona, inovasi dina awan terus-terusan muncul, aranjeunna bakal muncul sareng, sigana, aranjeunna ngan ukur muncul dina méga sareng ngan ukur, ku usaha ngamimitian, aranjeunna bakal ditransferkeun ka On-premises.

Sedengkeun pikeun SQL, SQL bakal hirup. Ieu ngandung harti yén anjeun kedah terang PostgreSQL sareng MySQL sareng tiasa damel sareng aranjeunna, tapi anu langkung penting nyaéta tiasa dianggo kalayan leres.

sumber: www.habr.com