Kadhangkala ing mangsa ngarep, mbusak otomatis data sing ora perlu bakal dadi salah sawijining tugas penting DBMS [1]. Ing sawetoro wektu, kita dhewe kudu ngurus mbusak utawa mindhah data sing ora perlu menyang sistem panyimpenan sing luwih murah. Contone, sampeyan arep mbusak sawetara yuta larik. Tugas sing cukup prasaja, utamane yen kondisi kasebut dikenal lan ana indeks sing cocog. "DELETE FROM table1 WHERE col1 = : value" - apa sing luwih gampang, ta?
Video:
-
Aku wis dadi panitia program Highload wiwit taun pisanan, yaiku wiwit taun 2007.
-
Lan aku wis karo Postgres wiwit 2005. Digunakake ing akeh proyek.
-
Klompok karo RuPostges uga wiwit 2007.
-
Kita wis tuwuh dadi 2100+ peserta ing Meetup. Iki nomer loro ing donya sawise New York, disusul San Francisco kanggo dangu.
-
Aku wis manggon ing California kanggo sawetara taun. Aku luwih akeh karo perusahaan Amerika, kalebu sing gedhe. Dheweke minangka pangguna aktif Postgres. Lan ana macem-macem perkara sing menarik.
iku perusahaanku. Kita ana ing bisnis ngotomatisasi tugas sing ngilangi kalem pembangunan.
Yen sampeyan nindakake apa-apa, mula kadhangkala ana sawetara jinis plug ing Postgres. Ayo dadi ngomong sampeyan kudu ngenteni admin kanggo nyiyapake test stand kanggo sampeyan, utawa sampeyan kudu ngenteni DBA nanggapi kanggo sampeyan. Lan kita nemokake bottlenecks kasebut ing proses pangembangan, tes lan administrasi lan nyoba ngilangi kanthi bantuan otomatisasi lan pendekatan anyar.
Aku bubar ing VLDB ing Los Angeles. Iki minangka konferensi paling gedhe babagan database. Lan ana laporan yen ing mangsa ngarep DBMS ora mung nyimpen, nanging uga kanthi otomatis mbusak data. Iki topik anyar.
Ana luwih akeh data ing donya zettabyte - yaiku 1 petabyte. Lan saiki wis kira-kira kita duwe luwih saka 000 zettabytes data sing disimpen ing donya. Lan ana liyane lan liyane.
Lan apa sing kudu dilakoni? Temenan kudu dicopot. Punika link kanggo laporan menarik iki. Nanging nganti saiki iki durung dileksanakake ing DBMS.
Sing bisa ngitung dhuwit pengin rong perkara. Dheweke pengin kita mbusak, mula kanthi teknis kita kudu bisa nindakake.
Apa sing bakal dakcritakake sabanjure yaiku sawetara kahanan abstrak sing kalebu akeh kahanan nyata, yaiku jinis kompilasi apa sing kedadeyan karo aku lan database ing saubengé kaping pirang-pirang, pirang-pirang taun. Rakes ana ing endi-endi lan saben wong mlaku ing kabeh wektu.
Ayo kita duwe basis utawa sawetara basis sing akeh. Lan sawetara cathetan sing jelas sampah. Contone, pangguna miwiti nindakake apa wae ing kana, nanging ora rampung. Lan sawise sawetara wektu, kita ngerti yen sing durung rampung iki ora bisa disimpen maneh. Yaiku, kita pengin ngresiki sawetara barang sampah supaya bisa ngirit papan, nambah kinerja, lsp.
Umumé, tugas kanggo ngotomatisasi mbusak barang tartamtu, garis tartamtu ing sawetara tabel.
Lan kita duwe panjaluk kasebut, sing bakal kita ucapake dina iki, yaiku, babagan mbusak sampah.
We takon pangembang experienced kanggo nindakaken. Dheweke njupuk panjaluk iki, mriksa dhewe - kabeh bisa digunakake. Dites ing pementasan - kabeh apik. Digulung metu - kabeh bisa. Sapisan dina kita mbukak - kabeh apik.
Basis data tuwuh lan tuwuh. DELETE saben dina wiwit mlaku rada alon.
Banjur kita ngerti manawa kita saiki duwe perusahaan pemasaran lan lalu lintas bakal kaping pirang-pirang luwih gedhe, mula kita mutusake kanggo ngaso sementara barang-barang sing ora perlu. Lan lali bali.
Sawetara sasi mengko padha kelingan. Lan sing pangembang mandhek utawa sibuk karo liyane, prentah liyane kanggo bali.
Dheweke mriksa dev, ing pementasan - kabeh OK. Alami, sampeyan isih kudu ngresiki apa sing akumulasi. Dheweke mriksa kabeh kerjane.
Apa sing kedadeyan sabanjure? Banjur kabeh tiba kanggo kita. Iku irungnya supaya ing sawetara titik kabeh tiba mudhun. Kabeh padha kaget, ora ana sing ngerti apa sing kedadeyan. Banjur pranyata ana ing DELETE iki.
Ana sing salah? Iki minangka dhaptar apa sing bisa salah. Endi sing paling penting?
-
Contone, ora ana review, yaiku ahli DBA ora ndeleng. Dheweke bakal langsung nemokake masalah kasebut kanthi mripat sing berpengalaman, lan saliyane, dheweke duwe akses menyang prod, ing ngendi sawetara yuta garis wis akumulasi.
-
Mungkin padha mriksa sing salah.
-
Mungkin hardware wis kuna lan sampeyan kudu nganyarke basis iki.
-
Utawa ana sing salah karo database dhewe, lan kita kudu pindhah saka Postgres menyang MySQL.
-
Utawa mungkin ana sing salah karo operasi.
-
Mungkin ana sawetara kesalahan ing organisasi kerja lan sampeyan kudu murub wong lan nyewa wong sing paling apik?
Ora ana mriksa DBA. Yen ana DBA, dheweke bakal weruh pirang-pirang yuta garis kasebut lan sanajan tanpa eksperimen bakal ujar: "Dheweke ora nindakake." Upaminipun yen kode iki ana ing GitLab, GitHub lan bakal ana proses review kode lan ora ana sing tanpa persetujuan DBA operasi iki bakal ditindakake ing prod, mula DBA bakal ujar: "Iki ora bisa ditindakake. .”
Lan dheweke bakal ngomong yen sampeyan bakal duwe masalah karo disk IO lan kabeh proses bakal edan, bisa uga ana kunci, lan uga sampeyan bakal mblokir autovacuum sajrone sawetara menit, mula iki ora apik.
Kesalahan kapindho - padha mriksa ing panggonan sing salah. Kita weruh sawise kasunyatan manawa akeh data sampah sing diklumpukake ing prod, nanging pangembang ora duwe data akumulasi ing database iki, lan ora ana sing nggawe sampah iki sajrone pementasan. Mulane, ana 1 baris sing cepet rampung.
Kita ngerti manawa tes kita lemah, yaiku proses sing dibangun ora entuk masalah. Eksperimen DB sing nyukupi ora ditindakake.
Eksperimen becik luwih becik ditindakake ing peralatan sing padha. Iku ora tansah bisa nindakake iki ing peralatan padha, nanging iku penting banget sing salinan ukuran lengkap saka database. Iki sing wis dakwartakaké nganti pirang-pirang taun. Lan setahun kepungkur aku ngomong babagan iki, sampeyan bisa nonton kabeh ing YouTube.
Mungkin peralatan kita ora apik? Yen katon, banjur latensi mlumpat. Kita wis weruh yen panggunaan 100%. Mesthi wae, yen iki minangka drive NVMe modern, mula bisa uga luwih gampang kanggo kita. Lan mungkin kita ora bakal mandheg.
Yen sampeyan duwe awan, mula upgrade gampang ditindakake ing kana. Ngunggah replika anyar ing hardware anyar. ngalih. Lan kabeh apik. Cukup gampang.
Apa bisa ndemek disk sing luwih cilik? Lan ing kene, mung kanthi bantuan DBA, kita nyilem menyang topik tartamtu sing diarani checkpoint tuning. Pranyata kita ora duwe checkpoint tuning.
Apa iku checkpoint? Iku ing sembarang DBMS. Yen sampeyan duwe data ing memori sing diganti, ora langsung ditulis menyang disk. Informasi sing data wis diganti pisanan ditulis ing nulis-ahead log. Lan ing sawetara titik, DBMS mutusake manawa wektune kanggo mbuwang kaca nyata menyang disk, supaya yen gagal, kita bisa nindakake kurang REDO. Kaya dolanan. Yen kita tiwas, kita bakal miwiti game saka checkpoint pungkasan. Lan kabeh DBMS ngleksanakake.
Setelan ing Postgres ketinggalan. Iki dirancang kanggo volume data lan transaksi 10-15 taun. Lan checkpoint ora pangecualian.
Iki informasi saka laporan mriksa Postgres kita, yaiku mriksa kesehatan otomatis. Lan iki sawetara database sawetara terabyte. Lan bisa dideleng manawa mriksa checkpoints ing meh 90% kasus.
Iki artine apa? Ana rong setelan ing kana. Checkpoint bisa teka kanthi wektu entek, contone, ing 10 menit. Utawa bisa uga teka nalika cukup akeh data wis diisi.
Lan kanthi standar max_wal_saze disetel dadi 1 gigabyte. Nyatane, iki pancene kedadeyan ing Postgres sawise 300-400 megabyte. Sampeyan wis ngganti akeh data lan checkpoint sampeyan kedadeyan.
Lan yen ora ana sing nyetel, lan layanan tansaya akeh, lan perusahaan entuk dhuwit akeh, wis akeh transaksi, banjur checkpoint rawuh sapisan menit, kadhangkala saben 30 detik, lan kadhangkala malah tumpang tindih. Iki cukup ala.
Lan kita kudu nggawe manawa teka kurang kerep. Sing, kita bisa ngunggahake max_wal_size. Lan bakal teka kurang kerep.
Nanging kita wis ngembangake kabeh metodologi babagan carane nindakake kanthi luwih bener, yaiku, carane nggawe keputusan babagan milih setelan, kanthi jelas adhedhasar data tartamtu.
Mulane, kita nindakake rong seri eksperimen ing basis data.
Seri pisanan - kita ngganti max_wal_size. Lan kita nindakake operasi massive. Pisanan, kita nindakake ing setelan gawan 1 gigabyte. Lan kita nindakake DELETE massive akeh yuta garis.
Sampeyan bisa ndeleng carane hard iku kanggo kita. Kita weruh yen disk IO ala banget. We ndeleng carane akeh WAL kita wis kui, amarga iki penting banget. Ayo ndeleng kaping pirang-pirang checkpoint. Lan kita ndeleng manawa ora apik.
Sabanjure kita nambah max_wal_size. We mbaleni. Kita nambah, kita mbaleni. Lan kakehan. Ing asas, 10 TCTerms apik, ngendi 1, 2, 4, 8 gigabyte. Lan kita ndeleng prilaku sistem tartamtu. Cetha yen ing kene peralatan kudu kaya ing prod. Sampeyan kudu duwe disk sing padha, jumlah memori sing padha, lan setelan Postgres sing padha.
Lan ing cara iki kita bakal ngganti sistem kita, lan kita ngerti carane DBMS bakal nindakake ing cilik saka massa ala DELETE, carane iku bakal checkpoint.
Checkpoint ing basa Rusia minangka checkpoints.
Conto: Mbusak sawetara yuta larik miturut indeks, larik "kasebar" ing kaca.
Punika conto. Iki sawetara dhasar. Lan kanthi setelan gawan 1 gigabyte kanggo max_wal_size, cetha banget yen disk kita menyang rak kanggo ngrekam. Gambar iki minangka gejala khas pasien sing lara banget, yaiku, dheweke pancen rumangsa ala. Lan ana siji operasi, mung ana DELETE sawetara yuta baris.
Yen operasi kuwi diijini ing prod, banjur kita mung bakal ngapusi mudhun, amarga iku cetha sing siji DELETE matèni kita ing beting.
Luwih, ngendi 16 gigabyte, iku cetha yen untu wis musna. Untu wis luwih apik, yaiku, kita nuthuk ing langit-langit, nanging ora dadi ala. Ana sawetara kamardikan ing kono. Ing sisih tengen ana rekaman. Lan jumlah operasi - grafik kapindho. Lan iku cetha sing kita wis AMBEGAN sethitik luwih gampang nalika 16 gigabyte.
Lan ing ngendi 64 gigabyte bisa dideleng yen wis dadi luwih apik. Wis untu pocapan, ana luwih kesempatan kanggo urip operasi liyane lan nindakake soko karo disk.
Napa ngene
Aku bakal nyilem menyang rincian sethitik, nanging topik iki, carane nindakake checkpoint tuning, bisa kasil laporan kabèh, supaya aku ora bakal mbukak akeh, nanging aku bakal njelaske nganggo bentuk garis sethitik apa kangelan ana.
Yen checkpoint kerep banget, lan kita nganyari baris kita ora sequentially, nanging golek dening indeks, kang apik, amarga kita ora mbusak kabeh tabel, banjur bisa kelakon sing pisanan ndemek kaca pisanan, banjur sewu, banjur bali menyang pisanan. Lan yen ing antarane kunjungan kasebut menyang kaca pisanan, checkpoint wis disimpen ing disk, mula bakal disimpen maneh, amarga kita wis reged kaping pindho.
Lan kita bakal meksa checkpoint kanggo nyimpen kaping pirang-pirang. Carane bakal ana operasi keluwih kanggo wong.
Nanging ora mung kuwi. Kaca yaiku 8 kilobyte ing Postgres lan 4 kilobyte ing Linux. Lan ana setelan full_page_writes. Diaktifake kanthi gawan. Lan iki bener, amarga yen kita mateni, banjur ana bebaya yen mung setengah saka kaca bakal disimpen yen tabrakan.
Prilaku nulis menyang WAL saka log maju yaiku nalika kita duwe checkpoint lan ngganti kaca kanggo pisanan, kabeh kaca, yaiku, kabeh 8 kilobyte, mlebu log maju, sanajan kita mung ngganti baris, sing bobote 100 bita. Lan kita kudu nulis kabeh kaca.
Ing owah-owahan sakteruse, mung bakal ana tuple tartamtu, nanging kanggo pisanan kita nulis kabeh.
Lan, miturut, yen checkpoint kedaden maneh, banjur kita kudu miwiti kabeh saka ngeruk maneh lan push kabeh kaca. Kanthi checkpoints sing kerep, nalika kita mlaku liwat kaca sing padha, full_page_writes = on bakal luwih akeh tinimbang sing bisa, yaiku kita ngasilake WAL luwih akeh. More dikirim menyang replika, menyang arsip, menyang disk.
Lan, miturut, kita duwe rong redundansi.
Yen kita nambah max_wal_size, iku dadi luwih gampang kanggo loro checkpoint lan wal writer. Lan sing apik.
Ayo sijine ing terabyte lan manggon karo. Apa sing ala? Iki ala, amarga yen gagal, kita bakal menek nganti pirang-pirang jam, amarga checkpoint wis suwe banget lan akeh sing wis diganti. Lan kita kudu nindakake kabeh REDO iki. Lan supaya kita nindakake seri kapindho eksperimen.
Kita nindakake operasi lan ndeleng nalika checkpoint bakal rampung, kita mateni -9 Postgres kanthi sengaja.
Lan sawise iku kita miwiti maneh, lan ndeleng suwene iku bakal munggah ing peralatan iki, IE pinten bakal REDO ing kahanan ala iki.
Kaping pindho aku bakal nyathet yen kahanan iku ala. Kaping pisanan, kita nabrak sakdurunge pos papriksan rampung, mula kita kudu kelangan akeh. Lan kapindho, kita duwe operasi massive. Lan yen checkpoints ana wektu entek, mesthine, kurang WAL bakal diasilake wiwit checkpoint pungkasan. Tegese, iku kapitunan pindho.
Kita ngukur kahanan kasebut kanggo macem-macem ukuran max_wal_size lan mangertos yen max_wal_size 64 gigabyte, banjur ing kasus kaping pindho, kita bakal menek 10 menit. Lan kita mikir apa cocog karo kita utawa ora. Iki minangka pitakonan bisnis. Kita kudu nuduhake gambar iki marang sing tanggung jawab kanggo keputusan bisnis lan takon, "Suwene kita bisa ngapusi paling akeh yen ana masalah? Apa kita bisa turu ing kahanan paling awon sajrone 3-5 menit? Lan sampeyan nggawe keputusan.
Lan ing kene ana titik sing menarik. Kita duwe sawetara laporan babagan Patroni ing konferensi kasebut. Lan mungkin sampeyan nggunakake. Iki minangka autofailover kanggo Postgres. GitLab lan Data Egret ngomong babagan iki.
Lan yen sampeyan duwe autofailover sing teka ing 30 detik, bisa uga kita bisa turu 10 menit? Amarga kita bakal ngalih menyang tiron ing titik iki, lan kabeh bakal nggoleki. Iki titik moot. Aku ora ngerti jawaban sing jelas. Aku mung rumangsa yen topik iki ora mung babagan pemulihan kacilakan.
Yen kita wis pulih suwe sawise gagal, mula kita bakal ora kepenak ing akeh kahanan liyane. Contone, ing eksperimen sing padha, nalika nindakake apa-apa lan kadhangkala kudu ngenteni 10 menit.
Aku isih ora bakal adoh banget, sanajan kita duwe autofailover. Minangka aturan, nilai kayata 64, 100 gigabyte minangka nilai sing apik. Kadhangkala malah worth milih kurang. Umumé, iki minangka ilmu subtle.
Kanggo nindakake iterasi, contone, max_wal_size = 1, 8, sampeyan kudu mbaleni operasi massa kaping pirang-pirang. Sampeyan digawe iku. Lan ing basis sing padha sampeyan pengin nindakake maneh, nanging sampeyan wis mbusak kabeh. Apa sing kudu ditindakake?
Aku bakal ngomong mengko babagan solusi kita, apa sing kita lakoni supaya bisa ngulang ing kahanan kaya ngono. Lan iki minangka pendekatan sing paling bener.
Nanging ing kasus iki, kita padha begja. Yen, kaya sing kasebut ing kene "MULAI, Mbusak, Mbalik maneh", mula kita bisa mbaleni DELETE. Tegese, yen kita mbatalake dhewe, banjur bisa mbaleni. Lan fisik ing sampeyan data bakal dumunung ing panggonan sing padha. Sampeyan malah ora kembung. Sampeyan bisa ngulang babagan DELETE kasebut.
DELETE karo ROLLBACK iki cocog kanggo nyetel checkpoint, sanajan sampeyan ora duwe laboratorium database sing dipasang kanthi bener.
Kita nggawe piring kanthi siji kolom "i". Postgres duwe kolom sarana. Dheweke ora katon kajaba dijaluk khusus. Iki minangka: ctid, xmid, xmax.
Ctid minangka alamat fisik. Kaca nol, tuple pisanan ing kaca.
Sampeyan bisa ndeleng sing sawise ROOLBACK tuple tetep ing panggonan sing padha. Yaiku, kita bisa nyoba maneh, bakal tumindak kanthi cara sing padha. Iki sing utama.
Xmax iku wektu mati tuple. Iki prangko, nanging Postgres mangerténi sing transaksi mbalek maneh, supaya ora Matter yen 0 utawa iku transaksi mbalek maneh. Iki nuduhake manawa bisa ngulang maneh DELETE lan mriksa operasi akeh saka prilaku sistem. Sampeyan bisa nggawe lab database kanggo wong miskin.
Iki babagan programer. About DBA, banget, padha tansah scold programer kanggo iki: "Yagene kowe nindakake operasi dawa lan angel?". Iki topik jejeg temen beda. Biyen ana administrasi, saiki bakal ana pembangunan.
Temenan, kita durung pecah dadi potongan. Wis cetha. Sampeyan ora bisa ngilangi DELETE kasebut kanggo tumpukan jutaan garis dadi bagean. Iku bakal rampung kanggo 20 menit, lan kabeh bakal ngapusi mudhun. Nanging, sayangé, malah pangembang sing berpengalaman nggawe kesalahan, sanajan ing perusahaan gedhe banget.
Apa penting kanggo break?
-
Yen kita weruh yen disk hard, banjur alon mudhun. Lan yen kita rusak, banjur kita bisa nambah jeda, kita bisa alon throttling.
-
Lan kita ora bakal ngalangi wong liya nganti suwe. Ing sawetara kasus, ora masalah, yen sampeyan mbusak sampah nyata sing ora ana sing nggarap, mesthine sampeyan ora bakal ngalangi sapa wae kajaba karya autovacuum, amarga bakal ngenteni transaksi rampung. Nanging yen sampeyan mbusak soko sing bisa dijaluk wong liya, mula bakal diblokir, bakal ana sawetara reaksi berantai. Transaksi dawa kudu dihindari ing situs web lan aplikasi seluler.
Iki menarik. Aku kerep ndeleng sing gawe takon: "Apa ukuran paket aku kudu milih?".
Cetha yen luwih gedhe ukuran bundel, luwih cilik overhead transaksi, yaiku, overhead tambahan saka transaksi. Nanging ing wektu sing padha, wektu mundhak kanggo transaksi iki.
Aku duwe aturan banget prasaja: njupuk minangka akeh sing bisa, nanging ora pindhah liwat executables saben detik.
Kenapa sedetik? Panjelasan kasebut gampang banget lan bisa dingerteni kabeh wong, sanajan wong non-teknis. Kita ndeleng reaksi. Ayo njupuk 50 milidetik. Yen ana owah-owahan, mripat kita bakal nanggepi. Yen kurang, banjur luwih angel. Yen ana sing nanggapi sawise 100 milliseconds, contone, sampeyan ngeklik mouse, lan mangsuli sampeyan sawise 100 milliseconds, sampeyan wis aran wektu tundha iki. Detik wis dianggep minangka rem.
Dadi, yen kita ngilangi operasi massa dadi bledosan 10 detik, mula kita duwe risiko yen bakal ngalangi wong liya. Lan bakal bisa kanggo sawetara detik, lan wong wis sok dong mirsani. Mulane, aku luwih seneng ora nindakake luwih saka detik. Nanging ing wektu sing padha, aja ngilangi kanthi apik, amarga overhead transaksi bakal katon. Dasar bakal luwih angel, lan masalah liyane bisa uga muncul.
Kita milih ukuran paket. Ing saben kasus, kita bisa nindakake kanthi beda. Bisa otomatis. Lan kita yakin babagan efisiensi pangolahan siji bungkus. Yaiku, kita Mbusak siji paket utawa UPDATE.
Oalah, kabeh sing dakkandhakake ora mung babagan DELETE. Kaya sing sampeyan bayangake, iki minangka operasi akeh ing data.
Lan kita ndeleng manawa rencana kasebut apik banget. Sampeyan bisa ndeleng pindai indeks, pindai mung indeks luwih apik. Lan kita duwe jumlah cilik saka data melu. Lan kurang saka detik nepaki. Super.
Lan kita isih kudu mesthekake yen ora ana degradasi. Mengkono yen paket pisanan cepet bisa, banjur dadi luwih elek, luwih elek lan luwih elek. Proses kaya ngono sampeyan kudu nyoba akeh. Iki persis apa laboratorium database kanggo.
Lan kita isih kudu nyiapake apa wae supaya bisa ngetutake iki kanthi bener ing produksi. Contone, kita bisa nulis wektu ing log, kita bisa nulis ing ngendi kita saiki lan sing saiki wis dibusak. Lan iki bakal ngidini kita ngerti apa sing kedadeyan mengko. Lan yen ana masalah, goleki masalah kasebut kanthi cepet.
Yen kita kudu mriksa efisiensi panjalukan lan kita kudu ngulang kaping pirang-pirang, mula ana sing kaya bot. Dheweke wis siyap. Iki digunakake dening puluhan pangembang saben dina. Lan ngerti carane menehi database terabyte ageng ing request ing 30 detik, salinan dhewe. Lan sampeyan bisa mbusak soko ana lan ngandika RESET, lan mbusak maneh. Sampeyan bisa eksprimen karo cara iki. Aku ndeleng masa depan kanggo perkara iki. Lan kita wis nglakoni.
Apa strategi partisi? Aku ndeleng 3 macem-macem strategi pemisahan sing digunakake para pangembang ing paket kasebut.
Sing pisanan prasaja banget. Kita duwe ID numerik. Lan ayo dipecah dadi interval sing beda-beda lan digarap. Kakurangan iku cetha. Ing bagean pisanan, kita bisa duwe 100 baris sampah nyata, ing kaloro 5 baris utawa ora kabeh, utawa kabeh 1 baris bakal dadi sampah. Karya sing ora rata, nanging gampang rusak. Dheweke njupuk ID maksimal lan ngrusak. Iki minangka pendekatan naif.
Strategi kapindho yaiku pendekatan sing seimbang. Iki digunakake ing Gitlab. Padha njupuk lan mindhai meja. Kita nemokake wates-wates paket ID supaya saben paket duwe 10 cathetan. Lan sijine wong ing antrian. Banjur kita proses. Sampeyan bisa nindakake iki ing pirang-pirang thread.
Ing strategi pisanan, uga, sampeyan bisa nindakake iki ing sawetara utas. Iku ora angel.
Nanging ana pendekatan sing luwih adhem lan luwih apik. Iki minangka strategi katelu. Lan yen bisa, luwih becik milih. Kita nindakake iki kanthi basis indeks khusus. Ing kasus iki, mesthine bakal dadi indeks miturut kondisi sampah lan ID kita. Kita bakal nyakup ID supaya minangka indeks mung pindai supaya ora menyang tumpukan.
Umumé, pindai mung indeks luwih cepet tinimbang pindai indeks.
Lan kita cepet nemokake ID sing pengin dibusak. BATCH_SIZE kita pilih luwih dhisik. Lan kita ora mung njaluk wong, kita njaluk wong ing cara khusus lan langsung hack wong. Nanging kita ngunci supaya yen wis dikunci, kita ora ngunci, nanging nerusake lan njupuk sing sabanjure. Iki kanggo nganyari skip dikunci. Fitur super Postgres iki ngidini kita bisa nggarap sawetara utas yen pengin. Bisa ing siji stream. Lan ing kene ana CTE - iki minangka panyuwunan. Lan kita duwe penghapusan nyata ing lantai loro CTE iki - returning *. Sampeyan bisa bali id, nanging luwih apik *yen sampeyan ora duwe akeh data ing saben baris.
Yagene kita butuh? Iki sing kudu kita laporake maneh. Saiki kita wis mbusak akeh garis nyatane. Lan kita duwe wates miturut ID utawa digawe_at kaya iki. Sampeyan bisa nindakake min, max. Ana liyane sing bisa ditindakake. Sampeyan bisa ngemot akeh ing kene. Lan trep banget kanggo ngawasi.
Ana siji cathetan liyane babagan indeks. Yen kita mutusake yen kita butuh indeks khusus kanggo tugas iki, mula kita kudu mesthekake yen ora ngrusak tumpukan mung nganyari tuple. Yaiku, Postgres duwe statistik kaya ngono. Iki bisa dideleng ing pg_stat_user_tables kanggo tabel sampeyan. Sampeyan bisa ndeleng manawa nganyari panas digunakake utawa ora.
Ana kahanan nalika indeks anyar sampeyan mung bisa dipotong. Lan sampeyan duwe kabeh nganyari liyane sing wis digunakake, alon mudhun. Ora mung amarga indeks katon (saben indeks slows mudhun nganyari sethitik, nanging sethitik), nanging kene isih ngrusak. Lan ora bisa nggawe optimasi khusus kanggo tabel iki. Iki kedadeyan kadhangkala. Iki minangka subtlety sing sawetara wong ngelingi. Lan rake iki gampang kanggo langkah. Kadhangkala kedadeyan sampeyan kudu golek pendekatan saka sisih liyane lan isih nindakake tanpa indeks anyar iki, utawa nggawe indeks liyane, utawa kanthi cara liya, contone, sampeyan bisa nggunakake cara liya.
Nanging iki minangka strategi sing paling optimal, carane dibagi dadi kelompok lan njupuk batch kanthi siji panyuwunan, mbusak sethithik, lsp.
Transaksi dawa
Autovakum sing diblokir -
masalah pamblokiran -
Kesalahan # 5 iku gedhe. Nikolai saka Okmeter ngomong babagan pemantauan Postgres. Pemantauan Postgres sing becik, sayangé, ora ana. Ana sing luwih cedhak, ana sing luwih adoh. Okmeter cukup cedhak kanggo sampurna, nanging akeh sing ilang lan kudu ditambahake. Sampeyan kudu siap kanggo iki.
Contone, tuple mati paling apik dipantau. Yen sampeyan duwe akeh barang mati ing meja, banjur ana sing salah. Iku luwih apik kanggo nanggepi saiki, yen ora ana degradasi, lan kita bisa ngapusi mudhun. Mengkono.
Yen ana IO gedhe, mula jelas yen iki ora apik.
Transaksi dawa uga. Transaksi dawa ngirim ora diijini ing OLTP. Lan iki minangka link menyang potongan sing ngidini sampeyan njupuk potongan iki lan wis nindakake sawetara nelusuri transaksi sing dawa.
Kenapa transaksi dawa ora apik? Amarga kabeh kunci bakal dirilis mung ing pungkasan. Lan kita meneng kabeh. Kajaba iku, kita mblokir autovacuum kanggo kabeh tabel. Iku ora apik banget. Sanajan sampeyan wis aktif siyaga panas ing tiron, iku isih ala. Umumé, ora ana sing luwih apik kanggo nyegah transaksi sing dawa.
Yen kita duwe akeh tabel sing ora vakum, mula kita kudu waspada. Ing kene kahanan kaya mengkono bisa. Kita ora langsung bisa mengaruhi operasi autovacuum. Iki minangka potongan saka Avito, sing rada saya apik. Lan dadi alat sing menarik kanggo ndeleng apa sing ana karo autovacuum. Contone, sawetara tabel nunggu ana lan ora bakal ngenteni giliran. Sampeyan uga kudu sijine ing ngawasi lan duwe tandha.
Lan masalah pamblokiran. Alas wit blok. Aku seneng njupuk soko saka wong lan nambah. Ing kene aku njupuk CTE rekursif sing keren saka Data Egret sing nuduhake alas wit kunci. Iki minangka alat diagnostik sing apik. Lan adhedhasar, sampeyan uga bisa mbangun pemantauan. Nanging iki kudu ditindakake kanthi ati-ati. Sampeyan kudu nggawe statement_timeout cilik kanggo sampeyan dhewe. Lan lock_timeout dikarepake.
Kadhangkala kabeh kesalahan kasebut kedadeyan ing jumlah.
Miturut pendapatku, kesalahan utama ing kene yaiku organisasi. Iku organisasi, amarga technique ora narik. Iki nomer 2 - padha mriksa ing panggonan salah.
Kita mriksa ing panggonan sing salah, amarga kita ora duwe klon produksi, sing gampang dipriksa. Pangembang bisa uga ora duwe akses menyang produksi.
Lan kita mriksa ora ana. Yen kita wis mriksa ana, kita bakal weruh dhewe. Pangembang weruh kabeh sanajan tanpa DBA yen dheweke mriksa ing lingkungan sing apik, ing ngendi ana jumlah data sing padha lan lokasi sing padha. Dheweke bakal weruh kabeh degradasi iki lan dheweke bakal isin.
Liyane babagan autovacuum. Sawise kita wis nindakake sapuan massive saka sawetara yuta baris, kita isih kudu nindakake REPACK. Iki penting banget kanggo indeks. Dheweke bakal rumangsa ala sawise kita ngresiki kabeh sing ana.
Lan yen sampeyan pengin mbalekake karya reresik saben dina, aku bakal menehi saran supaya luwih kerep, nanging luwih cilik. Bisa sapisan menit utawa malah luwih asring sethithik. Lan sampeyan kudu ngawasi rong perkara: manawa bab iki ora ana kesalahan lan ora ketinggalan. Trik sing aku nuduhake mung bakal ngrampungake iki.
Apa kita nindakake iku open source. Iki dikirim ing GitLab. Lan kita nggawe supaya wong bisa mriksa sanajan tanpa DBA. Kita nindakake lab database, yaiku, kita nyebut komponen dhasar sing saiki digunakake Joe. Lan sampeyan bisa njupuk salinan produksi. Saiki ana implementasine Joe kanggo slack, sampeyan bisa ngomong ana: "nerangake panjalukan kuwi lan kuwi" lan langsung entuk asil kanggo salinan database. Sampeyan bisa malah Mbusak ana, lan ora ana sing bakal sok dong mirsani.
Ayo dadi ngomong sampeyan duwe 10 terabyte, kita nggawe lab database uga 10 terabyte. Lan kanthi database 10 terabyte bebarengan, 10 pangembang bisa kerja bebarengan. Saben uwong bisa nindakake apa sing dikarepake. Bisa mbusak, nyelehake, lsp. Kuwi khayalan. Kita bakal ngomong babagan iki sesuk.
Iki diarani provisioning tipis. Iki minangka provisioning subtle. Iki minangka sawetara fantasi sing ngilangi wektu tundha pangembangan, nyoba lan nggawe jagad iki dadi papan sing luwih apik babagan iki. Yaiku, mung ngidini sampeyan ngindhari masalah karo operasi akeh.
Conto: database 5 terabyte, entuk salinan kurang saka 30 detik. Lan ora gumantung ing ukuran, yaiku, ora ketompo carane akeh terabyte.
Dina iki sampeyan bisa pindhah menyang lan digali menyang piranti kita. Sampeyan bisa ndhaptar kanggo ndeleng apa sing ana. Sampeyan bisa nginstal bot iki. Iku gratis. Tulis.
Pitakonan
Kerep banget ing kahanan nyata ternyata data sing kudu tetep ana ing tabel luwih sithik tinimbang sing kudu dibusak. Sing, ing kahanan kaya mengkono, iku asring luwih gampang kanggo ngleksanakake pendekatan kuwi, nalika iku luwih gampang kanggo nggawe obyek anyar, mung nyalin data perlu ana, lan trunk tabel lawas. Cetha yen pendekatan terprogram dibutuhake kanggo wektu iki, nalika sampeyan bakal ngalih. Carane pendekatan iki?
Iki minangka pendekatan sing apik banget lan tugas sing apik banget. Iku banget padha karo apa pg_repack, iku banget padha karo apa sing kudu dilakoni nalika nggawe ID 4 bita. Akeh frameworks nindakake iki sawetara taun kepungkur, lan mung piring wis thukul munggah, lan padha kudu diowahi kanggo 8 bait.
Tugas iki cukup angel. Kita nindakaken. Lan sampeyan kudu ati-ati banget. Ana kunci, lsp. Nanging lagi ditindakake. Yaiku, pendekatan standar yaiku nganggo pg_repack. Sampeyan ngumumake label kasebut. Lan sadurunge sampeyan miwiti ngunggah data snapshot menyang, sampeyan uga ngumumake siji piring sing nglacak kabeh owah-owahan. Ana trick sing bisa uga ora nglacak sawetara owah-owahan. Ana subtleties. Banjur sampeyan ngalih kanthi ngganti owah-owahan. Bakal ana jeda cendhak nalika kita nutup kabeh wong, nanging umume iki ditindakake.
Yen sampeyan ndeleng pg_repack ing GitHub, banjur ana, nalika ana tugas kanggo ngowahi ID saka int 4 dadi int 8, banjur ana gagasan kanggo nggunakake pg_repack dhewe. Iki uga bisa, nanging iku dicokot saka hack, nanging uga bisa kanggo iki. Sampeyan bisa campur ing pemicu sing pg_repack nggunakake lan ngandika ana: "Kita ora perlu data iki", IE mung nransfer apa kita kudu. Banjur dheweke mung ngalih lan iku.
Kanthi pendekatan iki, kita isih entuk salinan tabel kaping pindho, ing ngendi data kasebut wis diindeks lan ditumpuk banget kanthi indeks sing apik.
Bloat ora ana, iku pendekatan sing apik. Nanging aku ngerti manawa ana upaya kanggo ngembangake otomatisasi iki, yaiku nggawe solusi universal. Aku bisa nggawe sampeyan sesambungan karo otomatisasi iki. Iku ditulis ing Python, kang apik.
Aku mung sethitik saka donya MySQL, aku teka kanggo ngrungokake. Lan kita nggunakake pendekatan iki.
Nanging mung yen kita duwe 90%. Yen kita duwe 5%, mula ora apik banget kanggo nggunakake.
Matur nuwun kanggo laporan! Yen ora ana sumber daya kanggo nggawe salinan prod lengkap, apa ana algoritma utawa rumus kanggo ngitung beban utawa ukuran?
Pitakonan apik. Nganti saiki, kita bisa nemokake database multi-terabyte. Malah yen hardware ana ora padha, Contone, kurang memori, kurang prosesor lan disk ora persis padha, nanging isih kita nindakaken. Yen pancen ora ana, mula sampeyan kudu mikir. Ayo kula mikir nganti sesuk, sampeyan teka, kita bakal ngomong, iki pitakonan sing apik.
Matur nuwun kanggo laporan! Sampeyan pisanan miwiti babagan kasunyatan sing ana Postgres kelangan, kang wis watesan kuwi lan kuwi, nanging berkembang. Lan iki kabeh kruk umum. Apa ora kabeh iki konflik karo pangembangan Postgres dhewe, kang sawetara DELETE deferent bakal katon utawa liyane sing kudu tetep ing tingkat kurang apa kita nyoba kanggo smear karo sawetara cara aneh kita kene?
Yen kita ngandika ing SQL kanggo mbusak utawa nganyari akeh cathetan ing siji transaksi, banjur carane Postgres bisa disebaraké ana? Kita sacara fisik diwatesi ing operasi. Kita isih bakal nindakake kanggo dangu. Lan kita bakal ngunci ing wektu iki, etc.
Rampung karo indeks.
Aku bisa nganggep manawa tuning checkpoint padha bisa otomatis. Ing sawijining dina bisa uga. Nanging banjur aku ora ngerti pitakonan.
Pitakonan yaiku, apa ana vektor pangembangan sing ana ing kene, lan ing kene sampeyan dadi paralel? Sing. Apa dheweke durung mikir babagan iki?
Aku ngomong babagan prinsip sing bisa digunakake saiki. Ana bot liyane , kanthi iki sampeyan bisa nindakake tuning checkpoint otomatis. Apa bakal ana ing Postgres? Ora ngerti, malah durung dirembug. Kita isih adoh saka iku. Nanging ana ilmuwan sing nggawe sistem anyar. Lan padha nyurung kita menyang indeks otomatis. Ana pembangunan. Contone, sampeyan bisa ndeleng tuning otomatis. Iku milih paramèter kanthi otomatis. Nanging dheweke ora bakal nindakake checkpoint tuning kanggo sampeyan. Sing, iku bakal njupuk kanggo kinerja, shell buffer, etc.
Lan kanggo nyetel checkpoint, sampeyan bisa nindakake iki: yen sampeyan duwe sewu kluster lan hardware beda, mesin virtual beda ing méga, sampeyan bisa nggunakake bot kita nindakake otomatisasi. Lan max_wal_size bakal dipilih miturut setelan target sampeyan kanthi otomatis. Nanging nganti saiki iki ora malah cedhak ing inti, sayangé.
sugeng sonten Sampeyan ngomong bab bebaya saka transaksi dawa. Sampeyan ujar manawa autovacuum diblokir yen ana pambusakan. Kepiye carane bisa ngrusak kita? Amarga kita ngomong luwih akeh babagan mbebasake ruang lan bisa digunakake. Apa maneh sing ilang?
Autovacuum bisa uga dudu masalah paling gedhe ing kene. Lan kasunyatan manawa transaksi sing dawa bisa ngunci transaksi liyane, kemungkinan iki luwih mbebayani. Dheweke bisa uga ora ketemu. Yen dheweke ketemu, banjur bisa dadi ala banget. Lan karo autovacuum - iki uga masalah. Ana rong masalah karo transaksi dawa ing OLTP: kunci lan autovacuum. Lan yen sampeyan duwe umpan balik siyaga panas aktif ing tiron, sampeyan isih bakal nampa kunci autovacuum ing master, bakal teka saka tiron. Nanging paling ora bakal ana kunci. Lan bakal ana lok. Kita ngomong babagan owah-owahan data, mula kunci minangka titik penting ing kene. Lan yen iki kabeh kanggo dangu, banjur liyane lan liyane transaksi dikunci. Dheweke bisa nyolong wong liya. Lan wit lok katon. Aku menehi link menyang snippet. Lan masalah iki dadi luwih cepet saka masalah karo autovacuum, kang mung bisa nglumpukake.
Matur nuwun kanggo laporan! Sampeyan miwiti laporan kanthi ujar manawa sampeyan salah nguji. We terus idea kita kudu njupuk peralatan padha, karo basa ing cara sing padha. Ayo kita menehi pangembang basis. Lan dheweke nuruti panjaluke. Lan dheweke katon apik. Nanging dheweke ora mriksa urip, nanging kanggo urip, contone, kita duwe beban 60-70%. Lan sanajan nggunakake tuning iki, ora bisa digunakake kanthi apik.
Duwe ahli ing tim lan nggunakake ahli DBA sing bisa prédhiksi apa sing bakal kelakon karo beban latar mburi nyata iku penting. Nalika kita mung ndamel owah-owahan kita resik, kita ndeleng gambar. Nanging pendekatan sing luwih maju, nalika kita nindakake perkara sing padha maneh, nanging kanthi beban simulasi produksi. Iku cukup kelangan. Nganti saiki, sampeyan kudu tuwuh. Kaya wong diwasa. Kita mung ndeleng apa sing kita duwe lan uga ndeleng manawa kita duwe sumber daya sing cukup. Iku pitakonan sing apik.
Nalika kita wis nindakake uwuh pilih lan kita duwe, contone, flag dibusak
Iki sing ditindakake autovacuum kanthi otomatis ing Postgres.
Oh, apa dheweke nindakake?
Autovacuum minangka kolektor sampah.
Matur suwun!
Matur nuwun kanggo laporan! Apa ana pilihan kanggo langsung ngrancang database kanthi partisi supaya kabeh sampah dadi reged saka meja utama nang endi wae menyang sisih?
Mesthi wis.
Apa bisa nglindhungi awake dhewe yen wis ngunci meja sing ora bisa digunakake?
Mesthi wis. Nanging kaya pitakonan pitik lan endhog. Yen kita kabeh ngerti apa sing bakal kelakon ing mangsa ngarep, mesthine, kita bakal nindakake kabeh sing keren. Nanging bisnis saya ganti, ana kolom anyar, panjaluk anyar. Banjur - oops, kita pengin nyopot. Nanging kahanan becik iki, ing urip ana, nanging ora tansah. Nanging sakabèhé iku apike. Mung truncate lan iku.
Source: www.habr.com