Halo, warga Khabrovsk. Kelas ing klompok pisanan kursus diwiwiti dina iki . Ing babagan iki, kita pengin ngandhani babagan carane mbukak webinar ing kursus iki.
В kita ngomong babagan tantangan database SQL ing jaman awan lan Kubernetes. Ing wektu sing padha, kita ndeleng carane database SQL adaptasi lan mutasi ing pengaruh tantangan kasebut.
Webinar dianakake , Google Cloud Practice Delivery Manager at EPAM Systems.
Nalika wit-witan isih cilik...
Pisanan, ayo elinga kepiye pilihan DBMS diwiwiti ing pungkasan abad kepungkur. Nanging, iki ora bakal angel, amarga pilihan DBMS ing jaman kasebut diwiwiti lan rampung Oracle.
Ing pungkasan taun 90-an lan awal 2-an, ora ana pilihan nalika nerangake basis data skala industri. Ya, ana IBM DBXNUMX, Sybase lan sawetara database liyane sing teka lan lunga, nanging ing umum padha ora dadi ngelingke marang latar mburi Oracle. Patut, katrampilan para insinyur ing jaman kasebut ana gandhengane karo pilihan mung sing ana.
Oracle DBA kudu bisa:
- nginstal Oracle Server saka kit distribusi;
- Konfigurasi Oracle Server:
- init.ora;
- pamireng.ora;
- nggawe:
- papan meja;
- skema;
- pangguna;
- nindakake serep lan mulihake;
- nindakake monitoring;
- menehi hasil karo panjalukan suboptimal.
Ing wektu sing padha, ora ana syarat khusus saka Oracle DBA:
- bisa milih DBMS optimal utawa teknologi liyane kanggo nyimpen lan ngolah data;
- nyedhiyakake kasedhiyan dhuwur lan skalabilitas horisontal (iki ora mesthi dadi masalah DBA);
- kawruh apik babagan subyek, infrastruktur, arsitektur aplikasi, OS;
- mbukak lan mbongkar data, migrasi data antarane DBMS beda.
Umumé, yen kita pirembagan bab pilihan ing dina, iku meh podho pilihan ing toko Soviet ing pungkasan 80s:
Kita wektu
Wiwit iku, mesthi wit-witan wis thukul, donya wis owah, lan dadi kaya mangkene:
Pasar DBMS uga wis diganti, kaya sing bisa dideleng saka laporan paling anyar saka Gartner:
Lan ing kene kudu dicathet yen awan, sing popularitas saya tambah akeh, wis manggoni ceruk. Yen maca laporan Gartner sing padha, kita bakal weruh kesimpulan ing ngisor iki:
- Akeh pelanggan ana ing dalan kanggo mindhah aplikasi menyang awan.
- Teknologi anyar pisanan muncul ing méga lan dudu kasunyatan manawa bakal pindhah menyang infrastruktur non-awan.
- Model rega pay-as-you-go wis dadi umum. Saben uwong mung pengin mbayar apa sing digunakake, lan iki dudu tren, nanging mung minangka pratelan kasunyatan.
Apa saiki?
Dina iki kita kabeh ana ing awan. Lan pitakonan sing muncul kanggo kita yaiku pitakonan pilihan. Lan gedhe banget, sanajan kita mung ngomong babagan pilihan teknologi DBMS ing format On-premises. Kita uga wis ngatur layanan lan SaaS. Mangkono, pilihan mung dadi luwih angel saben taun.
Bebarengan karo pitakonan pilihan, ana uga faktor watesan:
- rega. Akeh teknologi isih biaya dhuwit;
- katrampilan. Yen kita ngomong babagan piranti lunak gratis, mula ana pitakonan babagan katrampilan, amarga piranti lunak gratis mbutuhake kompetensi sing cukup saka wong sing nyebarake lan ngoperasikake;
- fungsional. Ora kabeh layanan sing kasedhiya ing maya lan dibangun, ngandika, malah ing Postgres padha, duwe fitur padha Postgres On-premises. Iki minangka faktor penting sing kudu dingerteni lan dingerteni. Kajaba iku, faktor iki dadi luwih penting tinimbang kawruh babagan sawetara kemampuan sing didhelikake saka DBMS siji.
Apa sing dikarepake saka DA / DE saiki:
- pemahaman sing apik babagan area subyek lan arsitektur aplikasi;
- kemampuan kanggo milih teknologi DBMS sing cocog, kanthi njupuk tugas sing ana ing tangan;
- kemampuan kanggo milih cara sing paling optimal kanggo ngetrapake teknologi sing dipilih ing konteks watesan sing ana;
- kemampuan kanggo nindakake transfer data lan migrasi;
- kemampuan kanggo ngleksanakake lan ngoperasikake solusi sing dipilih.
Ing ngisor conto adhedhasar GCP nduduhake cara pilihan siji utawa teknologi liyane kanggo nggarap data gumantung saka strukture:
Elinga yen PostgreSQL ora kalebu ing skema, lan iki amarga didhelikake ing terminologi. Cloud SQL. Lan nalika kita tekan Cloud SQL, kita kudu nggawe pilihan maneh:
Perlu dicathet yen pilihan iki ora mesthi jelas, mula pangembang aplikasi asring dipandu dening intuisi.
Total:
- Luwih sampeyan pindhah, luwih akeh pitakonan pilihan. Lan sanajan sampeyan mung katon ing GCP, layanan ngatur lan SaaS, banjur sawetara sebutno RDBMS katon mung ing langkah 4 (lan ana Spanner cedhak). Kajaba iku, pilihan PostgreSQL katon ing langkah 5, lan ing jejere ana uga MySQL lan SQL Server, yaiku ana akeh kabeh, nanging sampeyan kudu milih.
- Kita kudu ora lali babagan watesan babagan latar mburi godaan. Sejatine saben wong pengin Spanner, nanging larang. Akibaté, panjalukan khas katon kaya iki: "Mangga nggawe kita Spanner nanging kanggo rega Cloud SQL, sampeyan profesional!"
Nanging apa sing kudu ditindakake?
Tanpa ngaku minangka bebener sing paling utama, ayo ngomong ing ngisor iki:
Kita kudu ngganti pendekatan kanggo sinau:
- ora ana gunane kanggo mulang cara DBA diwulang sadurunge;
- kawruh babagan siji produk ora cukup maneh;
- nanging ngerti Welasan ing tingkat siji iku mokal.
Sampeyan kudu ngerti ora mung lan ora sepira produk kasebut, nanging uga:
- kasus nggunakake aplikasi sawijining;
- cara penyebaran beda;
- kaluwihan lan cacat saben cara;
- produk padha lan alternatif kanggo nggawe pilihan informed lan optimal lan ora tansah ing sih saka produk menowo.
Sampeyan uga kudu bisa migrasi data lan ngerti prinsip dhasar integrasi karo ETL.
Kasus nyata
Ing jaman kepungkur, perlu nggawe backend kanggo aplikasi seluler. Nalika karya diwiwiti, backend wis dikembangake lan siap kanggo implementasine, lan tim pangembangan ngenteni rong taun kanggo proyek iki. Tugas ing ngisor iki disetel:
- mbangun CI/CD;
- mriksa arsitektur;
- sijine kabeh menyang operasi.
Aplikasi kasebut yaiku microservices, lan kode Python / Django dikembangake saka awal lan langsung ing GCP. Kanggo pamirsa target, dianggep bakal ana rong wilayah - AS lan EU, lan lalu lintas disebarake liwat Global Load balancer. Kabeh Beban Kerja lan beban kerja komputasi mlaku ing Google Kubernetes Engine.
Dene dhata kasebut ana 3 struktur:
- Cloud Storage;
- Datastore;
- Cloud SQL (PostgreSQL).
Siji bisa uga mikir kenapa Cloud SQL dipilih? Ngomong sing bener, pitakonan kaya ngono wis nyebabake sawetara ngaso sing kikuk ing taun-taun pungkasan - ana perasaan yen wong wis dadi isin babagan database relasional, nanging tetep aktif digunakake ;-).
Kanggo kasus kita, Cloud SQL dipilih amarga alasan ing ngisor iki:
- Kaya kasebut, aplikasi iki dikembangaké nggunakake Django, lan wis model kanggo pemetaan data ngengkel saka database SQL kanggo obyek Python (Django ORM).
- Kerangka kasebut dhewe ndhukung dhaptar DBMS sing cukup winates:
- PostgreSQL;
- MariaDB;
- MySQL;
- pitutur;
- SQLite
Mulane, PostgreSQL dipilih saka dhaptar iki kanthi intuisi (uga, dudu Oracle sing kudu dipilih).
Apa sing ilang:
- aplikasi iki disebarake mung ing 2 wilayah, lan 3rd muncul ing plans (Asia);
- Basis data dumunung ing wilayah Amérika Lor (Iowa);
- ing bagean saka customer ana uneg-uneg babagan bisa telat akses saka Eropah lan Asia lan gangguan ing layanan ing kasus downtime DBMS.
Senadyan kasunyatan manawa Django dhewe bisa nggarap sawetara database kanthi podo karo lan dibagi dadi maca lan nulis, ora ana tulisan akeh ing aplikasi kasebut (luwih saka 90% maca). Lan umume, lan umume, yen bisa ditindakake replika waca basis utama ing Eropah lan Asia, iki bakal dadi solusi kompromi. Nah, apa sing rumit babagan iki?
Kangelan yaiku pelanggan ora pengin nyerah nggunakake layanan sing dikelola lan Cloud SQL. Lan kapabilitas Cloud SQL saiki diwatesi. Cloud SQL ndhukung kasedhiyan dhuwur (HA) lan Read Replica (RR), nanging RR sing padha mung didhukung ing sak wilayah. Sawise nggawe database ing wilayah Amerika, sampeyan ora bisa nggawe replika maca ing wilayah Eropa nggunakake Cloud SQL, sanajan Postgres dhewe ora nyegah sampeyan nindakake iki. Korespondensi karo karyawan Google ora ana ing endi wae lan dipungkasi kanthi janji kanthi gaya "kita ngerti masalah kasebut lan lagi nggarap, ing sawijining dina masalah kasebut bakal dirampungake."
Yen kita dhaptar kapabilitas Cloud SQL kanthi ringkes, bakal katon kaya iki:
1. kasedhiyan dhuwur (HA):
- ing siji wilayah;
- liwat replikasi disk;
- Mesin PostgreSQL ora digunakake;
- kontrol otomatis lan manual bisa - failover / failback;
- Nalika ngoper, DBMS ora kasedhiya kanggo sawetara menit.
2. Wacan Replika (RR):
- ing siji wilayah;
- siyaga panas;
- PostgreSQL streaming replikasi.
Kajaba iku, kaya biasane, nalika milih teknologi sampeyan mesthi ngadhepi sawetara watesan:
- customer ora pengin nggawe entitas lan nggunakake IaaS, kajaba liwat GKE;
- pelanggan ora seneng masang PostgreSQL / MySQL;
- Umume, Google Spanner bakal cocog yen ora ana regane, nanging Django ORM ora bisa digunakake, nanging pancen apik.
Ngelingi kahanan kasebut, pelanggan nampa pitakon tindak lanjut: "Apa sampeyan bisa nindakake sing padha supaya kaya Google Spanner, nanging uga bisa digunakake karo Django ORM?"
Pilihan solusi No. 0
Bab pisanan sing teka ing pikiran:
- tetep ing CloudSQL;
- ora bakal ana replikasi sing dibangun ing antarane wilayah ing wangun apa wae;
- nyoba masang replika menyang Cloud SQL sing wis ana dening PostgreSQL;
- miwiti conto PostgreSQL nang endi wae lan piye wae, nanging paling ora ndemek master.
Alas, ternyata iki ora bisa ditindakake, amarga ora ana akses menyang host (ing proyek sing beda kabeh) - pg_hba lan liya-liyane, lan uga ora ana akses ing superuser.
Pilihan solusi No. 1
Sawise refleksi luwih lanjut lan njupuk menyang akun kahanan sadurunge, sepur pikiran diganti rada:
- Kita isih nyoba tetep ing CloudSQL, nanging kita ngalih menyang MySQL, amarga Cloud SQL dening MySQL duwe master eksternal, yaiku:
- minangka proxy kanggo MySQL eksternal;
- katon kaya conto MySQL;
- diciptakake kanggo migrasi data saka awan liyane utawa On-premise.
Wiwit nyiyapake replikasi MySQL ora mbutuhake akses menyang host, ing asas kabeh bisa, nanging banget ora stabil lan ora trep. Lan nalika kita tindak luwih, iku dadi rampung medeni, amarga kita tugasaken kabeh struktur karo terraform, lan dumadakan ternyata master external ora didhukung dening terraform. Ya, Google duwe CLI, nanging sakperangan alesan kabeh bisa digunakake ing kene - kadhangkala digawe, kadhangkala ora digawe. Mungkin amarga CLI diciptakake kanggo migrasi data eksternal, lan ora kanggo replika.
Bener, ing wektu iki dadi jelas yen Cloud SQL ora cocog. Nalika padha ngomong, kita nindakake kabeh sing bisa.
Pilihan solusi No. 2
Amarga ora bisa tetep ing kerangka Cloud SQL, kita nyoba ngramu syarat kanggo solusi kompromi. Persyaratan kasebut katon ing ngisor iki:
- kerja ing Kubernetes, nggunakake maksimal sumber daya lan kemampuan Kubernetes (DCS, ...) lan GCP (LB, ...);
- lack ballast saka Bunch saka iku rasah ing maya kaya HA proxy;
- kemampuan kanggo mbukak PostgreSQL utawa MySQL ing wilayah HA utama; ing wilayah liyane - HA saka RR wilayah utama plus salinan (kanggo linuwih);
- multi master (Aku ora pengin ngubungi dheweke, nanging ora penting banget)
.
Minangka asil panjaluk kasebut, pDBMS cocok lan opsi naleni:
- MySQL Galera;
- CockroachDB;
- Piranti PostgreSQL
:
- pgpool-II;
- Patroni.
MySQL Galera
Teknologi MySQL Galera dikembangake dening Codership lan minangka plugin kanggo InnoDB. Kekhasan:
- multi master;
- replikasi sinkron;
- maca saka sembarang simpul;
- ngrekam menyang simpul apa wae;
- mekanisme HA dibangun ing;
- Ana grafik Helm saka Bitnami.
KecoakDB
Miturut katrangan, barang kasebut pancen bom lan minangka proyek sumber terbuka sing ditulis ing Go. Peserta utama yaiku Cockroach Labs (diadegake dening wong saka Google). DBMS relasional iki asline dirancang kanggo disebarake (kanthi skala horisontal metu saka kothak) lan fault-tolerant. Penulis saka perusahaan kasebut nemtokake tujuan "nggabungake kasugihan fungsionalitas SQL kanthi aksesibilitas horisontal sing akrab karo solusi NoSQL."
A bonus becik support kanggo protokol sambungan post-gress.
Pgpool
Iki minangka tambahan kanggo PostgreSQL, nyatane, entitas anyar sing njupuk kabeh sambungan lan ngolah. Nduwe load balancer lan parser dhewe, sing dilisensi ing lisensi BSD. Nyedhiyakake kesempatan sing akeh, nanging katon rada medeni, amarga anane entitas anyar bisa dadi sumber sawetara petualangan tambahan.
Patroni
Iki bab pungkasan mripatku tiba, lan, ternyata, ora muspra. Patroni minangka sarana open source, sing sejatine minangka daemon Python sing ngidini sampeyan njaga kluster PostgreSQL kanthi otomatis kanthi macem-macem jinis replikasi lan ngalih peran otomatis. Bab kasebut dadi menarik banget, amarga digabungake kanthi apik karo cuber lan ora ngenalake entitas anyar.
Apa sing sampeyan pilih ing pungkasan?
Pilihan ora gampang:
- KecoakDB - geni, nanging peteng;
- MySQL Galera - uga ora ala, digunakake ing akeh panggonan, nanging MySQL;
- Pgpool - akeh entitas sing ora perlu, integrasi karo awan lan K8;
- Patroni - integrasi banget karo K8s, ora entitas rasah, Integrasi uga karo GCP LB.
Mangkono, pilihan tiba ing Patroni.
temonan
Wektu kanggo nyimpulake kanthi ringkes. Ya, jagad infrastruktur IT wis owah sacara signifikan, lan iki mung wiwitan. Lan yen sadurunge awan mung minangka prasarana liyane, saiki kabeh wis beda. Kajaba iku, inovasi ing awan terus-terusan muncul, bakal katon lan, mbok menawa, mung bakal katon ing awan lan mung banjur, kanthi upaya wiwitan, bakal ditransfer menyang On-premises.
Kanggo SQL, SQL bakal urip. Iki tegese sampeyan kudu ngerti PostgreSQL lan MySQL lan bisa nggarap, nanging sing luwih penting yaiku bisa digunakake kanthi bener.
Source: www.habr.com