DBA bot Joe. Anatoly Stansler (Postgres.ai)

Kepiye pangembang backend ngerti manawa pitakon SQL bakal bisa digunakake kanthi apik ing "prod"? Ing perusahaan gedhe utawa berkembang kanthi cepet, ora saben wong duwe akses menyang "produk". Lan kanthi akses, ora kabeh panjalukan bisa dicenthang tanpa lara, lan nggawe salinan database asring mbutuhake jam. Kanggo ngatasi masalah kasebut, kita nggawe DBA buatan - Joe. Wis kasil dileksanakake ing sawetara perusahaan lan mbantu luwih saka rolas pangembang.

Video:

Halo kabeh! Jenengku Anatoly Stansler. Aku kerja ing perusahaan postgres.ai. Kita setya nyepetake proses pangembangan kanthi ngilangi wektu tundha sing ana gandhengane karo karya Postgres saka pangembang, DBA lan QA.

Kita duwe klien sing apik lan saiki bagean saka laporan kasebut bakal dikhususake kanggo kasus sing kita temoni nalika nggarap. Aku bakal ngomong babagan carane mbantu dheweke ngatasi masalah sing cukup serius.

Nalika kita ngembangake lan nindakake migrasi beban dhuwur sing rumit, kita takon dhewe: "Apa migrasi iki bakal mandheg?". Kita nggunakake review, kita nggunakake kawruh saka kolega liyane experienced, ahli DBA. Lan padha bisa ngomong apa bakal mabur utawa ora.

Nanging mbok menawa luwih apik yen kita bisa nyoba dhewe ing salinan ukuran lengkap. Lan dina iki kita mung bakal ngomong babagan pendekatan kanggo nyoba saiki lan kepiye carane bisa ditindakake kanthi luwih apik lan nganggo alat apa. Kita uga bakal ngomong babagan pro lan kontra saka pendekatan kasebut, lan apa sing bisa didandani ing kene.

Sapa sing nate nggawe indeks langsung ing prod utawa nggawe owah-owahan? Cukup sethithik. Lan kanggo sapa iki nyebabake kasunyatan manawa data ilang utawa ana downtime? Banjur sampeyan ngerti pain iki. Alhamdulillah ana serep.

Pendekatan pisanan yaiku tes ing prod. Utawa, nalika pangembang lenggah ing mesin lokal, wis data test, ana sawetara jinis pilihan winates. Lan kita muter metu kanggo prod, lan kita njaluk kahanan iki.

Lara, larang. Iku mbokmenawa paling apik ora.

Lan apa cara paling apik kanggo nindakake?

Ayo dadi pementasan lan pilih sawetara bagéan saka prod ana. Utawa paling apik, ayo njupuk prod nyata, kabeh data. Lan sawise dikembangake sacara lokal, kita uga bakal mriksa pementasan.

Iki bakal ngidini kita mbusak sawetara kasalahan, yaiku nyegah supaya ora ana ing prod.

Apa masalahe?

• Masalahe yaiku kita nuduhake pementasan iki karo kolega. Lan asring banget yen sampeyan nggawe sawetara owah-owahan, bam - lan ora ana data, karya kasebut mudhun. Pementasan ana multi-terabyte. Lan sampeyan kudu ngenteni suwene munggah maneh. Lan kita mutusake kanggo ngrampungake sesuk. Iku, kita duwe pembangunan.
• Lan, mesthi, kita duwe akeh kolega sing kerja ing kana, akeh tim. Lan kudu ditindakake kanthi manual. Lan iki ora trep.

Lan iku worth ngandika mung siji nyoba, siji dijupuk, yen kita pengin nggawe sawetara owah-owahan ing database, tutul data, ngganti struktur. Lan yen ana sing salah, yen ana kesalahan ing migrasi, mula kita ora bakal cepet mundur.

Iki luwih apik tinimbang pendekatan sadurungé, nanging isih ana kemungkinan dhuwur sing sawetara jenis kesalahan bakal menyang produksi.

Apa sing ngalangi kita menehi saben pangembang bangku test, salinan ukuran lengkap? Aku iki cetha apa nemu ing dalan.

Sapa sing duwe database luwih gedhe tinimbang terabyte? Luwih saka setengah kamar.

Lan cetha yen mesin tetep kanggo saben pangembang, nalika ana produksi gedhe, larang banget, lan uga butuh wektu sing suwe.

We duwe klien sing wis temen maujud sing iku penting banget kanggo nyoba kabeh owah-owahan ing salinan full-ukuran, nanging database kurang saka terabyte, lan ora ana sumber daya kanggo nyimpen bench test kanggo saben pangembang. Mulane, dheweke kudu ngundhuh dumps lokal menyang mesin lan nyoba kanthi cara iki. Butuh wektu akeh.

Malah yen sampeyan nindakake ing infrastruktur, banjur ngundhuh siji terabyte data saben jam wis apik banget. Nanging padha nggunakake dumps logis, padha download lokal saka méga. Kanggo wong-wong mau, kacepetan kira-kira 200 gigabyte saben jam. Lan isih butuh wektu kanggo nguripake saka mbucal logis, muter indeks, etc.

Nanging dheweke nggunakake pendekatan iki amarga ngidini supaya prod bisa dipercaya.

Apa sing bisa kita lakoni ing kene? Ayo nggawe bangku tes murah lan menehi saben pangembang bangku tes dhewe.

Lan iki bisa.

Lan ing pendekatan iki, nalika kita nggawe tiron tipis kanggo saben pangembang, kita bisa nuduhake ing siji mesin. Contone, yen sampeyan duwe database 10TB lan pengin menehi kanggo 10 gawe, sampeyan ora perlu duwe XNUMX x XNUMXTB database. Sampeyan mung butuh siji mesin kanggo nggawe salinan terisolasi tipis kanggo saben pangembang nggunakake siji mesin. Aku bakal pitutur marang kowe cara kerjane sethitik mengko.

Tuladha nyata:

• DB - 4,5 terabyte.

• Kita bisa entuk salinan independen sajrone 30 detik.

Sampeyan ora kudu ngenteni stand test lan gumantung saka ukurane. Sampeyan bisa njaluk ing detik. Bakal dadi lingkungan sing terisolasi, nanging nuduhake data ing antarane.

Iki apik. Ing kene kita ngomong babagan sihir lan alam semesta paralel.

Ing kasus kita, iki bisa digunakake kanthi nggunakake sistem OpenZFS.

OpenZFS minangka sistem file copy-on-write sing ndhukung snapshots lan kloning metu saka kothak. Iku dipercaya lan bisa diukur. Dheweke gampang banget diatur. Secara harfiah bisa disebarake ing rong tim.

Ana pilihan liyane:

• lvm,

• Panyimpenan (contone, Panyimpenan Murni).

Database Lab sing dakkandhakake yaiku modular. Bisa dileksanakake nggunakake opsi iki. Nanging saiki, kita wis fokus ing OpenZFS, amarga ana masalah karo LVM khusus.

Cara kerjane? Tinimbang nulis ulang data saben-saben kita ngganti, kita nyimpen kanthi mung menehi tandha yen data anyar iki saka titik wektu anyar, snapshot anyar.

Lan ing mangsa ngarep, nalika kita pengin mbalek maneh utawa kita pengin nggawe tiron anyar saka sawetara versi lawas, kita mung ngomong: "OK, wenehi pamblokiran data iki sing ditandhani kaya iki."

Lan pangguna iki bakal nggarap set data kasebut. Dheweke mboko sithik ngganti, nggawe jepretan dhewe.

Lan kita bakal cabang. Saben pangembang ing kasus kita bakal duwe kesempatan kanggo duwe klon dhewe sing diowahi, lan data sing dituduhake bakal dituduhake ing antarane kabeh wong.

Kanggo masang sistem kasebut ing omah, sampeyan kudu ngrampungake rong masalah:

• Kapisan yaiku sumber data, saka ngendi sampeyan bakal njupuk. Sampeyan bisa nyetel replikasi karo produksi. Sampeyan wis bisa nggunakake serep sing wis diatur, Mugi. WAL-E, WAL-G utawa Barman. Lan sanajan sampeyan nggunakake sawetara solusi Cloud kaya RDS utawa Cloud SQL, sampeyan bisa nggunakake dumps logis. Nanging kita isih menehi saran supaya sampeyan nggunakake serep, amarga kanthi pendekatan iki sampeyan uga bakal nahan struktur fisik file, sing bakal ngidini sampeyan luwih cedhak karo metrik sing bakal sampeyan deleng ing produksi supaya bisa nyekel masalah sing ana.

• Kapindho yaiku ing ngendi sampeyan pengin dadi tuan rumah Lab Database. Bisa uga Cloud, bisa uga On-premise. Penting kanggo ngomong ing kene yen ZFS ndhukung kompresi data. Lan iku cukup apik.

Bayangake manawa kanggo saben klon kasebut, gumantung saka operasi sing ditindakake ing basis, sawetara jinis dev bakal tuwuh. Kanggo iki, dev uga butuh ruang. Nanging amarga kasunyatan sing kita njupuk basis 4,5 terabyte, ZFS bakal compress menyang 3,5 terabyte. Iki bisa beda-beda gumantung saka setelan. Lan kita isih duwe ruang kanggo dev.

Sistem kasebut bisa digunakake kanggo macem-macem kasus.

• Iki minangka pangembang, DBA kanggo validasi pitakon, kanggo optimasi.

• Iki bisa digunakake ing testing QA kanggo nyoba migrasi tartamtu sadurunge kita muter metu kanggo prod. Lan kita uga bisa mundhakaken lingkungan khusus kanggo QA karo data nyata, ngendi padha bisa nyoba fungsi anyar. Lan bakal njupuk sawetara detik tinimbang ngenteni jam, lan bisa uga dina ing sawetara kasus liyane sing salinan tipis ora digunakake.

• Lan kasus liyane. Yen perusahaan ora duwe sistem analytics sing disetel, mula kita bisa ngisolasi klon tipis saka basis produk lan menehi pitakon dawa utawa indeks khusus sing bisa digunakake ing analytics.

Kanthi pendekatan iki:

1. Kemungkinan kesalahan kurang ing "prod", amarga kita nyoba kabeh owah-owahan ing data ukuran lengkap.

2. Kita duwe budaya nyoba, amarga saiki sampeyan ora kudu ngenteni jam kanggo ngadeg dhewe.

3. Lan ora ana alangan, ora ngenteni ing antarane tes. Sampeyan bener bisa pindhah lan mriksa. Lan bakal luwih apik kanthi cara iki amarga kita nyepetake pembangunan.

• Bakal ana kurang refactoring. Kurang kewan omo bakal mungkasi ing prod. Kita bakal refactor mau kurang mengko.

• Kita bisa mbalikke owah-owahan sing ora bisa dibatalake. Iki dudu pendekatan standar.

1. Iki mupangati amarga kita nuduhake sumber daya saka bangku tes.

Wis apik, nanging apa maneh sing bisa dicepetake?

Thanks kanggo sistem kasebut, kita bisa nyuda ambang kanggo mlebu tes kasebut.

Saiki ana bunder ganas ing ngendi pangembang kudu dadi ahli supaya bisa ngakses data ukuran lengkap sing nyata. Dheweke kudu dipercaya karo akses kasebut.

Nanging carane tuwuh yen ora ana. Nanging apa yen sampeyan mung duwe set data tes cilik sing kasedhiya kanggo sampeyan? Banjur sampeyan ora bakal entuk pengalaman nyata.

Kepiye carane metu saka bunder iki? Minangka antarmuka pisanan, trep kanggo pangembang saka sembarang tingkat, kita milih bot Slack. Nanging bisa dadi antarmuka liyane.

Apa sing ngidini sampeyan nindakake? Sampeyan bisa njupuk pitakon tartamtu lan ngirim menyang saluran khusus kanggo database. Kita bakal kanthi otomatis masang klon tipis ing sawetara detik. Ayo padha mbukak panjalukan iki. Kita ngumpulake metrik lan rekomendasi. Ayo nuduhake visualisasi. Banjur klone iki bakal tetep supaya pitakon iki bisa dioptimalake, nambah indeks, lsp.

Lan uga Slack menehi kita kesempatan kanggo kolaborasi metu saka kothak. Amarga iki mung saluran, sampeyan bisa miwiti ngrembug panjalukan iki ana ing thread kanggo panjaluk kasebut, ping kolega, DBA sing ana ing njero perusahaan.

Nanging ana, mesthi, masalah. Amarga iki donya nyata, lan kita nggunakake server hosting akeh turunan bebarengan, kita kudu compress jumlah memori lan daya CPU kasedhiya kanggo turunan.

Nanging supaya tes kasebut bisa dipercaya, sampeyan kudu ngatasi masalah iki.

Cetha yen titik penting yaiku data sing padha. Nanging kita wis duwe. Lan kita pengin entuk konfigurasi sing padha. Lan kita bisa menehi konfigurasi sing meh padha.

Iku bakal kelangan kanggo duwe hardware padha ing produksi, nanging bisa beda-beda.

Ayo dadi elinga carane Postgres dianggo karo memori. Kita duwe rong cache. Siji saka sistem file lan siji Postgres asli, yaiku Shared Buffer Cache.

Wigati dicathet menawa Shared Buffer Cache diparengake nalika Postgres diwiwiti, gumantung saka ukuran sing sampeyan nemtokake ing konfigurasi.

Lan cache kapindho nggunakake kabeh papan sing kasedhiya.

Lan nalika kita nggawe sawetara turunan ing siji mesin, dadi metu sing kita mboko sithik isi memori. Lan ing cara sing apik, Shared Buffer Cache 25% saka total memori sing kasedhiya ing mesin.

Lan ternyata yen ora ngganti parameter iki, kita bakal bisa mbukak mung 4 conto ing siji mesin, yaiku 4 saka kabeh klon tipis kasebut. Lan iki, mesthi, ala, amarga kita pengin duwe luwih akeh.

Nanging ing sisih liya, Buffer Cache digunakake kanggo nglakokake pitakon kanggo indeks, yaiku, rencana kasebut gumantung saka ukuran cache kita. Lan yen kita mung njupuk parameter iki lan nyuda, banjur rencana kita bisa diganti akeh.

Contone, yen kita duwe cache gedhe ing prod, banjur Postgres luwih seneng nggunakake indeks. Lan yen ora, banjur bakal ana SeqScan. Lan apa gunane yen rencana kita ora pas?

Nanging kene kita teka menyang kesimpulan sing nyatane rencana ing Postgres ora gumantung ing ukuran tartamtu kasebut ing Shared Buffer ing rencana, iku gumantung ing effective_cache_size.

Effective_cache_size minangka perkiraan jumlah cache sing kasedhiya kanggo kita, yaiku jumlah Cache Buffer lan cache sistem file. Iki diatur dening config. Lan memori iki ora diparengake.

Lan amarga parameter iki, kita bisa jenis trick Postgres, ngandika sing kita bener duwe akèh data kasedhiya, malah yen kita ora duwe data iki. Lan kanthi mangkono, rencana kasebut bakal cocog karo produksi.

Nanging iki bisa mengaruhi wektu. Lan kita ngoptimalake pitakon miturut wektu, nanging penting yen wektu gumantung ing akeh faktor:

• Iku gumantung ing beban sing saiki ing prod.

• Iku gumantung ing karakteristik saka mesin dhewe.

Lan iki minangka parameter ora langsung, nanging nyatane kita bisa ngoptimalake persis kanthi jumlah data sing bakal diwaca pitakon iki kanggo entuk asil.

Lan yen sampeyan pengin wektu cedhak karo apa sing bakal kita deleng ing prod, mula kita kudu njupuk hardware sing paling padha lan, bisa uga, luwih-luwih supaya kabeh klon pas. Nanging iki minangka kompromi, yaiku sampeyan bakal entuk rencana sing padha, sampeyan bakal weruh jumlah data sing bakal diwaca pitakon tartamtu lan sampeyan bakal bisa nyimpulake manawa pitakon iki apik (utawa migrasi) utawa ala, isih kudu dioptimalake. .

Ayo goleki carane Joe dioptimalake khusus.

Ayo njaluk panjaluk saka sistem nyata. Ing kasus iki, database 1 terabyte. Lan kita pengin ngetung jumlah kiriman anyar sing duwe luwih saka 10 seneng.

Kita nulis pesen menyang saluran kasebut, tiron wis disebarake kanggo kita. Lan kita bakal weruh manawa panjaluk kasebut bakal rampung sajrone 2,5 menit. Iki bab pisanan kita sok dong mirsani.

B Joe bakal nuduhake rekomendasi otomatis adhedhasar rencana lan metrik.

Kita bakal weruh yen pitakonan ngolah data akeh banget kanggo entuk jumlah baris sing relatif cilik. Lan sawetara jinis indeks khusus dibutuhake, amarga kita ngerteni manawa ana akeh baris sing disaring ing pitakon.

Ayo dideleng kanthi cetha apa sing kedadeyan. Pancen, kita weruh manawa kita wis maca meh siji lan setengah gigabyte data saka cache file utawa malah saka disk. Lan iki ora apik, amarga mung 142 baris.

Lan, misale jek, kita duwe pindai indeks ing kene lan kudu ditindakake kanthi cepet, nanging amarga kita nyaring akeh garis (kita kudu ngetung), panjaluk kasebut alon-alon.

Lan iki kedaden ing rencana amarga kasunyatan sing kondisi ing query lan kondisi ing indeks sebagian ora cocog.

Ayo dadi nyoba nggawe indeks luwih tepat lan ndeleng carane eksekusi query diganti sawise iku.

Nggawe indeks njupuk wektu sing cukup suwe, nanging saiki kita mriksa pitakon lan ndeleng manawa wektu tinimbang 2,5 menit mung 156 milidetik, sing cukup apik. Lan kita maca mung 6 megabyte data.

Lan saiki kita nggunakake indeks mung scan.

Crita penting liyane yaiku kita pengin nampilake rencana kasebut kanthi cara sing luwih bisa dingerteni. Kita wis ngetrapake visualisasi nggunakake Flame Graphs.

Iki minangka panjaluk sing beda, luwih kuat. Lan kita mbangun Flame Graphs miturut rong paramèter: iki jumlah data sing simpul tartamtu diitung ing rencana lan wektu, IE wektu eksekusi simpul.

Ing kene kita bisa mbandhingake simpul tartamtu karo saben liyane. Lan bakal cetha kang njupuk luwih utawa kurang, kang biasane angel kanggo nindakake ing cara Rendering liyane.

Mesthi, kabeh wong ngerti explain.depesz.com. Fitur apik saka visualisasi iki yaiku nyimpen rencana teks lan uga nglebokake sawetara paramèter dhasar menyang tabel supaya bisa diurutake.

Lan pangembang sing durung ngerti babagan topik iki uga nggunakake explain.depesz.com, amarga luwih gampang kanggo nemtokake metrik sing penting lan sing ora.

Ana pendekatan anyar kanggo visualisasi - iki explain.dalibo.com. Dheweke nggawe visualisasi wit, nanging angel banget kanggo mbandhingake simpul. Ing kene sampeyan bisa ngerti struktur kasebut kanthi becik, nanging yen ana panjaluk gedhe, mula sampeyan kudu nggulung maju lan maju, nanging uga ana pilihan.

kolaborasi

Lan, kaya sing dakkandhakake, Slack menehi kita kesempatan kanggo kolaborasi. Contone, yen kita nemokake pitakon rumit sing ora jelas carane ngoptimalake, kita bisa njlentrehake masalah iki karo kolega kita ing thread ing Slack.

Iku misale jek sing penting kanggo nyoba ing data ukuran lengkap. Kanggo nindakake iki, kita nggawe alat Update Database Lab, sing kasedhiya ing open source. Sampeyan uga bisa nggunakake bot Joe. Sampeyan bisa njupuk saiki lan ngleksanakake ing panggonan sampeyan. Kabeh panuntun kasedhiya ing kono.

Sampeyan uga penting kanggo dicathet yen solusi kasebut dhewe ora revolusioner, amarga ana Delphix, nanging minangka solusi perusahaan. Iku wis rampung ditutup, iku larang banget. Kita khusus ing Postgres. Iki kabeh produk open source. Gabung karo kita!

Iki ngendi aku mungkasi. Matur nuwun!

Pitakonan

Hello! Matur nuwun kanggo laporan! Apik banget, utamane kanggo aku, amarga aku wis ngrampungake masalah sing padha sawetara wektu kepungkur. Dadi aku duwe sawetara pitakonan. Muga-muga aku entuk paling ora bagean.

Aku wonder carane ngetung panggonan kanggo lingkungan iki? Teknologi kasebut tegese ing kahanan tartamtu, klon sampeyan bisa tuwuh nganti ukuran maksimal. Kira-kira, yen sampeyan duwe database sepuluh terabyte lan 10 klon, mula gampang kanggo simulasi kahanan sing saben klon bobote 10 data unik. Kepiye carane sampeyan ngetung panggonan iki, yaiku, delta sing sampeyan ucapake, ing ngendi klone kasebut bakal urip?

Pitakonan apik. Penting kanggo nglacak klon tartamtu ing kene. Lan yen klon duwe owah-owahan sing gedhe banget, mula tuwuh, mula kita bisa menehi peringatan marang pangguna babagan iki, utawa langsung mungkasi klone iki supaya ora ana kahanan sing gagal.

Ya, aku duwe pitakonan nested. Yaiku, kepiye sampeyan njamin siklus urip modul kasebut? Kita duwe masalah iki lan crita sing kapisah. Kepiye kedadeyan iki?

Ana sawetara ttl kanggo saben klon. Sejatine, kita duwe ttl tetep.

Apa, yen ora rahasia?

1 jam, i.e. nganggur - 1 jam. Yen ora digunakake, banjur kita bang. Nanging ora ana surprise ing kene, amarga kita bisa ngunggahake klon ing sawetara detik. Lan yen sampeyan butuh maneh, mangga.

Aku uga kasengsem ing pilihan teknologi, amarga, contone, kita nggunakake sawetara cara ing podo karo siji utawa alesan liyane. Kenapa ZFS? Apa sampeyan ora nggunakake LVM? Sampeyan kasebut yen ana masalah karo LVM. Apa masalahe? Ing mratelakake panemume, pilihan paling optimal karo panyimpenan, ing syarat-syarat kinerja.

Apa masalah utama karo ZFS? Kasunyatan yen sampeyan kudu mbukak ing host sing padha, yaiku kabeh kedadeyan bakal urip ing OS sing padha. Lan ing kasus panyimpenan, sampeyan bisa nyambungake macem-macem peralatan. Lan bottleneck mung pamblokiran sing ana ing sistem panyimpenan. Lan pitakonan saka pilihan teknologi menarik. Apa ora LVM?

Khusus, kita bisa ngrembug LVM ing meetup. Babagan panyimpenan - iku mung larang. Kita bisa ngleksanakake sistem ZFS ing ngendi wae. Sampeyan bisa nyebarake ing mesin sampeyan. Sampeyan mung bisa ndownload repositori lan nyebarake. ZFS diinstal meh ing endi wae yen kita ngomong babagan Linux. Yaiku, kita entuk solusi sing fleksibel banget. Lan ZFS dhewe menehi akeh metu saka kothak. Sampeyan bisa ngunggah data sing dikarepake, nyambungake akeh disk, ana jepretan. Lan, kaya sing dakkandhakake, gampang ngatur. Sing, misale jek banget penake kanggo nggunakake. Dheweke dites, umure wis pirang-pirang taun. Dheweke duwe komunitas sing akeh banget. ZFS minangka solusi sing bisa dipercaya.

Nikolai Samokhvalov: Apa aku bisa menehi komentar luwih lanjut? Jenengku Nikolay, kita kerja bareng karo Anatoly. Aku setuju yen panyimpenan gedhe. Lan sawetara pelanggan duwe Storage Pure etc.

Anatoly kanthi bener nyathet yen kita fokus ing modularitas. Lan ing mangsa ngarep, sampeyan bisa ngleksanakake siji antarmuka - njupuk gambar asli, nggawe tiron, numpes tiron. Kabeh iku gampang. Lan panyimpenan kelangan, yen iku.

Nanging ZFS kasedhiya kanggo kabeh wong. DelPhix wis cukup, duwe 300 klien. Saka jumlah kasebut, rejeki 100 duwe 50 klien, yaiku ditujokake menyang NASA, lsp. Wektune kabeh wong entuk teknologi iki. Lan mulane kita duwe Inti open source. Kita duwe bagean antarmuka sing ora mbukak sumber. Iki minangka platform sing bakal dituduhake. Nanging kita pengin bisa diakses kabeh wong. Kita pengin nggawe revolusi supaya kabeh penguji mandheg ngira ing laptop. Kita kudu nulis PILIH lan langsung weruh yen iku alon. Mungkasi ngenteni DBA ngandhani babagan iki. Punika goal utama. Lan aku mikir yen kita kabeh bakal teka ing iki. Lan kita nggawe bab iki kanggo saben wong. Mulane ZFS, amarga bakal kasedhiya ing endi wae. Thanks kanggo komunitas sing wis ngrampungake masalah lan duwe lisensi open source, lsp.*

salam! Matur nuwun kanggo laporan! Jenengku Maxim. Kita wis ngrampungake masalah sing padha. Dheweke mutusake dhewe. Kepiye sampeyan nuduhake sumber daya ing antarane klon kasebut? Saben klon bisa nindakake dhewe ing wektu tartamtu: siji nyoba siji bab, liyane liyane, wong mbangun indeks, wong duwe proyek abot. Lan yen sampeyan isih bisa dibagi dening CPU, banjur dening IO, carane dibagi? Iki pitakonan pisanan.

Lan pitakonan sing kapindho yaiku babagan bedane stand. Ayo dadi ngomong aku duwe ZFS kene lan kabeh iku kelangan, nanging klien ing prod ora duwe ZFS, nanging ext4, contone,. Carane ing kasus iki?

Pitakonan apik banget. Aku kasebut masalah iki dicokot karo kasunyatan sing kita nuduhake sumber daya. Lan solusi iki. Mbayangno yen sampeyan lagi nyoba ing pementasan. Sampeyan uga bisa duwe kahanan kaya ing wektu sing padha wong menehi siji mbukak, wong liya. Lan minangka asil, sampeyan ndeleng metrik sing ora bisa dingerteni. Malah masalah sing padha bisa karo prod. Yen sampeyan pengin mriksa sawetara panyuwunan lan sampeyan ndeleng manawa ana masalah - kerjane alon-alon, mula masalah kasebut ora ana ing panyuwunan kasebut, nanging ana sawetara jinis beban paralel.

Lan mulane, penting ing kene kanggo fokus babagan rencana kasebut, langkah-langkah apa sing bakal ditindakake ing rencana kasebut lan jumlah data sing bakal ditindakake. Kasunyatan bilih disk kita, contone, bakal dimuat karo soko, iku khusus bakal mengaruhi wektu. Nanging kita bisa ngira carane dimuat panjalukan iki dening jumlah data. Ora penting banget yen ing wektu sing padha bakal ana sawetara eksekusi.

Aku duwe rong pitakonan. Iki barang sing keren banget. Apa ana kasus nalika data produksi kritis, kayata nomer kertu kredit? Apa wis ana sing siap utawa tugas sing kapisah? Lan pitakonan kapindho - apa ana sing kaya iki kanggo MySQL?

Babagan data. Kita bakal nindakake obfuscation nganti kita nindakake. Nanging yen sampeyan nyebarake persis Joe, yen sampeyan ora menehi akses menyang pangembang, mula ora ana akses menyang data kasebut. Kenging punapa? Amarga Joe ora nuduhake data. Iku mung nuduhake metrik, rencana lan iku. Iki ditindakake kanthi sengaja, amarga iki minangka salah sawijining syarat klien kita. Dheweke pengin bisa ngoptimalake tanpa menehi akses kanggo kabeh wong.

Babagan MySQL. Sistem iki bisa digunakake kanggo apa wae sing nyimpen negara ing disk. Lan amarga kita nindakake Postgres, saiki kita nindakake kabeh otomatisasi kanggo Postgres dhisik. Kita pengin ngotomatisasi njupuk data saka serep. Kita ngatur Postgres kanthi bener. Kita ngerti carane nggawe rencana cocog, etc.

Nanging amarga sistem kasebut bisa diperluas, uga bisa digunakake kanggo MySQL. Lan ana conto kasebut. Yandex duwe perkara sing padha, nanging ora nerbitake ing endi wae. Dheweke nggunakake ing Yandex.Metrica. Lan mung ana crita babagan MySQL. Nanging teknologi padha, ZFS.

Matur nuwun kanggo laporan! Aku uga duwe sawetara pitakonan. Sampeyan nyatakake yen kloning bisa digunakake kanggo analytics, contone kanggo mbangun indeks tambahan ing kana. Bisa ngomong sethitik liyane babagan cara kerjane?

Lan aku bakal langsung takon pitakonan kapindho babagan podho saka stands, podho saka plans. Rencana kasebut uga gumantung marang statistik sing diklumpukake dening Postgres. Kepiye carane ngatasi masalah iki?

Miturut analytics, ora ana kasus tartamtu, amarga kita durung nggunakake, nanging ana kesempatan kasebut. Yen kita ngomong babagan indeks, banjur mbayangno yen query nguber tabel kanthi atusan yuta cathetan lan kolom sing biasane ora diindeks ing prod. Lan kita pengin ngetung sawetara data ing kana. Yen panyuwunan iki dikirim menyang prod, ana kemungkinan bakal gampang ing prod, amarga panyuwunan bakal diproses ing kono sajrone sawetara menit.

Ok, ayo nggawe klon tipis sing ora nggegirisi kanggo mandheg sawetara menit. Lan supaya luwih nyaman maca analytics, kita bakal nambah indeks kanggo kolom sing kita kasengsem ing data.

Indeks bakal digawe saben wektu?

Sampeyan bisa nggawe supaya kita ndemek data, nggawe jepretan, banjur kita bakal pulih saka gambar asli iki lan drive panjalukan anyar. Tegese, sampeyan bisa nggawe supaya sampeyan bisa ngunggahake klon anyar kanthi indeks sing wis ditempelake.

Kanggo pitakonan babagan statistik, yen kita mulihake saka serep, yen kita nindakake replikasi, banjur statistik kita bakal padha. Amarga kita duwe kabeh struktur data fisik, yaiku, kita bakal nggawa data kaya kabeh metrik statistik.

Punika masalah liyane. Yen sampeyan nggunakake solusi maya, banjur mung dump logis sing kasedhiya ing kana, amarga Google, Amazon ora ngidini sampeyan njupuk salinan fisik. Bakal ana masalah.

Matur nuwun kanggo laporan. Ana rong pitakonan sing apik babagan MySQL lan enggo bareng sumber daya. Nanging, ing kasunyatan, iku kabeh nerangake kasunyatan sing iki dudu topik DBMS tartamtu, nanging saka sistem file sakabèhé. Lan, kanthi mangkono, masalah enggo bareng sumber daya uga kudu dirampungake saka kono, ora ing mburi Postgres, nanging ing sistem file, ing server, umpamane.

Pitakonku rada beda. Iku luwih cedhak karo database multi-lapisan, ing ngendi ana sawetara lapisan. Contone, kita nyiyapake nganyari gambar sepuluh terabyte, kita replikasi. Lan kita khusus nggunakake solusi iki kanggo database. Replikasi lagi ditindakake, data lagi dianyari. Ana 100 karyawan sing kerja podo karo, sing terus-terusan ngluncurake tembakan sing beda-beda iki. Apa sing kudu ditindakake? Carane kanggo mesthekake yen ora ana konflik, sing padha dibukak siji, banjur sistem file diganti, lan gambar iki kabeh lunga?

Dheweke ora bakal lunga amarga kaya ngono ZFS. Kita bisa nyimpen kanthi kapisah ing siji utas owah-owahan sistem file amarga replikasi. Lan simpen klon sing digunakake pangembang ing versi data lawas. Lan kerjane kanggo kita, kabeh ana ing urutan iki.

Pranyata nganyari bakal njupuk Panggonan minangka lapisan tambahan, lan kabeh gambar anyar bakal pindhah wis, adhedhasar lapisan iki, tengen?

Saka lapisan sadurunge sing saka replikasi sadurunge.

Lapisan sadurunge bakal tiba, nanging bakal ngrujuk menyang lapisan lawas, lan bakal njupuk gambar anyar saka lapisan pungkasan sing ditampa ing nganyari?

Umumé, ya.

Banjur minangka akibat kita bakal duwe nganti anjir saka lapisan. Lan liwat wektu padha kudu dikompres?

Ya kabeh bener. Ana sawetara jendhela. Kita nyimpen jepretan mingguan. Iku gumantung ing sumber apa sampeyan duwe. Yen sampeyan duwe kemampuan kanggo nyimpen akeh data, sampeyan bisa nyimpen jepretan kanggo dangu. Dheweke ora bakal lunga dhewe. Ora bakal ana korupsi data. Yen jepretan wis ketinggalan jaman, kaya sing katon, yaiku gumantung saka kabijakan ing perusahaan, mula kita mung bisa mbusak lan mbebasake ruang.

Halo, matur nuwun kanggo laporan! Pitakonan babagan Joe. Sampeyan ujar manawa pelanggan ora pengin menehi kabeh akses menyang data kasebut. Tegese, yen wong duwe asil saka Explain Analyze, banjur bisa ngintip data.

Kaya ngono. Contone, kita bisa nulis: "PILIH FROM WHERE email = kanggo sing". Yaiku, kita ora bakal weruh data kasebut dhewe, nanging kita bisa ndeleng sawetara pratandha ora langsung. Iki kudu dimangerteni. Nanging ing sisih liya, kabeh ana. Kita duwe audit log, kita duwe kontrol kolega liyane sing uga ndeleng apa sing ditindakake para pangembang. Lan yen ana wong sing nyoba nindakake iki, layanan keamanan bakal teka lan ngupayakake masalah iki.

sugeng sonten Matur nuwun kanggo laporan! Aku duwe pitakonan singkat. Yen perusahaan ora nggunakake Slack, apa ana sing naleni saiki, utawa apa pangembang bisa nyebarake conto kanggo nyambungake aplikasi tes menyang database?

Saiki ana link menyang Slack, yaiku ora ana utusan liyane, nanging aku uga pengin nggawe dhukungan kanggo utusan liyane. Apa sing kowe iso? Sampeyan bisa masang DB Lab tanpa Joe, pindhah karo bantuan saka REST API utawa karo bantuan saka platform kita lan nggawe klon lan nyambung karo PSQL. Nanging iki bisa ditindakake yen sampeyan siyap menehi pangembang akses menyang data kasebut, amarga ora bakal ana layar maneh.

Aku ora butuh lapisan iki, nanging aku butuh kesempatan kasebut.

Banjur ya, bisa ditindakake.

Source: www.habr.com