Dina waktos anu jauh, panyabutan otomatis data anu teu dipikabutuh bakal janten salah sahiji tugas penting DBMS [1]. Samentawis waktos, urang nyalira kedah ngurus mupus atanapi mindahkeun data anu teu dipikabutuh kana sistem panyimpen anu langkung mirah. Anggap anjeun mutuskeun mupus sababaraha juta jajar. Tugas anu cukup saderhana, khususna upami kaayaanna dipikanyaho sareng aya indéks anu cocog. "Hapus tina table1 WHERE col1 =: nilai" - naon bisa jadi basajan, katuhu?
video:
-
Kuring parantos janten panitia program Highload ti mimiti taun, nyaéta saprak 2007.
-
Sareng kuring parantos sareng Postgres ti 2005. Dipaké dina loba proyék.
-
Grup sareng RuPostges ogé saprak 2007.
-
Kami parantos ningkat kana 2100+ pamilon dina Meetup. Ieu kadua di dunya sanggeus New York, overtaken ku San Fransisco keur lila.
-
Kuring geus cicing di California pikeun sababaraha taun. Abdi langkung seueur ngurus perusahaan Amérika, kalebet anu ageung. Aranjeunna pamaké aktip ti Postgres. Tur aya sagala sorts hal metot.
nyaéta parusahaan kuring. Kami dina bisnis ngajadikeun otomatis tugas anu ngaleungitkeun kalambatan pangwangunan.
Upami anjeun ngalakukeun hiji hal, teras sakapeung aya sababaraha jinis colokan di sabudeureun Postgres. Hayu urang ngadagoan admin pikeun nyetél test stand pikeun anjeun, atawa anjeun kudu ngadagoan DBA ngabales ka anjeun. Sareng urang mendakan bottlenecks sapertos dina prosés pamekaran, uji sareng administrasi sareng nyobian ngaleungitkeunana kalayan bantuan automation sareng pendekatan anyar.
Abdi nembe di VLDB di Los Angeles. Ieu konferensi pangbadagna dina database. Sareng aya laporan yén DBMS ka hareup henteu ngan ukur nyimpen, tapi ogé ngahapus data sacara otomatis. Ieu topik anyar.
Aya beuki loba data di dunya zettabytes - éta 1 petabytes. Sareng ayeuna parantos diperkirakeun yén urang gaduh langkung ti 000 zettabytes data anu disimpen di dunya. Jeung aya beuki loba di antarana.
Jeung naon anu kudu dipigawé kalayan eta? Jelas perlu dipiceun. Ieu mangrupikeun tautan kana laporan anu pikaresepeun ieu. Tapi sajauh ieu teu acan dilaksanakeun dina DBMS.
Jalma anu bisa ngitung duit hayang dua hal. Aranjeunna hoyong urang ngahapus, janten sacara téknis urang kedah tiasa ngalakukeunana.
Anu bakal kuring nyarioskeun salajengna nyaéta sababaraha kaayaan abstrak anu kalebet sakumpulan kaayaan nyata, nyaéta jenis kompilasi naon anu saleresna kajantenan ka kuring sareng pangkalan data sakurilingna sababaraha kali, mangtaun-taun. Rakes aya dimana-mana sareng sadayana ngaléngkah unggal waktos.
Anggap urang gaduh basa atanapi sababaraha basa anu ngembang. Sareng sababaraha rékaman écés sampah. Contona, pamaké mimiti ngalakukeun hiji hal di dinya, tapi teu rengse eta. Sareng saatos sababaraha waktos urang terang yén tacan beres ieu henteu tiasa disimpen deui. Nyaéta, urang hoyong ngabersihan sababaraha barang sampah pikeun ngahémat rohangan, ningkatkeun kinerja, jsb.
Sacara umum, tugasna nyaéta ngajadikeun otomatis ngahapus hal-hal khusus, garis khusus dina sababaraha tabel.
Sareng urang gaduh pamundut sapertos kitu, anu bakal urang bahas ayeuna, nyaéta, ngeunaan panyabutan sampah.
Kami naroskeun ka pamekar anu berpengalaman pikeun ngalakukeunana. Anjeunna nyandak pamundut ieu, pariksa keur dirina - sagalana jalan. Diuji dina pementasan - sadayana saé. Digulung kaluar - sagalana jalan. Sakali sapoé urang ngajalankeun eta - sagalana geus rupa.
database tumuwuh sarta tumuwuh. DELETE poean mimiti jalan saeutik leuwih laun.
Teras we ngartos yen urang ayeuna boga parusahaan pamasaran jeung lalulintas bakal sababaraha kali leuwih badag, jadi urang mutuskeun pikeun ngareureuhkeun samentara hal nu teu perlu. Jeung poho balik.
Sababaraha bulan ti harita maranéhna inget. Jeung pamekar nu kaluar atawa sibuk jeung hal sejenna, maréntahkeun séjén pikeun mulangkeunana.
Anjeunna pariksa dina dev, dina pementasan - sagalana OK. Alami, anjeun masih kudu ngabersihan up naon geus akumulasi. Anjeunna dipariksa sagalana jalan.
Naon kajadian salajengna? Lajeng sagalana ragrag eta pikeun urang. Ieu pakait sahingga di sawatara titik sagalana ragrag ka handap. Sarerea reuwas, teu aya anu ngartos naon anu kajantenan. Terus tétéla yén masalah éta dina DELETE ieu.
Aya nu lepat? Ieu daptar naon anu tiasa salah. Nu mana anu paling penting?
-
Salaku conto, teu aya ulasan, nyaéta ahli DBA henteu ningali éta. Anjeunna bakal geuwat manggihan masalah kalawan panon ngalaman, sarta sajaba ti, anjeunna boga aksés ka prod, dimana sababaraha juta garis geus akumulasi.
-
Meureun maranéhna dipariksa lepat.
-
Panginten hardwarena parantos lami sareng anjeun kedah ningkatkeun dasar ieu.
-
Atanapi aya anu lepat sareng pangkalan data éta sorangan, sareng urang kedah ngalih ti Postgres ka MySQL.
-
Atawa meureun aya lepat sareng operasi.
-
Panginten aya sababaraha kasalahan dina organisasi padamelan sareng anjeun kedah mecat batur sareng nyewa jalma anu pangsaéna?
Henteu aya cek DBA. Upami aya DBA, anjeunna bakal ningali sababaraha juta garis ieu sareng bahkan tanpa percobaan bakal nyarios: "Éta henteu ngalakukeun éta." Anggap upami kode ieu aya di GitLab, GitHub sareng bakal aya prosés ulasan kode sareng teu aya hal sapertos anu tanpa persetujuan DBA operasi ieu bakal lumangsung dina prod, maka écés DBA bakal nyarios: "Ieu teu tiasa dilakukeun. .”
Sarta anjeunna bakal nyebutkeun yén anjeun bakal boga masalah sareng disk IO sarta sakabeh prosés bakal balik gélo, meureun aya konci, sarta ogé anjeun bakal meungpeuk autovacuum pikeun kebat menit, jadi ieu teu alus.
Kasalahan kadua - aranjeunna dipariksa di tempat salah. Urang nempo sanggeus kanyataan yén loba data junk akumulasi on prod, tapi pamekar teu boga akumulasi data dina database ieu, sarta teu saurang ogé dijieun junk ieu salila pementasan. Sasuai, aya 1 garis anu gancang digarap.
Urang ngarti yén tés urang lemah, nyaéta prosés anu diwangun teu nyekel masalah. Hiji percobaan DB nyukupan teu dipigawé.
Eksperimen idéal langkung dipikaresep dilaksanakeun dina alat anu sami. Teu salawasna mungkin pikeun ngalakukeun ieu dina alat-alat anu sarua, tapi penting pisan yén éta salinan pinuh-ukuran database. Ieu naon anu kuring da'wah sababaraha taun ayeuna. Sareng sataun katukang kuring nyarioskeun ieu, anjeun tiasa nonton sadayana dina YouTube.
Meureun parabot urang goréng? Lamun neuteup, lajeng latency luncat. Kami parantos ningali yén panggunaan 100%. Tangtosna, upami ieu mangrupikeun drive NVMe modern, maka sigana bakal langkung gampang pikeun urang. Sarta meureun urang moal iklas ti dinya.
Upami anjeun gaduh awan, teras pamutahiran éta gampang dilakukeun di dinya. Ngangkat réplika anyar dina hardware anyar. switchover. Sareng sadayana saé. Lumayan gampang.
Naha mungkin waé nyabak disk anu langkung alit? Sareng di dieu, ngan kalayan bantosan DBA, urang teuleum kana topik anu disebut tuning checkpoint. Tétéla urang teu boga checkpoint tuning.
Naon téh checkpoint? Éta aya dina DBMS naon waé. Nalika anjeun gaduh data dina mémori anu robih, éta henteu langsung ditulis kana disk. Inpormasi anu datana parantos robih mimitina ditulis kana log tulis payun. Sarta di sawatara titik, DBMS mutuskeun yén éta waktu dump kaca nyata ka disk, ku kituna lamun urang gagal, urang tiasa ngalakukeun kirang REDO. Ieu kawas cocooan. Lamun urang tiwas, urang bakal ngamimitian kaulinan ti checkpoint panungtungan. Sareng sadaya DBMS ngalaksanakeunana.
Setélan di Postgres katinggaleun. Éta dirancang pikeun volume data sareng transaksi umur 10-15 taun. Sareng titik pamariksaan henteu aya pengecualian.
Ieu inpormasi tina laporan pamariksaan Postgres kami, nyaéta pamariksaan kaséhatan otomatis. Sareng ieu mangrupikeun sababaraha pangkalan data tina sababaraha terabytes. Sareng tiasa katingali ogé yén maksakeun pamariksaan dina ampir 90% kasus.
Naon éta hartosna? Aya dua setélan di dinya. Checkpoint tiasa dugi ka waktosna, contona, dina 10 menit. Atawa bisa datang lamun cukup loba data geus dieusian.
Sareng sacara standar max_wal_saze disetel ka 1 gigabyte. Kanyataanna, ieu bener kajadian di Postgres sanggeus 300-400 megabytes. Anjeun parantos ngarobih seueur data sareng pamariksaan anjeun kajantenan.
Sareng upami teu aya anu nyetél éta, sareng jasana ningkat, sareng perusahaan nampi seueur artos, éta seueur transaksi, teras pamariksaan sumping sakali menit, sakapeung unggal 30 detik, sareng sakapeung tumpang tindih. Ieu rada goréng.
Sarta kami kudu mastikeun yén datang kirang sering. Nyaéta, urang tiasa ningkatkeun max_wal_size. Sarta eta bakal datangna kirang sering.
Tapi kami geus ngembangkeun sakabeh metodologi pikeun kumaha ngalakukeun eta leuwih bener, nyaeta, kumaha carana nyieun kaputusan ngeunaan milih setelan, jelas dumasar kana data husus.
Sasuai, urang ngalakukeun dua runtuyan percobaan dina database.
Runtuyan kahiji - urang ngarobah max_wal_size. Sareng urang nuju ngalakukeun operasi masif. Kahiji, urang ngalakukeun eta dina setélan standar 1 gigabyte. Sarta kami ngalakukeun hiji DELETE masif loba jutaan garis.
Anjeun tiasa ningali kumaha teuas éta pikeun urang. Kami ningali yén disk IO parah pisan. Kami ningali sabaraha WAL anu kami hasilkeun, sabab ieu penting pisan. Hayu urang tingali sabaraha kali pos pamariksaan lumangsung. Sarta kami nempo yén éta téh teu alus.
Salajengna urang ningkatkeun max_wal_size. Urang ulang. Urang nambahan, urang ulang. Sarta jadi sababaraha kali. Sacara prinsip, 10 titik téh alus, dimana 1, 2, 4, 8 gigabytes. Sarta kami kasampak di kabiasaan sistem husus. Ieu jelas yén di dieu parabot kudu kawas on prod. Anjeun kedah gaduh disk anu sami, jumlah mémori anu sami, sareng setélan Postgres anu sami.
Sareng ku cara kieu urang bakal tukeur sistem urang, sareng urang terang kumaha DBMS bakal kalakuanana upami aya DELETE massa anu goréng, kumaha éta bakal papariksaan.
Checkpoint dina basa Rusia mangrupakeun checkpoints.
Conto: PUPUS sababaraha juta baris dumasar indéks, baris "paburencay" sakuliah kaca.
Ieu conto. Ieu sababaraha dasar. Sareng ku setélan standar 1 gigabyte pikeun max_wal_size, jelas pisan yén disk urang angkat ka rak pikeun ngarékam. Gambar ieu mangrupikeun gejala khas pasien anu gering pisan, nyaéta, anjeunna leres-leres ngarasa goréng. Tur aya hiji operasi tunggal, aya ngan hiji DELETE sababaraha juta garis.
Upami operasi sapertos kitu diidinan dina prod, maka urang ngan ukur ngagolér, sabab écés yén hiji DELETE maéhan urang dina rak.
Salajengna, dimana 16 gigabytes, éta jelas yén huntu geus Isro. Huntu geus hadé, nyaeta, urang knocking on siling, tapi teu jadi goréng. Aya sababaraha kabebasan di dinya. Di katuhu aya catetan. Jeung jumlah operasi - grafik kadua. Sarta eta jelas yén urang geus engapan saeutik gampang nalika 16 gigabyte.
Sareng dimana 64 gigabytes tiasa katingali yén éta parantos langkung saé. Geus huntu diucapkeun, aya deui kasempetan pikeun salamet operasi sejen tur ngalakukeun hiji hal kalawan disk.
Kunaon kitu
Kuring bakal teuleum kana detil saeutik, tapi topik ieu, kumaha carana ngalaksanakeun papariksaan tuning, bisa ngahasilkeun sakabeh laporan, jadi kuring moal ngamuat loba, tapi kuring baris outline saeutik naon kasusah aya.
Upami pamariksaan éta sering teuing, sareng urang ngamutahirkeun garis kami henteu sacara berurutan, tapi mendakan ku indéks, anu saé, sabab kami henteu ngahapus sadayana méja, maka éta tiasa kajadian anu mimitina urang keuna halaman kahiji, teras sarébu, terus balik deui ka nu kahiji. Sareng upami antara kunjungan ieu ka halaman kahiji, titik pamariksaan parantos disimpen kana disk, teras éta bakal disimpen deui, sabab kami kotor pikeun kadua kalina.
Sareng kami bakal maksakeun tempat pamariksaan pikeun ngahemat sababaraha kali. Kumaha bakal aya operasi kaleuleuwihan pikeun anjeunna.
Tapi éta henteu sadayana. Kaca aya 8 kilobyte dina Postgres sareng 4 kilobyte dina Linux. Sareng aya setélan full_page_writes. Ieu diaktipkeun sacara standar. Sareng ieu leres, sabab upami urang mareuman, maka aya bahaya anu ngan ukur satengah halaman bakal disimpen upami nabrak.
Paripolah nulis ka WAL tina log maju sapertos kitu nalika urang gaduh titik pamariksaan sareng urang ngarobih halaman pertama kalina, sadaya halaman, nyaéta, sadayana 8 kilobyte, asup kana log payun, sanaos urang ngan ukur ngarobih. garis, anu beuratna 100 bait. Sareng urang kedah nyerat sadayana halaman.
Dina parobahan saterusna bakal aya ngan tuple husus, tapi pikeun kahiji kalina urang nulis handap sagalana.
Sareng, sasuai, upami pamariksaan kajantenan deui, maka urang kedah ngamimitian sadayana ti mimiti deui sareng nyorong sadayana halaman. Kalawan sering checkpoints, lamun urang leumpang ngaliwatan kaca sarua, full_page_writes = on bakal leuwih ti eta bisa jadi, ie urang ngahasilkeun leuwih WAL. More dikirim ka réplika, ka arsip, ka disk.
Sareng, sasuai, urang gaduh dua redundancies.
Upami urang ningkatkeun max_wal_size, tétéla urang ngagampangkeun pikeun checkpoint sareng panulis wal. Sareng éta saé.
Hayu urang nempatkeun dina terabyte sarta hirup kalawan eta. Naon goréng ngeunaan eta? Ieu goréng, sabab bisi gagal, urang bakal nanjak sababaraha jam, sabab checkpoint geus lila pisan jeung loba geus robah. Sareng urang kedah ngalakukeun sadaya REDO ieu. Sarta sangkan ngalakukeun runtuyan kadua percobaan.
Kami ngalakukeun operasi sareng ningali nalika pamariksaan badé réngsé, kami maéhan -9 Postgres kalayan ngahaja.
Sarta sanggeus éta urang mimitian deui, tur tingal kumaha lila eta bakal naek kana parabot ieu, ie sabaraha eta bakal REDO dina kaayaan goréng ieu.
Dua kali kuring bakal dicatet yén kaayaan téh goréng. Mimiti, urang nabrak pas sateuacan pos pamariksaan réngsé, janten urang kedah kaleungitan. Jeung Bréh, urang kungsi operasi masif. Tur upami checkpoints éta on timeout, teras, paling dipikaresep, kirang WAL bakal dihasilkeun saprak checkpoint panungtungan. Hartina, éta téh pecundang ganda.
Kami ngukur kaayaan sapertos kitu pikeun ukuran max_wal_size anu béda sareng ngartos yén upami max_wal_size nyaéta 64 gigabyte, maka dina kasus anu parah ganda kami bakal nanjak salami 10 menit. Sareng urang pikir naha éta cocog sareng urang atanapi henteu. Ieu patarosan bisnis. Urang kedah nunjukkeun gambar ieu ka anu tanggung jawab kana kaputusan bisnis sareng naroskeun, "Sabaraha lami urang tiasa ngagolér upami aya masalah? Naha urang tiasa ngagolér dina kaayaan anu paling parah salami 3-5 menit? Jeung anjeun nyieun kaputusan.
Sarta di dieu mangrupa titik metot. Kami gaduh sababaraha laporan ngeunaan Patroni dina konperénsi éta. Sarta meureun anjeun ngagunakeun eta. Ieu mangrupikeun autofailover pikeun Postgres. GitLab sareng Data Egret nyarioskeun ieu.
Tur upami Anjeun salah boga autofailover nu datang dina 30 detik, lajeng meureun urang bisa ngagolér pikeun 10 menit? Kusabab urang bakal pindah ka replica ku titik ieu, jeung sagalana bakal rupa. Ieu titik moot. Abdi henteu terang jawaban anu jelas. Kuring ngan ngarasa yen topik ieu teu ngan sabudeureun recovery kacilakaan.
Lamun urang boga recovery lila sanggeus hiji kagagalan, mangka urang bakal uncomfortable dina loba kaayaan sejen. Salaku conto, dina percobaan anu sami, nalika urang ngalakukeun hiji hal sareng sakapeung kedah ngantosan 10 menit.
Kuring tetep moal jauh teuing, sanaos urang gaduh autofailover. Sakumaha aturan, nilai sapertos 64, 100 gigabytes mangrupikeun nilai anu saé. Kadang-kadang malah patut milih kirang. Sacara umum, ieu elmu halus.
Pikeun ngalakukeun iterasi, contona, max_wal_size = 1, 8, anjeun kedah ngulang operasi massa sababaraha kali. Anjeun dijieun eta. Sareng dina dasar anu sami anjeun badé ngalakukeun deui, tapi anjeun parantos ngahapus sadayana. Naon anu kedah dilakukeun?
Kuring bakal ngobrol engké ngeunaan solusi urang, naon anu urang laksanakeun pikeun ngulang dina kaayaan sapertos kitu. Sareng ieu mangrupikeun pendekatan anu paling leres.
Tapi dina hal ieu, kami untung. Lamun, sakumaha nyebutkeun dieu "Mimitian, Pupus, ROLLBACK", lajeng urang bisa ngulang PUPUS. Nyaéta, upami urang ngabatalkeun éta nyalira, maka urang tiasa ngulang deui. Jeung fisik di anjeun data bakal tempatna di tempat anu sarua. Anjeun malah teu meunang bloat nanaon. Anjeun tiasa ngulang deui DELETE sapertos kitu.
DELETE ieu sareng ROLLBACK idéal pikeun tuning checkpoint, sanaos anjeun teu gaduh laboratorium database anu leres.
Kami ngadamel piring kalayan hiji kolom "i". Postgres gaduh kolom utiliti. Aranjeunna halimunan iwal husus dipénta. Ieu: ctid, xmid, xmax.
Ctid mangrupakeun alamat fisik. Kaca nol, tuple munggaran dina kaca.
Ieu bisa ditempo yén sanggeus ROOLBACK tuple tetep dina tempat anu sarua. Nyaéta, urang tiasa nyobian deui, éta bakal kalakuanana sami. Ieu hal utama.
Xmax mangrupikeun waktos maotna tuple. Ieu dicap, tapi Postgres weruh yén urus ieu digulung deui, jadi henteu masalah lamun éta 0 atanapi éta urus digulung deui. Ieu nunjukkeun yén kasebut nyaéta dimungkinkeun pikeun iterate leuwih DELETE jeung pariksa operasi bulk tina kabiasaan sistem. Anjeun tiasa ngadamel laboratorium database pikeun jalma miskin.
Ieu ngeunaan programer. Ngeunaan DBA, oge, aranjeunna salawasna scold programer pikeun ieu: "Naha anjeun ngalakukeun operasi panjang tur hésé?". Ieu topik jejeg lengkep béda. Baheula aya administrasi, ayeuna bakal aya pangwangunan.
Jelas, urang teu pegat jadi potongan. Éta jelas. Teu mungkin mun teu megatkeun DELETE misalna pikeun numpuk jutaan garis kana bagéan. Ieu bakal dilakukeun pikeun 20 menit, sarta sagalana bakal ngagolér. Tapi, hanjakalna, malah pamekar ngalaman nyieun kasalahan, sanajan di pausahaan anu kacida gedéna.
Naha éta penting pikeun megatkeun?
-
Upami urang ningali yén disk éta teuas, teras hayu urang ngalambatkeunana. Sareng upami urang rusak, maka urang tiasa nambihan jeda, urang tiasa ngalambatkeun throttling.
-
Sarta kami moal meungpeuk batur keur lila. Dina sababaraha kasus teu masalah, upami Anjeun keur mupus sampah nyata nu teu saurang ogé dipake dina, mangka paling dipikaresep anjeun moal meungpeuk saha iwal karya autovacuum, sabab bakal ngadagoan urus réngsé. Tapi upami anjeun ngahapus hiji hal anu tiasa dipénta ku batur, maka aranjeunna bakal diblokir, bakal aya sababaraha réaksi ranté. Transaksi panjang kedah dihindari dina situs wéb sareng aplikasi sélulér.
Ieu metot. Kuring mindeng ningali yén pamekar nanya: "Naon ukuran pak kuring kudu milih?".
Ieu jelas yén badag ukuran kebat, nu leuwih leutik overhead urus, nyaéta, overhead tambahan tina transaksi. Tapi dina waktos anu sareng, waktos naek pikeun urus ieu.
Kuring boga aturan basajan pisan: nyandak saloba Anjeun tiasa, tapi ulah balik leuwih executables per detik.
Naha sadetik? Kateranganana basajan pisan sareng kaharti ku sadayana, bahkan jalma non-teknis. Urang ningali réaksi. Hayu urang nyandak 50 milidetik. Upami aya anu robih, maka panon urang bakal ngaréspon. Lamun kurang, mangka leuwih hese. Lamun hal responds sanggeus 100 milliseconds, contona, anjeun diklik mouse, sarta eta ngajawab anjeun sanggeus 100 milliseconds, anjeun geus ngarasa reureuh slight kieu. Sadetik geus katarima salaku rem.
Sasuai, lamun urang megatkeun operasi massa urang kana bursts 10 detik, mangka urang boga resiko nu urang bakal meungpeuk batur. Sarta eta bakal dianggo pikeun sababaraha detik, sarta jalma bakal geus aya bewara eta. Ku alatan éta, kuring leuwih resep teu ngalakukeun leuwih ti sadetik. Tapi dina waktos anu sareng, ulah megatkeun eta up pisan finely, sabab overhead urus bakal noticeable. Dasarna bakal langkung hese, sareng masalah-masalah anu sanés tiasa timbul.
Urang milih ukuran pakét. Dina unggal hal, urang tiasa ngalakukeunana béda. Bisa otomatis. Sarta kami yakin kana efisiensi ngolah hiji pak. Nyaéta, urang ngahapus hiji bungkus atanapi UPDATE.
Ku jalan kitu, sadaya anu kuring nyarioskeun sanés ngan ukur DELETE. Sakumaha anjeun duga, ieu mangrupikeun operasi bulk dina data.
Sarta kami ningali yén rencana téh alus teuing. Anjeun tiasa ningali indéks scan, indéks ukur scan malah hadé. Sarta kami boga jumlah leutik data aub. Sarta kirang ti sadetik minuhan. Super.
Sareng urang tetep kedah mastikeun yén henteu aya degradasi. Éta kajadian yén bungkus munggaran gancang dianggo, teras janten parah, parah sareng parah. Prosésna sapertos kitu anjeun kedah nguji pisan. Ieu persis naon labs database keur.
Sareng urang masih kedah nyiapkeun hiji hal supados urang tiasa nuturkeun ieu leres dina produksi. Contona, urang bisa nulis waktu dina log, urang bisa nulis dimana urang ayeuna jeung saha urang ayeuna geus dihapus. Sareng ieu bakal ngamungkinkeun urang ngartos naon anu kajantenan engké. Sareng upami aya anu salah, gancang milarian masalahna.
Upami urang kedah mariksa efisiensi pamundut sareng urang kedah ngulang sababaraha kali, maka aya anu sapertos bot sasama. Anjeunna parantos siap. Hal ieu dianggo ku puluhan pamekar unggal dinten. Sarta anjeunna weruh kumaha carana masihan database terabyte badag dina pamundut di 30 detik, salinan anjeun sorangan. Sareng anjeun tiasa ngahapus hiji hal di dinya sareng ucapkeun RESET, sareng ngahapus deui. Anjeun tiasa ékspérimén ku cara ieu. Kuring ningali masa depan pikeun hal ieu. Sarta kami geus ngalakukeun eta.
Naon strategi partisi? Kuring ningali 3 strategi partisi anu béda anu dianggo ku pamekar dina pak.
Anu kahiji saderhana pisan. Simkuring gaduh ID numerik. Sareng hayu urang ngabagi kana interval anu béda sareng damel sareng éta. downside jelas. Dina ruas kahiji, urang tiasa gaduh 100 garis sampah nyata, dina kadua 5 garis atanapi henteu pisan, atanapi sadayana 1 garis bakal janten sampah. Karya pisan henteu rata, tapi gampang pikeun megatkeun. Aranjeunna nyandak ID maksimum sarta smashed eta. Ieu pendekatan naif.
Strategi kadua nyaéta pendekatan saimbang. Hal ieu dipaké dina Gitlab. Aranjeunna nyandak sareng nyeken méja. Kami mendakan wates-wates bungkus KTP supados unggal pakét ngagaduhan 10 rékaman. Sareng nempatkeun aranjeunna dina antrian. Teras we prosés. Anjeun tiasa ngalakukeun ieu dina sababaraha threads.
Dina strategi munggaran, teuing, ku jalan kitu, anjeun tiasa ngalakukeun ieu dina sababaraha threads. Teu hese.
Tapi aya pendekatan anu langkung tiis sareng langkung saé. Ieu strategi katilu. Jeung lamun mungkin, eta leuwih hade milih eta. Urang ngalakukeun ieu dina dasar indéks husus. Dina hal ieu, éta paling dipikaresep bakal indéks nurutkeun kaayaan sampah urang jeung ID. Urang bakal ngalebetkeun ID supados éta ngan ukur indéks scan supados urang henteu angkat ka tumpukan.
Sacara umum, nyeken ukur indéks langkung gancang tibatan nyeken indéks.
Sareng urang gancang mendakan KTP anu badé dipupus. BATCH_SIZE kami pilih sateuacanna. Sarta kami henteu ngan meunang aranjeunna, urang meunang aranjeunna dina cara husus sarta geuwat hack aranjeunna. Tapi kami ngonci supados upami aranjeunna parantos dikonci, kami henteu ngonci aranjeunna, tapi teraskeun sareng nyandak anu salajengna. Ieu kanggo update skip dikonci. Fitur super Postgres ieu ngamungkinkeun urang damel dina sababaraha utas upami urang hoyong. Ieu mungkin dina hiji aliran. Sareng di dieu aya CTE - ieu mangrupikeun pamundut. Sareng urang gaduh penghapusan nyata anu lumangsung di lantai kadua CTE ieu - returning *. Anjeun tiasa uih deui id, tapi langkung saé *lamun teu boga loba data dina unggal baris.
Naha urang peryogi eta? Ieu naon urang kudu ngalaporkeun deui. Urang ayeuna geus dihapus jadi loba garis dina kanyataanana. Sareng kami gaduh wates ku ID atanapi ku created_at sapertos kieu. Anjeun tiasa ngalakukeun min, max. Hal sejenna bisa dipigawé. Anjeun tiasa barang seueur di dieu. Sarta eta pisan merenah pikeun monitoring.
Aya hiji deui catetan ngeunaan indéks. Upami urang mutuskeun yén urang peryogi indéks khusus pikeun tugas ieu, maka urang kedah mastikeun yén éta henteu ngarusak tumpukan ngan apdet tuples. Hartina, Postgres gaduh statistik sapertos kitu. Ieu tiasa ditingali dina pg_stat_user_tables pikeun méja anjeun. Anjeun tiasa ningali upami apdet panas dianggo atanapi henteu.
Aya kaayaan nalika indéks anyar anjeun ngan saukur tiasa motong aranjeunna. Sareng anjeun gaduh apdet anu sanés anu parantos jalan, ngalambatkeun. Henteu ngan kusabab indéks mucunghul (unggal indéks slows turun apdet saeutik, tapi saeutik), tapi di dieu eta masih ngaruksak eta. Jeung mustahil pikeun nyieun optimasi husus pikeun tabel ieu. Ieu kajadian kadang. Ieu mangrupikeun subtlety anu sakedik jalma émut. Sareng rake ieu gampang diléngkah. Kadang-kadang kajadian nu kudu manggihan pendekatan ti sisi sejen tur masih ngalakukeun tanpa indéks anyar ieu, atawa nyieun indéks sejen, atawa ku cara séjén, contona, anjeun tiasa nganggo metoda kadua.
Tapi ieu téh strategi paling optimal, kumaha ngabagi kana bets sarta némbak bets kalawan hiji pamundut, ngahapus saeutik saeutik, jsb.
Transaksi panjang
Autovakum diblokir -
masalah blocking -
Kasalahan # 5 mangrupikeun kasalahan anu ageung. Nikolai ti Okmeter ngobrol ngeunaan ngawaskeun Postgres. Idéal ngawaskeun Postgres, hanjakalna, teu aya. Aya nu deukeut, aya nu leuwih jauh. Okmeter cukup caket pikeun sampurna, tapi seueur anu leungit sareng kedah ditambihan. Anjeun kedah siap pikeun ieu.
Contona, tuple maot anu pangalusna diawaskeun. Upami Anjeun gaduh loba hal maot dina tabél, lajeng hal anu salah. Éta langkung saé pikeun ngaréaksikeun ayeuna, upami henteu aya degradasi, sareng urang tiasa ngagolér. Eta kajadian.
Lamun aya IO badag, mangka jelas yén ieu téh teu alus.
Transaksi panjang teuing. Transaksi panjang teu kedah diidinan dina OLTP. Sareng ieu mangrupikeun tautan kana snippet anu ngamungkinkeun anjeun nyandak snippet ieu sareng parantos ngalaksanakeun sababaraha tracking transaksi anu panjang.
Naha transaksi lila goréng? Kusabab sakabeh konci bakal dileupaskeun ngan dina tungtungna. Sarta kami screw dulur. Tambih Deui, urang meungpeuk autovacuum pikeun sakabéh tabel. Éta henteu saé pisan. Sanaos anjeun gaduh siaga panas diaktipkeun dina réplika, éta tetep goréng. Sacara umum, nowhere éta hadé pikeun nyingkahan transaksi panjang.
Lamun urang boga loba tabel nu teu vacuumed, mangka urang kudu waspada. Di dieu kaayaan kitu téh mungkin. Urang teu langsung bisa mangaruhan operasi autovacuum. Ieu snippet ti Avito, nu kuring rada ningkat. Sareng tétéla janten alat anu pikaresepeun pikeun ningali naon anu urang gaduh sareng autovacuum. Salaku conto, sababaraha méja ngantosan di dinya sareng moal ngantosan péngkolan. Anjeun ogé kedah nempatkeun éta dina ngawaskeun sareng gaduh waspada.
Sareng ngaluarkeun blok. Leuweung tangkal blok. Kuring resep nyandak hiji hal ti batur tur ningkatkeun eta. Di dieu kuring nyokot CTE recursive tiis ti Data Egret nu nembongkeun leuweung tangkal konci. Ieu mangrupikeun alat diagnostik anu saé. Sareng dina dasarna, anjeun ogé tiasa ngawangun monitoring. Tapi ieu kudu dipigawé taliti. Anjeun kudu nyieun statement_timeout leutik keur diri. Jeung lock_timeout nyaeta desirable.
Kadang sagala kasalahan ieu lumangsung dina jumlah.
Dina pamanggih kuring, kasalahan utama di dieu nyaéta organisasi. Éta organisasi, sabab téknik henteu narik. Ieu nomer 2 - aranjeunna dipariksa di tempat salah.
Urang dipariksa di tempat salah, sabab urang teu boga clone produksi, nu gampang dipariksa. A pamekar bisa jadi teu boga aksés ka produksi pisan.
Sarta kami dipariksa teu aya. Lamun urang geus dipariksa di dinya, urang bakal geus katempo sorangan. Pamekar ningali éta sadayana sanajan tanpa DBA upami anjeunna pariksa dina lingkungan anu saé, dimana aya jumlah data anu sami sareng lokasi anu sami. Anjeunna bakal ningali sadaya degradasi ieu sareng anjeunna bakal isin.
Langkung seueur ngeunaan autovacuum. Sanggeus kami geus dipigawé hiji nyapu masif sababaraha juta garis, urang masih kudu ngalakukeun REPACK. Ieu hususna penting pikeun indéks. Aranjeunna bakal ngarasa goréng sanggeus urang cleaned sagalana aya.
Sareng upami anjeun hoyong uih deui padamelan beberesih sapopoé, maka kuring bakal nyarankeun ngalakukeunana langkung sering, tapi langkung alit. Éta tiasa sakali menit atanapi langkung sering sakedik. Sareng anjeun kedah ngawas dua hal: yén hal ieu teu aya kasalahan sareng éta henteu katinggaleun. Trik anu kuring nunjukkeun ngan bakal ngabéréskeun ieu.
Anu kami lakukeun nyaéta open source. Éta dipasang dina GitLab. Sarta kami nyieun eta ku kituna jalma bisa pariksa sanajan tanpa DBA a. Kami ngalakukeun lab database, nyaéta, urang nyauran komponén dasar dimana Joe ayeuna damel. Sareng anjeun tiasa nyandak salinan produksi. Ayeuna aya hiji palaksanaan Joe pikeun slack, Anjeun bisa nyebutkeun aya: "ngajelaskeun query misalna jeung kitu" jeung geura meunang hasil pikeun salinan anjeun database. Anjeun malah tiasa ngaHAPUS di dinya, sareng teu aya anu bakal perhatikeunana.
Anggap anjeun gaduh 10 terabyte, urang ngadamel lab database ogé 10 terabyte. Sareng sareng database 10 terabyte sakaligus, 10 pamekar tiasa dianggo sakaligus. Sarerea bisa ngalakukeun naon maranéhna rék. Bisa mupus, leupaskeun, jsb Éta lamunan misalna. Urang bakal ngobrol ngeunaan ieu isukan.
Ieu disebut provisioning ipis. Ieu provisioning halus. Ieu mangrupikeun implengan anu ngaleungitkeun telat dina pangwangunan, dina uji sareng ngajantenkeun dunya janten tempat anu langkung saé dina hal ieu. Nyaéta, éta ngan ukur ngamungkinkeun anjeun pikeun ngahindarkeun masalah sareng operasi bulk.
Conto: 5 terabyte database, meunang salinan dina waktu kurang ti 30 detik. Sareng henteu gumantung kana ukuranana, nyaéta, henteu paduli sabaraha terabytes.
Dinten anjeun tiasa angkat ka jeung ngagali kana parabot urang. Anjeun tiasa ngadaptar pikeun ningali naon anu aya. Anjeun tiasa masang bot ieu. Éta gratis. Tulis.
patarosan
Sering pisan dina kaayaan nyata tétéla yén data anu kedah tetep dina tabél langkung seueur tibatan anu kedah dihapus. Hartina, dina kaayaan kitu, éta mindeng gampang pikeun nerapkeun pendekatan misalna hiji, nalika leuwih gampang pikeun nyieun hiji objek anyar, nyalin ngan data diperlukeun aya, sarta batang tabel heubeul. Ieu jelas yén pendekatan programmatic diperlukeun pikeun moment ieu, bari anjeun bakal pindah. Kumaha pendekatan ieu?
Ieu mangrupikeun pendekatan anu saé sareng tugas anu saé pisan. Sarupa pisan sareng anu dilakukeun ku pg_repack, sami sareng anu anjeun kedah laksanakeun nalika anjeun ngadamel ID 4 bait. Loba frameworks ngalakukeun ieu sababaraha taun ka pengker, sarta ngan pelat geus dipelak nepi, sarta maranéhanana kudu dirobah jadi 8 bait.
tugas ieu rada hese. Urang ngalakukeun eta. Jeung anjeun kudu ati pisan. Aya konci, jsb Tapi keur dipigawé. Nyaéta, pendekatan standar nyaéta nganggo pg_repack. Anjeun nyatakeun labél sapertos kitu. Sareng sateuacan anjeun mimiti unggah data snapshot kana éta, anjeun ogé nyatakeun hiji piring anu ngalacak sadaya parobihan. Aya trik nu malah moal bisa ngalacak sababaraha parobahan. Aya subtleties. Lajeng anjeun pindah ku rolling parobahan. Bakal aya jeda pondok nalika urang nutup sadayana, tapi sacara umum ieu dilakukeun.
Upami anjeun ningali pg_repack dina GitHub, teras aya, nalika aya tugas pikeun ngarobih ID tina int 4 ka int 8, teras aya ide pikeun ngagunakeun pg_repack nyalira. Ieu oge mungkin, tapi éta saeutik hack, tapi bakal dianggo pikeun ieu teuing. Anjeun tiasa campur dina pemicu nu pg_repack migunakeun sarta ngomong aya: "Urang teu kedah data ieu", ie urang ngan mindahkeun naon urang kudu. Lajeng anjeunna ngan pindah sarta éta eta.
Kalayan pendekatan ieu, urang masih nampi salinan kadua tabel, dimana datana parantos diindeks sareng ditumpuk pisan merata kalayan indéks anu saé.
Bloat henteu hadir, éta mangrupikeun pendekatan anu saé. Tapi kuring terang yén aya usaha pikeun ngembangkeun otomatisasi pikeun ieu, nyaéta ngadamel solusi universal. Abdi tiasa ngahubungi anjeun sareng otomatisasi ieu. Ieu ditulis dina Python, nu hiji hal anu alus.
Abdi ngan saeutik saeutik ti dunya MySQL, jadi kuring datang ka ngadangukeun. Sareng kami nganggo pendekatan ieu.
Tapi éta ngan upami urang gaduh 90%. Upami urang gaduh 5%, maka éta henteu saé pisan ngagunakeunana.
Hatur nuhun laporan! Upami teu aya sumber daya pikeun ngadamel salinan prod lengkep, naha aya algoritma atanapi rumus pikeun ngitung beban atanapi ukuran?
Patarosan alus. Sajauh ieu, urang tiasa mendakan pangkalan data multi-terabyte. Malah lamun hardware aya teu sarua, Contona, memori kirang, processor kirang na disk teu persis sarua, tapi tetep urang ngalakukeun eta. Upami teu aya tempat, maka anjeun kedah mikir. Hayu atuh pikir nepi ka isukan, anjeun datang, urang bakal ngobrol, ieu patarosan alus.
Hatur nuhun laporan! Anjeun mimitina dimimitian ngeunaan kanyataan yén aya hiji Postgres tiis, nu boga keterbatasan sapertos kitu, tapi ngembang. Sareng ieu sadayana mangrupikeun tongkat sareng ageung. Naha ieu sadayana bertentangan sareng pamekaran Postgres sorangan, dimana sababaraha DELETE deferent bakal muncul atanapi anu sanés anu kedah tetep dina tingkat anu rendah naon anu urang nyobian ngolesan sababaraha cara aneh urang di dieu?
Upami urang nyarios dina SQL pikeun ngahapus atanapi ngapdet seueur rékaman dina hiji transaksi, teras kumaha Postgres tiasa nyebarkeun éta di dinya? Kami sacara fisik terbatas dina operasi. Urang masih bakal ngalakukeun eta pikeun lila. Sareng urang bakal ngonci dina waktos ieu, jsb.
Dipigawé kalayan indéks.
Abdi tiasa nganggap yén tuning checkpoint anu sami tiasa otomatis. Someday eta meureun. Tapi harita kuring teu pati ngarti kana patarosanana.
Patarosanna, naha aya vektor pangembangan sapertos ka ditu ka dieu, sareng di dieu anjeun paralel? Jelema. Naha aranjeunna henteu acan panginten?
Kuring ngobrol ngeunaan prinsip anu tiasa dianggo ayeuna. Aya bot sejen , kalayan ieu anjeun tiasa ngalakukeun tuning checkpoint otomatis. Naha éta bakal aya dina Postgres? Kuring henteu terang, éta henteu acan dibahas. Urang masih jauh ti éta. Tapi aya élmuwan anu nyieun sistem anyar. Sareng aranjeunna nyorong kami kana indéks otomatis. Aya kamajuan. Salaku conto, anjeun tiasa ningali tuning otomatis. Éta otomatis milih parameter. Tapi anjeunna moal ngalakukeun pamariksaan tuning pikeun anjeun. Hartina, éta bakal ngajemput pikeun pagelaran, panyangga cangkang, jsb.
Sareng pikeun tuning checkpoint, anjeun tiasa ngalakukeun ieu: upami anjeun gaduh sarébu klaster sareng hardware anu béda, mesin virtual anu béda dina méga, anjeun tiasa nganggo bot kami. ngalakukeun automation. Sareng max_wal_size bakal dipilih dumasar kana setélan target anjeun sacara otomatis. Tapi sajauh ieu teu malah nutup di inti, hanjakalna.
Wilujeng sonten Anjeun ngobrol ngeunaan bahaya transaksi panjang. Anjeun nyarios yén autovacuum dipeungpeuk bisi ngahapus. Kumaha deui eta ngarugikeun urang? Kusabab urang nyarios langkung seueur ngeunaan ngabebaskeun rohangan sareng tiasa dianggo. Naon deui urang leungit?
Autovacuum meureun sanes masalah pangbadagna di dieu. Sareng kanyataan yén transaksi anu panjang tiasa ngonci transaksi anu sanés, kamungkinan ieu langkung bahaya. Manehna bisa atawa teu bisa papanggih. Mun manehna patepung, teras tiasa pisan goréng. Tur kalawan autovacuum - ieu ogé masalah. Aya dua masalah sareng transaksi panjang di OLTP: konci sareng autovacuum. Tur upami Anjeun salah boga eupan balik sayaga panas diaktipkeun dina réplika, mangka anjeun masih bakal nampa hiji konci autovacuum on master, éta bakal datangna ti replica nu. Tapi sahenteuna moal aya konci. Sarta bakal aya loks. Urang ngobrol ngeunaan parobahan data, jadi konci téh titik penting di dieu. Sareng upami ieu sadayana kanggo waktos anu lami, teras langkung seueur transaksi dikonci. Éta bisa maok batur. Jeung tangkal lok mucunghul. Kuring nyadiakeun tumbu ka snippet. Sareng masalah ieu janten langkung jelas langkung gancang tibatan masalah autovacuum, anu ngan ukur tiasa ngumpulkeun.
Hatur nuhun laporan! Anjeun ngamimitian laporan anjeun ku nyarios yén anjeun salah diuji. Urang neraskeun ide urang yén urang kedah nyandak alat anu sami, kalayan dasarna dina cara anu sami. Anggap urang masihan pamekar dasar. Sarta anjeunna sasuai jeung pamundut. Sareng anjeunna sigana henteu kunanaon. Tapi anjeunna henteu pariksa hirup, tapi hirup, contona, urang boga beban 60-70%. Sareng upami urang nganggo tuning ieu, éta henteu tiasa dianggo pisan.
Gaduh ahli dina tim sareng nganggo ahli DBA anu tiasa ngaduga naon anu bakal kajadian sareng beban latar anu nyata penting. Lamun urang ngan drove parobahan bersih kami, urang tingali gambar. Tapi pendekatan anu langkung maju, nalika urang ngalakukeun deui hal anu sami, tapi kalayan beban anu disimulasikan sareng produksi. Ieu rada tiis. Nepi ka harita, Anjeun kudu tumuwuh nepi. Kawas sawawa. Kami ngan ukur ningali naon anu urang gaduh sareng ogé ningali naha urang gaduh sumber anu cekap. Éta patarosan anu saé.
Nalika urang geus ngalakukeun hiji pilih sampah sarta kami boga, contona, hiji bandéra dihapus
Ieu naon autovacuum teu otomatis di Postgres.
Oh, anjeunna ngalakukeun eta?
Autovacuum nyaeta kolektor sampah.
Hatur nuhun!
Hatur nuhun laporan! Naha aya pilihan pikeun langsung ngarancang database kalayan ngabagi-bagi ku cara anu sadayana sampah janten kotor tina méja utama dimana waé ka sisi?
Tangtu boga.
Naha mungkin teras ngajaga diri upami urang ngonci méja anu henteu kedah dianggo?
Tangtu boga. Tapi sual hayam jeung endog. Lamun urang sadayana terang naon anu bakal kajadian di mangsa nu bakal datang, tangtosna, urang bakal ngalakukeun sagalana tiis. Tapi bisnis ieu robah, aya kolom anyar, requests anyar. Teras - aduh, urang badé ngahapus. Tapi kaayaan idéal ieu, dina kahirupan eta lumangsung, tapi teu salawasna. Tapi sacara umum éta ide anu saé. Ngan truncate na éta eta.
sumber: www.habr.com