Transkrip ceramah Bruce Momjian 2020 "Buka Konci Manajer Konci Postgres".
(Catetan: Sadaya patarosan SQL tina slide tiasa didapet tina tautan ieu: )
Halo! Hadé pisan mun aya di Rusia deui. Hapunten teu tiasa sumping taun ka tukang, tapi taun ieu kuring sareng Ivan gaduh rencana anu ageung. Abdi ngarepkeun langkung sering ka dieu. Abdi resep sumping ka Rusia. Kuring bakal didatangan Tyumen, Tver. Abdi bungah pisan tiasa nganjang ka kota-kota ieu.
Nami abdi Bruce Momjian. Abdi damel di EnterpriseDB sareng parantos damel sareng Postgres langkung ti 23 taun. Kuring cicing di Philadelphia, AS. Kuring ngarambat sakitar 90 dinten sataun. Jeung kuring hadir ngeunaan 40 konferensi. Abdi , nu ngandung slides nu ayeuna kuring baris némbongkeun Anjeun. Ku alatan éta, sanggeus konferensi Anjeun bisa ngundeur éta ti ramatloka pribadi kuring. Éta ogé ngandung ngeunaan 30 presentasi. Aya ogé video sareng sajumlah ageung éntri blog, langkung ti 500. Ieu mangrupikeun sumber anu cukup informatif. Sareng upami anjeun resep kana bahan ieu, maka kuring ngajak anjeun ngagunakeunana.
Abdi kantos janten guru, profesor sateuacan ngamimitian damel sareng Postgres. Sareng kuring bungah pisan yén kuring ayeuna bakal tiasa nyarioskeun naon anu kuring badé nyarioskeun ka anjeun. Ieu mangrupikeun salah sahiji presentasi kuring anu paling pikaresepeun. Sareng presentasi ieu ngandung 110 slide. Urang bakal ngamimitian ngobrol sareng hal-hal anu saderhana, sareng dina tungtungna laporan bakal janten langkung rumit, sareng janten rada rumit.
Ieu obrolan rada pikaresepeun. Meungpeuk sanes subjek anu pang populerna. Simkuring hoyong ieu ngaleungit wae. Ieu kawas indit ka dokter gigi.
- Ngonci mangrupikeun masalah pikeun seueur jalma anu damel di pangkalan data sareng gaduh sababaraha prosés dina waktos anu sami. Aranjeunna peryogi blocking. Nyaéta, dinten ieu kuring bakal masihan anjeun pangaweruh dasar ngeunaan meungpeuk.
- ID Transaksi. Ieu mangrupikeun bagian anu rada pikaboseneun dina presentasi, tapi aranjeunna kedah kahartos.
- Salajengna urang bakal ngobrol ngeunaan jenis blocking. Ieu bagian anu cukup mékanis.
- Sareng di handap ieu kami bakal masihan sababaraha conto blocking. Sarta eta bakal rada hese ngarti.
Hayu urang ngobrol ngeunaan blocking.
Terminologi urang rada kompleks. Sabaraha anjeun terang dimana petikan ieu asalna? Dua jalma. Ieu tina kaulinan disebut kolosal Gua Adventure. Ieu kaulinan komputer dumasar-téks dina 80s, Jigana. Aya anjeun kedah lebet kana guha, kana labirin, sareng téksna robih, tapi eusina kirang langkung sami unggal waktos. Éta kumaha kuring apal kaulinan ieu.
Sareng di dieu urang ningali nami konci anu sumping ka kami ti Oracle. Urang make aranjeunna.
Di dieu urang ningali istilah anu ngabingungkeun kuring. Contona, SHARE UPDATE ECXLUSIVE. Teras Bagikeun RAW ECXLUSIVE. Jujur, ngaran-ngaran ieu teu pati jelas. Urang bakal coba mertimbangkeun aranjeunna dina leuwih jéntré. Sababaraha ngandung kecap "bagi", nu hartina misahkeun. Sababaraha ngandung kecap "ekslusif". Sababaraha ngandung duanana kecap ieu. Abdi hoyong mimitian ku cara ngonci ieu jalan.
Sareng kecap "aksés" ogé penting pisan. Jeung kecap "baris" mangrupakeun string a. Nyaéta, distribusi aksés, distribusi baris.
Masalah anu sanés anu kedah kahartos dina Postgres, anu hanjakalna henteu tiasa dibahas dina omongan kuring, nyaéta MVCC. Kuring boga presentasi misah dina topik ieu dina ramatloka kuring. Tur upami Anjeun salah pikir presentasi ieu teuas, MVCC meureun hardest kuring. Tur upami Anjeun salah kabetot, Anjeun bisa lalajo eta dina website. Anjeun tiasa nonton video.
Hal séjén anu urang kedah ngartos nyaéta ID transaksi. Loba transaksi teu bisa jalan tanpa identifiers unik. Sarta di dieu urang boga katerangan ngeunaan naon transaksi. Postgres gaduh dua sistem panomeran transaksi. Kuring terang ieu sanés solusi anu saé pisan.
Ogé émut yén slides bakal sesah kahartos, janten anu disorot beureum nyaéta anu anjeun kedah perhatosan.
Urang tingali. Jumlah transaksi disorot beureum. Fungsi SELECT pg_back dipidangkeun di dieu. Ieu mulih transaksi kuring jeung ID urus.
Hiji deui, upami anjeun resep presentasi ieu sareng hoyong ngajalankeun éta dina pangkalan data anjeun, anjeun tiasa angkat ka tautan ieu dina warna pink sareng unduh SQL pikeun presentasi ieu. Sareng anjeun tiasa ngajalankeun éta dina PSQL anjeun sareng sadayana presentasi bakal langsung aya dina layar anjeun. Éta moal ngandung kembang, tapi sahenteuna urang tiasa ningali éta.
Dina hal ieu urang tingali ID urus. Ieu mangrupikeun nomer anu kami pasihan anjeunna. Sareng aya jinis ID transaksi anu sanés dina Postgres, anu disebut ID transaksi virtual
Sareng urang kedah ngartos ieu. Ieu penting pisan, disebutkeun urang moal bisa ngarti ngonci di Postgres.
ID urus virtual nyaéta ID urus anu henteu ngandung nilai pengkuh. Salaku conto, upami kuring ngajalankeun paréntah SELECT, teras kuring sigana moal ngarobih pangkalan data, kuring moal ngonci nanaon. Janten nalika urang ngajalankeun SELECT saderhana, kami henteu masihan urus éta ID pengkuh. Kami ngan ukur masihan anjeunna ID virtual di dinya.
Sarta ieu ngaronjatkeun kinerja Postgres, ngaronjatkeun kamampuhan cleanup, jadi ID transaksi virtual diwangun ku dua angka. Jumlah kahiji saméméh slash mangrupa ID backend. Sarta di katuhu urang tingali ngan hiji counter.
Ku alatan éta, lamun kuring ngajalankeun pamundut a, éta nyebutkeun yen backend ID nyaeta 2.
Tur upami abdi ngajalankeun runtuyan transaksi misalna, lajeng urang tingali yen counter naek unggal waktos abdi ngajalankeun query a. Contona, nalika kuring ngajalankeun query 2/10, 2/11, 2/12, jsb.
Émut yén aya dua kolom di dieu. Di kénca kami ningali ID transaksi virtual - 2/12. Sarta di katuhu urang boga ID urus permanén. Jeung widang ieu kosong. Sareng transaksi ieu henteu ngarobih pangkalan data. Janten kuring henteu masihan ID transaksi permanén.
Pas kuring ngajalankeun paréntah analisa ((ANALYZE)), query sarua méré kuring ID urus permanén. Tingali kumaha ieu parantos robih pikeun urang. Abdi henteu ngagaduhan ID ieu sateuacanna, tapi ayeuna kuring gaduh éta.
Janten ieu pamundut sanés, transaksi sanés. Jumlah transaksi virtual nyaéta 2/13. Sareng upami kuring nyuhunkeun ID urus pengkuh, teras nalika kuring ngajalankeun pamundut, kuring bakal nampi.
Janten, sakali deui. Kami gaduh ID transaksi virtual sareng ID urus pengkuh. Ngan ngartos titik ieu ngartos kabiasaan Postgres.
Urang ngaléngkah ka bagian katilu. Di dieu urang ngan saukur bakal ngalangkungan sababaraha jinis konci dina Postgres. Teu pisan metot. Bagian panungtungan bakal leuwih metot. Tapi urang kudu mertimbangkeun hal dasar, sabab disebutkeun urang moal ngarti naon anu bakal kajadian salajengna.
Urang bakal ngaliwat bagian ieu, urang bakal ningali unggal jinis konci. Sareng kuring bakal nunjukkeun anjeun conto kumaha aranjeunna dipasang, kumaha jalanna, kuring bakal nunjukkeun anjeun sababaraha patarosan anu anjeun tiasa dianggo pikeun ningali kumaha ngonci jalan di Postgres.
Pikeun nyieun query jeung ningali naon lumangsung di Postgres, urang kudu ngaluarkeun query dina view sistem. Dina hal ieu, pg_lock disorot beureum. Pg_lock mangrupikeun tabel sistem anu nyarioskeun ka urang naon konci anu ayeuna dianggo di Postgres.
Nanging, sesah pisan pikeun kuring nunjukkeun anjeun pg_lock ku nyalira sabab éta rada rumit. Janten kuring nyiptakeun pandangan anu nunjukkeun pg_locks. Sareng éta ogé ngalakukeun sababaraha padamelan pikeun kuring anu ngamungkinkeun kuring ngartos langkung saé. Nyaéta, éta henteu kalebet konci kuring, sési kuring sorangan, jsb. Éta ngan ukur SQL standar sareng ngamungkinkeun anjeun pikeun nunjukkeun anjeun anu langkung saé.
masalah sejen nyaeta pintonan ieu pisan lega, jadi kuring kudu nyieun hiji kadua - lockview2.
Sarta eta nembongkeun kuring leuwih kolom ti tabél. Sareng hiji deui anu nunjukkeun kuring sesa kolom. Ieu rada rumit, janten kuring nyobian nampilkeunana sasederhana mungkin.
Janten kami nyiptakeun méja anu disebut Lockdemo. Sarta kami dijieun hiji garis aya. Ieu tabel sampel urang. Sarta kami bakal nyieun bagian ngan pikeun némbongkeun Anjeun conto konci.
Jadi, hiji baris, hiji kolom. Jenis konci kahiji disebut ACCESS SHARE. Ieu mangrupikeun pameungpeuk pangsaeutikna. Ieu ngandung harti yén éta praktis teu konflik jeung konci séjén.
Tur upami urang hoyong eksplisit nangtukeun konci, urang ngajalankeun paréntah "meja konci". Sareng écés bakal meungpeuk, nyaéta dina mode ACCESS SHARE kami ngaluncurkeun méja konci. Sareng upami kuring ngajalankeun PSQL di latar tukang, maka kuring ngamimitian sési kadua ti sési munggaran kuring ku cara kieu. Maksudna, naon anu bakal kuring laksanakeun di dieu? Kuring balik ka sési sejen tur ngabejaan eta "tunjukkeun kuring lockview pikeun pamundut ieu." Sarta di dieu kuring boga AccessShareLock dina tabel ieu. Ieu kahayang kuring dipénta. Sarta anjeunna nyebutkeun yen blok geus ditugaskeun. Basajan pisan.
Salajengna, upami urang ningali kolom kadua, teras teu aya nanaon. Aranjeunna kosong.
Sareng upami kuring ngajalankeun paréntah "PILIH", maka ieu mangrupikeun cara implisit (eksplisit) pikeun nyuhunkeun AccessShareLock. Ku kituna kuring ngaleupaskeun méja kuring sarta ngajalankeun pamundut na query mulih sababaraha baris. Sarta dina salah sahiji garis urang tingali AccessShareLock. Ku kituna, SELECT nelepon AccessShareLock dina tabél. Sareng éta henteu bertentangan sareng ampir naon waé sabab éta konci tingkat rendah.
Kumaha upami kuring ngajalankeun SELECT sareng gaduh tilu tabel anu béda? Saméméhna kuring ngan ngajalankeun hiji méja, ayeuna kuring ngajalankeun tilu: pg_class, pg_namespace na pg_attribute.
Sareng ayeuna nalika kuring ningali patarosan, kuring ningali 9 AccessShareLocks dina tilu tabel. Naha? Tilu tabel disorot warna biru: pg_attribute, pg_class, pg_namespace. Tapi anjeun ogé tiasa ningali yén sadaya indéks anu didefinisikeun ngaliwatan tabel ieu ogé ngagaduhan AccessShareLock.
Sareng ieu mangrupikeun konci anu praktis henteu bertentangan sareng anu sanés. Sareng sadaya anu dilakukeun nyaéta ngan ukur nyegah urang ngareset tabel nalika urang milih. Éta asup akal. Hartina, lamun urang milih méja, éta disappears dina momen anu, lajeng ieu salah, jadi AccessShare mangrupikeun konci tingkat rendah anu nyarioskeun ka urang "ulah leupaskeun méja ieu nalika kuring damel". Intina, éta waé anu anjeunna laksanakeun.
ROW SHARE - Konci ieu rada béda.
Hayu urang nyandak conto. SELECT ROW SHARE method pikeun ngonci unggal baris individual. Ku cara ieu teu aya anu tiasa ngahapus atanapi ngarobih nalika urang ningali.
Janten naon anu dilakukeun ku SHARE LOCK? Kami ningali yén ID transaksi nyaéta 681 pikeun PILIH. Jeung ieu metot. Naon anu lumangsung di dieu? Pertama kali urang ningali nomerna dina widang "Konci". Simkuring nyandak ID urus jeung nyebutkeun eta blocking eta dina modeu ekslusif. Kabéh hancana eta nyebutkeun kuring boga baris anu téhnisna dikonci wae dina tabél. Tapi anjeunna henteu nyarios dimana persisna. Urang bakal nempo ieu leuwih jéntré saeutik engké.
Di dieu urang nyebutkeun yén konci dipaké ku urang.
Janten, konci ekslusif sacara eksplisit nyarios yén éta ekslusif. Sareng upami anjeun ngahapus barisan dina tabel ieu, maka ieu anu bakal kajantenan, sakumaha anu anjeun tingali.
SHARE EXCLUSIVE mangrupikeun konci anu langkung panjang.
Ieu mangrupikeun paréntah analisa (ANALYZE) anu bakal dianggo.
SHARE LOCK - anjeun tiasa sacara eksplisit ngonci dina modeu bagikeun.
Anjeun oge bisa nyieun hiji indéks unik. Sareng anjeun tiasa ningali SHARE LOCK, anu mangrupikeun bagian tina aranjeunna. Sareng ngonci méja sareng nempatkeun KUNCI SHARE.
Sacara standar, SHARE LOCK dina méja ngandung harti yén jalma sanés tiasa maca tabél, tapi teu aya anu tiasa ngarobih. Sarta ieu kahayang kajadian mun anjeun nyieun hiji indéks unik.
Mun kuring nyieun hiji indéks concurrently unik, lajeng abdi bakal boga tipe béda tina ngonci sabab, sakumaha anjeun apal, ngagunakeun concurrently indexes ngurangan sarat ngonci. Sareng upami kuring nganggo konci normal, indéks normal, maka kuring bakal nyegah tulisan kana indéks méja nalika didamel. Upami kuring nganggo indéks sakaligus, maka kuring kedah nganggo jinis konci anu béda.
SHARE ROW EXCLUSIVE - deui tiasa diatur sacara eksplisit (eksplisit).
Atanapi urang tiasa nyiptakeun aturan, nyaéta, nyandak kasus khusus dimana éta bakal dianggo.
Ngonci EKSKLUSIF hartina teu saurang ogé bisa ngarobah tabél.
Di dieu urang ningali tipena béda konci.
ACCESS EXCLUSIVE, contona, nyaéta paréntah blocking. Contona, upami anjeun ngalakukeun CLUSTER table, teras ieu hartosna teu aya anu tiasa nyerat di dinya. Sarta eta ngonci teu ukur tabel sorangan, tapi ogé indexes.
Ieu mangrupikeun halaman kadua pameungpeuk ACCESS EXCLUSIVE, dimana urang ningali naon anu diblokir dina tabél. Ieu ngonci baris tabel individu, nu rada metot.
Éta sadayana inpormasi dasar anu kuring hoyong masihan. Urang ngobrol ngeunaan konci, ngeunaan ID transaksi, urang ngobrol ngeunaan ID transaksi virtual, ngeunaan ID transaksi permanén.
Tur ayeuna urang bakal ngaliwatan sababaraha conto blocking. Ieu bagian paling metot. Urang bakal nempo kasus pisan metot. Sareng tujuan kuring dina presentasi ieu nyaéta pikeun masihan anjeun pamahaman anu langkung saé ngeunaan naon anu dilakukeun ku Postgres nalika nyobian ngahalangan hal-hal anu tangtu. Jigana anjeunna pohara alus dina blocking kaluar bagian.
Hayu urang nempo sababaraha conto husus.
Urang mimitian ku tabel sarta hiji baris dina méja. Nalika kuring nyelapkeun hal kuring ExclusiveLock, Transaksi ID na ExclusiveLock dipintonkeun dina tabél.
Naon anu lumangsung lamun kuring nyelapkeun dua jajar deui? Sareng ayeuna méja urang ngagaduhan tilu jajar. Na kuring diselapkeun hiji baris jeung meunang ieu salaku kaluaran. Sareng upami kuring ngalebetkeun dua jajar deui, naon anu anéh? Aya hal aneh di dieu sabab kuring geus ditambahkeun tilu jajar tabel ieu, tapi kuring masih boga dua jajar dina tabel konci. Sareng ieu dasarna kabiasaan dasar Postgres.
Seueur jalma mikir yén upami dina pangkalan data anjeun ngonci 100 jajar, maka anjeun kedah nyiptakeun 100 éntri konci. Upami kuring meungpeuk 1 baris sakaligus, maka kuring peryogi 000 patarosan sapertos kitu. Sareng upami kuring peryogi sajuta atanapi samilyar pikeun meungpeuk. Tapi upami urang ngalakukeun ieu, éta moal jalan pisan. Upami anjeun parantos nganggo sistem anu nyiptakeun blokir éntri pikeun tiap barisan individu, maka anjeun tiasa ningali yén ieu pajeulit. Kusabab anjeun kedah langsung nangtukeun tabel konci anu tiasa ngabahekeun, tapi Postgres henteu ngalakukeun éta.
Sareng anu penting pisan ngeunaan slide ieu nyaéta yén éta jelas nunjukkeun yén aya sistem sanés anu ngajalankeun di jero MVCC anu ngonci barisan individu. Janten nalika anjeun ngonci milyaran baris, Postgres henteu nyiptakeun milyaran paréntah konci anu misah. Sareng ieu gaduh pangaruh anu saé pikeun produktivitas.
Kumaha upami apdet? Kuring ngamutahirkeun baris ayeuna, tur anjeun tiasa ningali yén éta geus dipigawé dua operasi béda sakaligus. Éta ngonci méja dina waktos anu sami, tapi ogé ngonci indéks. Sareng anjeunna kedah ngonci indéks kusabab aya konstrain unik dina méja ieu. Sareng kami hoyong mastikeun yén teu aya anu ngarobih, janten kami meungpeukna.
Naon anu bakal kajadian upami kuring hoyong ngapdet dua jajar? Sarta kami ningali yén anjeunna behaves cara sarua. Urang ngalakukeun dua kali loba apdet, tapi persis jumlah garis konci sarua.
Upami anjeun heran kumaha Postgres ngalakukeun ieu, anjeun kedah ngadangukeun ceramah kuring ngeunaan MVCC pikeun diajar kumaha Postgres sacara internal nyirian garis-garis ieu anu robih. Sareng Postgres gaduh cara pikeun ngalakukeun ieu, tapi henteu ngalakukeun dina tingkat ngonci méja, éta ngalakukeun dina tingkat anu langkung handap sareng langkung efisien.
Kumaha upami abdi hoyong mupus hiji hal? Upami kuring ngahapus, contona, hiji baris sareng kuring masih gaduh dua input blocking kuring, bahkan upami kuring hoyong ngahapus sadayana, aranjeunna masih aya.
Na, contona, abdi hoyong nyelapkeun 1 garis, lajeng boh ngahapus atawa nambahan 000 garis, lajeng maranéhanana garis individu nu kuring nambahan atawa ngarobah, aranjeunna teu kacatet di dieu. Éta ditulis dina tingkat anu langkung handap dina séri éta sorangan. Sareng salami pidato MVCC kuring nyarioskeun ieu sacara rinci. Tapi penting pisan nalika anjeun nganalisa konci pikeun mastikeun yén anjeun ngonci dina tingkat méja sareng anjeun henteu ningali kumaha barisan individu dirékam di dieu.
Kumaha upami meungpeuk eksplisit?
Mun kuring klik refresh, Kuring boga dua jajar dikonci. Sareng upami kuring milih sadayana teras klik "ngapdet dimana-mana," maka kuring masih gaduh dua rékaman blocking.
Urang teu nyieun rékaman misah pikeun tiap baris individu. Kusabab teras produktivitas turun, meureun aya seueur teuing. Sareng urang tiasa mendakan diri dina kaayaan anu teu pikaresepeun.
Sareng hal anu sami, upami urang dibagikeun, urang tiasa ngalakukeun sadayana 30 kali.
Urang mulangkeun tabel urang, ngahapus sagalana, lajeng selapkeun hiji baris deui.
kabiasaan sejen nu katingali dina Postgres anu kacida alusna dipikawanoh tur dipikahayang kabiasaan nyaeta nu bisa ngalakukeun update atawa pilih. Sareng anjeun tiasa ngalakukeun ieu dina waktos anu sami. Jeung pilih teu meungpeuk update jeung hal anu sarua dina arah nu lalawanan. Kami nyarioskeun ka pamaca supados henteu ngahalangan panulis, sareng panulis henteu ngahalangan pamaca.
Kuring gé nunjukkeun anjeun conto ieu. Kuring bakal nyieun pilihan ayeuna. Urang lajeng bakal ngalakukeun INSERT. Lajeng anjeun tiasa ningali - 694. Anjeun tiasa ningali ID tina urus anu dipigawé sisipan ieu. Tur éta kumaha gawéna.
Sareng upami kuring ningali ID backend kuring ayeuna, éta ayeuna 695.
Sareng abdi tiasa ningali 695 muncul dina méja kuring.
Sareng upami kuring ngamutahirkeun di dieu sapertos kieu, maka kuring nampi kasus anu béda. Dina hal ieu, 695 mangrupa konci ekslusif, sarta update boga kabiasaan anu sarua, tapi euweuh konflik antara aranjeunna, nu rada mahiwal.
Sareng anjeun tiasa ningali yén di luhur éta ShareLock, sareng di handapna ExclusiveLock. Jeung duanana transaksi digawé kaluar.
Sareng anjeun kedah ngadangukeun omongan kuring di MVCC pikeun ngartos kumaha ieu kajadian. Tapi ieu mangrupikeun ilustrasi anu anjeun tiasa lakukeun dina waktos anu sami, nyaéta ngalakukeun PILIH sareng UPDATE dina waktos anu sami.
Hayu urang ngareset sareng ngalakukeun hiji deui operasi.
Upami anjeun nyobian ngajalankeun dua apdet sakaligus dina baris anu sami, éta bakal diblokir. Jeung inget, ceuk kuring nu maca teu meungpeuk panulis, jeung nu nulis teu meungpeuk nu maca, tapi hiji panulis meungpeuk panulis séjén. Hartina, urang teu bisa boga dua jalma ngamutahirkeun baris sarua dina waktos anu sareng. Anjeun kedah ngantosan dugi salah sahijina réngsé.
Sareng pikeun ngagambarkeun ieu, kuring bakal ningali tabel Lockdemo. Sarta kami bakal kasampak di hiji baris. Per transaksi 698.
Kami parantos ngamutahirkeun ieu ka 2. 699 mangrupikeun pembaruan munggaran. Sareng éta suksés atanapi aya dina transaksi anu ditangguhkeun sareng ngantosan kami pikeun mastikeun atanapi ngabatalkeun.
Tapi tingali hal anu sanés - 2/51 mangrupikeun transaksi munggaran urang, sési munggaran urang. 3/112 teh pamundut kadua nu sumping ti luhur nu robah nilai nu ka 3. Tur upami Anjeun salah perhatikeun, luhureun hiji dikonci sorangan, anu mangrupa 699. Tapi 3/112 teu masihan konci. Kolom Lock_mode nyarioskeun naon anu diantosan. Ieu ekspektasi 699. Tur upami Anjeun salah nempo dimana 699 nyaeta, éta luhur. Sareng naon anu dilakukeun ku sési kahiji? Manehna nyieun hiji konci ekslusif on ID urus dirina sorangan. Ieu kumaha Postgres ngalakukeunana. Ieu blok ID urus sorangan. Sareng upami anjeun hoyong ngadagoan batur pikeun ngonfirmasi atanapi ngabatalkeun, maka anjeun kedah ngantosan nalika aya transaksi anu ditangguhkeun. Sareng sababna urang tiasa ningali garis anu aneh.
Hayu urang tingali deui. Di kénca kami ningali ID processing urang. Dina kolom kadua urang ningali ID transaksi virtual urang, sarta dina katilu urang ningali lock_type. Naon ieu hartosna? Intina naon anu dicarioskeun nyaéta ngahalangan ID urus. Tapi perhatikeun yén sadaya baris di handap nyarios hubungan. Sareng anjeun gaduh dua jinis konci dina méja. Aya konci hubungan. Lajeng aya nu meungpeuk transactionid, dimana anjeun meungpeuk sorangan, nu persis naon kajadian dina baris kahiji atawa di handap pisan, dimana transactionid nyaeta, dimana urang ngadagoan 699 nepi ka rengse operasi na.
Kuring gé ningali naon kajadian di dieu. Sareng di dieu dua hal lumangsung sakaligus. Anjeun ningali konci ID transaksi dina baris kahiji anu ngonci sorangan. Sareng anjeunna ngahalangan dirina pikeun ngajantenkeun jalma ngantosan.
Lamun nempo garis ka-6, eta teh entri sarua jeung kahiji. Ku kituna transaksi 699 diblokir. 700 ogé ngonci diri. Lajeng di baris handap anjeun bakal nempo yén urang nuju ngantosan 699 nepi ka rengse operasi na.
Sareng dina lock_type, tuple anjeun ningali nomer.
Anjeun tiasa ningali éta 0/10. Sareng ieu mangrupikeun nomer halaman, sareng ogé offset baris khusus ieu.
Sareng anjeun ningali éta janten 0/11 nalika urang ngamutahirkeun.
Tapi dina kanyataanana éta 0/10, sabab aya nungguan operasi ieu. Kami ngagaduhan kasempetan pikeun ningali yén ieu mangrupikeun séri anu kuring ngantosan pikeun mastikeun.
Sakali kami parantos ngonfirmasi sareng pencét commit, sareng nalika pembaruan parantos réngsé, ieu anu urang kéngingkeun deui. Transaksi 700 mangrupikeun hiji-hijina konci, éta henteu ngantosan saha waé sabab éta komitmen. Éta ngan ukur ngantosan transaksi réngsé. Sakali 699 béak, urang henteu ngantosan nanaon deui. Tur ayeuna urus 700 nyebutkeun yen sagalana geus rupa, yen eta boga sagala konci eta perlu dina sagala tabel diwenangkeun.
Sarta sangkan sakabeh hal ieu malah leuwih pajeulit, urang nyieun view sejen, nu waktos ieu bakal nyadiakeun kami kalawan hirarki a. Abdi henteu ngarepkeun anjeun ngartos pamundut ieu. Tapi ieu bakal masihan urang pandangan anu langkung jelas ngeunaan naon anu lumangsung.
Ieu mangrupikeun pandangan rekursif anu ogé ngagaduhan bagian anu sanés. Lajeng brings sagalana balik babarengan deui. Hayu urang nganggo ieu.
Kumaha lamun urang ngalakukeun tilu apdet simultaneous sarta nyebutkeun yén baris ayeuna tilu. Sareng urang bakal ngarobih 3 ka 4.
Sareng di dieu urang ningali 4. Sareng ID transaksi 702.
Lajeng abdi bakal ngarobah 4 ka 5. jeung 5 ka 6, jeung 6 ka 7. Sarta kuring baris nepi sababaraha jalma anu bakal ngantosan hiji transaksi ieu mungkas.
Jeung sagalana janten jelas. Naon baris kahiji? Ieu 702. Ieu ID urus nu asalna diatur nilai ieu. Naon anu diserat dina kolom Ditelasan kuring? Kuring boga tanda f. Ieu apdet kuring nu (5, 6, 7) teu bisa disatujuan sabab urang ngantosan ID urus 702 mungkas. Aya kami gaduh ID transaksi meungpeuk. Sarta ieu ngakibatkeun 5 konci ID transactional.
Sareng upami anjeun ningali 704, di 705, teu acan aya anu diserat, sabab henteu terang naon anu lumangsung. Éta ngan saukur nulis yén maranéhna teu boga pamanggih naon anu lumangsung. Sareng aranjeunna badé bobo sabab ngantosan batur réngsé sareng dihudangkeun nalika aya kasempetan pikeun ngarobih barisan.
Ieu naon eta Sigana mah. Éta jelas yén aranjeunna sadayana ngantosan garis ka-12.
Ieu naon urang nempo dieu. Ieu 0/12.
Janten saatos urus munggaran disatujuan, anjeun tiasa ningali di dieu kumaha hierarki jalanna. Tur ayeuna sagalana janten jelas. Éta kabéh jadi beresih. Jeung maranéhna sabenerna masih ngantosan.
Ieu naon anu lumangsung. 702 komitmen. Sareng ayeuna 703 kéngingkeun konci baris ieu, teras 704 ngamimitian ngantosan 703 komitmen. Sareng 705 ngantosan ieu ogé. Sareng nalika sadaya ieu réngsé, aranjeunna ngabersihan diri. Sareng kuring hoyong nunjukkeun yén sadayana ngantri. Sareng ieu sami sareng kaayaan macét nalika sadayana ngantosan mobil munggaran. Mobil kahiji eureun jeung dulur baris dina antrian panjang. Teras gerak, teras mobil salajengna tiasa maju sareng kéngingkeun blokna, jsb.
Sareng upami ieu henteu sigana pajeulit pikeun anjeun, maka kami ayeuna bakal ngobrol sareng anjeun ngeunaan deadlocks. Kuring henteu terang saha di antara anjeun anu parantos mendakan aranjeunna. Ieu masalah anu cukup umum dina sistem database. Tapi deadlocks nyaéta nalika hiji sési ngantosan sési anu sanés pikeun ngalakukeun hiji hal. Sareng dina waktos ieu sési sanés ngantosan sési munggaran pikeun ngalakukeun hiji hal.
Sareng, contona, upami Ivan nyarios: "Pasihan abdi hiji hal," sareng kuring nyarios: "Henteu, kuring ngan ukur bakal masihan ka anjeun upami anjeun masihan kuring anu sanés." Sareng anjeunna nyarios, "Henteu, kuring moal masihan ka anjeun upami anjeun henteu masihan ka kuring." Sarta kami mungkas nepi dina kaayaan deadlock. Kuring yakin yén Ivan moal ngalakukeun ieu, tapi anjeun ngartos hartina urang boga dua jalma anu hayang meunang hiji hal sarta aranjeunna henteu siap masihan eta jauh nepi ka jalma séjén méré aranjeunna naon maranéhna rék. Sareng teu aya solusi.
Sareng dasarna, pangkalan data anjeun kedah ngadeteksi ieu. Teras anjeun kedah ngahapus atanapi nutup salah sahiji sesi, sabab upami henteu aranjeunna bakal tetep aya salamina. Sareng urang ningali dina pangkalan data, urang ningali dina sistem operasi. Sareng di sadaya tempat dimana urang gaduh prosés paralel, ieu tiasa kajantenan.
Tur ayeuna urang bakal masang dua deadlocks. Kami bakal nempatkeun 50 sareng 80. Dina baris kahiji, kuring bakal ngamutahirkeun tina 50 ka 50. Kuring bakal nampi nomer transaksi 710.
Teras kuring bakal ngarobih 80 janten 81, sareng 50 janten 51.
Sareng ieu anu bakal katingalina. Janten 710 gaduh barisan diblokir, sareng 711 ngantosan konfirmasi. Urang nempo ieu nalika urang diropéa. 710 mangrupikeun pamilik séri kami. Sareng 711 ngantosan 710 pikeun ngarengsekeun transaksi.
Sarta eta malah nyebutkeun on nu baris deadlocks lumangsung. Jeung di dieu nu dimimitian jadi aneh.
Ayeuna urang ngamutahirkeun 80 ka 80.
Sareng ieu dimana deadlocks dimimitian. 710 ngantosan respon ti 711, sarta 711 ngantosan 710. Sarta ieu moal mungkas ogé. Sareng teu aya jalan kaluar tina ieu. Jeung maranéhna bakal nyangka respon ti unggal lianna.
Sarta eta ngan bakal mimiti reureuh sagalana. Sareng urang henteu hoyong éta.
Sareng Postgres gaduh cara pikeun perhatikeun nalika ieu kajantenan. Sareng nalika ieu kajantenan, anjeun nampi kasalahan ieu. Sareng ieu jelas yén prosés sapertos kitu ngantosan KUNCI SHARE tina prosés anu sanés, nyaéta, anu diblokir ku prosés 711. Sareng prosés éta ngantosan KUNCI SHARE dipasihkeun dina ID transaksi sapertos kitu sareng diblokir ku prosés sapertos kitu. Ku alatan éta, aya kaayaan deadlock di dieu.
Aya deadlock tilu arah? Éta mungkin waé? Sumuhun.
Urang asupkeun angka ieu kana méja. Urang ngarobah 40 ka 40, urang ngalakukeun blocking.
Urang ngarobah 60 ka 61, 80 ka 81.
Lajeng urang ngarobah 80 lajeng booming!
Sareng 714 ayeuna ngantosan 715. 716 ngantosan 715. Sareng teu aya anu tiasa dilakukeun ngeunaan éta.
Geus teu aya dua urang di dieu, geus aya tilu urang di dieu. Abdi hoyong hiji hal ti anjeun, hiji ieu hayang hal ti jalma katilu, sarta jalma katilu hayang hal ti kuring. Sareng urang mungkas dina antosan tilu arah sabab urang sadayana ngantosan jalma sanés ngalengkepan naon anu kedah dilakukeun.
Sareng Postgres terang dina barisan mana ieu kajantenan. Sarta eta bakal masihan anjeun pesen handap, nu nunjukeun yen anjeun gaduh masalah dimana tilu inputs blocking silih. Sareng henteu aya larangan di dieu. Ieu tiasa janten kasus dimana 20 éntri saling meungpeuk.
Masalah salajengna nyaeta serializable.
Upami konci serializable husus.
Sarta kami balik deui ka 719. Kaluaran na cukup normal.
Sareng anjeun tiasa klik pikeun ngadamel transaksi tina serializable.
Sareng anjeun sadar yén anjeun ayeuna gaduh jinis konci SA anu béda - hartosna tiasa séri.
Ku kituna urang boga tipe anyar konci disebut SARieadLock, nu mangrupakeun konci serial sarta ngidinan Anjeun pikeun nuliskeun serials.
Sareng anjeun ogé tiasa nyelapkeun indéks unik.
Dina tabél ieu kami gaduh indéks unik.
Ku kituna lamun kuring nempatkeun dina angka 2 dieu, jadi kuring boga 2. Tapi di luhur pisan, abdi nempatkeun sejen 2 di. Tur anjeun tiasa ningali yén 721 boga konci ekslusif. Tapi ayeuna 722 ngantosan 721 pikeun ngarengsekeun operasina sabab teu tiasa ngalebetkeun 2 dugi ka terang naon anu bakal kajadian ka 721.
Sareng upami urang ngalakukeun subtransaksi.
Di dieu urang gaduh 723.
Tur upami urang nyimpen titik lajeng ngamutahirkeun eta, lajeng urang meunang ID urus anyar. Ieu mangrupikeun pola kabiasaan anu sanés anu anjeun kedah perhatosan. Upami urang uih deui ieu, maka ID urus bakal ngaleungit. 724 indit. Tapi ayeuna urang gaduh 725.
Janten naon anu kuring badé lakukeun di dieu? Kuring nyobian nunjukkeun anjeun conto konci anu teu biasa anu anjeun tiasa mendakan: naha éta konci serializable atanapi SAVEPOINT, ieu mangrupikeun sababaraha jinis konci anu bakal muncul dina méja konci.
Ieu nyiptakeun konci eksplisit (eksplisit), anu ngagaduhan pg_advisory_lock.
Sareng anjeun ningali yén jinis pameungpeuk kadaptar salaku piwuruk. Sarta di dieu nyebutkeun "piwuruk" beureum. Sareng anjeun tiasa sakaligus meungpeuk sapertos kieu sareng pg_advisory_unlock.
Sareng kacindekan, kuring hoyong nunjukkeun ka anjeun hiji hal anu pikaresepeun. Kuring gé nyieun view sejen. Tapi kuring bakal gabung tabel pg_locks kalawan tabel pg_stat_activity. Jeung naha kuring hayang ngalakukeun ieu? Kusabab ieu bakal ngamungkinkeun kuring ningali sareng ningali sadaya sési ayeuna sareng ningali persis jinis konci anu aranjeunna ngantosan. Sarta ieu rada metot lamun urang nunda babarengan tabel konci na tabel query.
Sarta di dieu urang nyieun pg_stat_view.
Sarta kami ngamutahirkeun baris ku hiji. Sarta di dieu urang tingali 724. Lajeng urang ngamutahirkeun baris kami ka tilu. Sareng naon anu anjeun tingali di dieu ayeuna? Ieu mangrupikeun pamundut, nyaéta anjeun ningali sadaya daptar pamundut anu didaptarkeun dina kolom kénca. Teras di sisi katuhu anjeun tiasa ningali sumbatan sareng naon anu aranjeunna ciptakeun. Sareng tiasa langkung jelas pikeun anjeun supados anjeun henteu kedah uih deui ka unggal sési unggal waktos sareng ningali upami anjeun kedah ngiringan atanapi henteu. Aranjeunna ngalakukeun pikeun urang.
Fitur séjén anu mangpaat pisan nyaéta pg_blocking_pids. Anjeun meureun geus pernah ngadéngé dirina. Naon anu anjeunna lakukeun? Hal ieu ngamungkinkeun urang pikeun ngabejaan yen pikeun sési ieu 11740 naon ID prosés husus eta ngantosan. Sareng anjeun tiasa ningali yén 11740 ngantosan 724. sareng 724 di luhur pisan. Sareng 11306 mangrupikeun ID prosés anjeun. Intina, fungsi ieu ngalangkungan méja konci anjeun. Sareng kuring terang éta rada rumit, tapi anjeun tiasa ngartos éta. Intina fungsi ieu ngaliwat méja konci ieu sareng nyobian milarian dimana ID prosés ieu dibéré konci anu ngantosan. Sarta eta oge nyoba angka kaluar nu prosés ID prosés nu ngantosan konci boga. Janten anjeun tiasa ngajalankeun fungsi ieu pg_blocking_pids.
Sareng ieu tiasa mangpaat pisan. Kami ngan ukur nambihan ieu dina versi 9.6, janten fitur ieu ngan ukur 5 taun, tapi éta pisan, mangpaat pisan. Jeung sarua lumaku pikeun pamundut kadua. Éta nunjukkeun persis naon anu urang kedah tingali.
Ieu naon Kuring hayang ngobrol jeung anjeun ngeunaan. Sareng sakumaha anu kuring ngarepkeun, kami nganggo sadaya waktos kusabab seueur slide. Jeung slides sadia pikeun diundeur. Abdi hoyong hatur nuhun pikeun aya di dieu. Kuring yakin anjeun bakal ngarasakeun sesa konferensi, hatur nuhun pisan!
patarosan:
Salaku conto, upami kuring nyobian ngapdet baris, sareng sési kadua nyobian ngahapus sadaya méja. Sajauh kuring ngartos, kedah aya anu sapertos konci hajat. Naha aya anu sapertos kitu di Postgres?
Hayu urang balik deui ka awal. Anjeun tiasa émut yén nalika anjeun ngalakukeun nanaon, contona nalika anjeun ngalakukeun PILIH, kami ngaluarkeun AccessShareLock. Sarta ieu nyegah tabel turun. Janten upami anjeun, contona, hoyong ngapdet baris dina tabel atanapi ngahapus barisan, maka batur henteu tiasa ngahapus sadayana tabel dina waktos anu sami sabab anjeun nahan AccessShareLock ieu dina sadaya méja sareng dina barisan. Sareng upami anjeun parantos réngsé, aranjeunna tiasa ngahapus. Tapi bari anjeun langsung ngarobah hiji hal aya, aranjeunna moal bisa ngalakukeun eta.
Hayu urang ngalakukeun deui. Hayu urang ngaléngkah ka conto ngahapus. Sareng anjeun ningali kumaha aya konci ekslusif dina barisan luhureun sadaya méja.
Ieu bakal kasampak kawas konci ekslusif, katuhu?
Enya, siga kitu. Abdi ngartos naon anu anjeun nyarios. Anjeun nyarios yén upami kuring ngalakukeun SELECT teras kuring gaduh ShareExclusive teras kuring ngajantenkeun Row Exclusive, naha éta janten masalah? Tapi héran ieu henteu janten masalah. Ieu sigana ningkatkeun gelar konci, tapi dasarna kuring gaduh konci anu nyegah ngahapus. Sareng ayeuna, nalika kuring ngajantenkeun konci ieu langkung kuat, éta tetep nyegah ngahapus. Jadi teu siga kuring naék. Nyaéta, éta nyegah kajadian nalika éta dina tingkat anu langkung handap ogé, janten nalika kuring naékkeun tingkatna éta tetep nyegah tabel tina dihapus.
Abdi ngartos naon anu anjeun nyarios. Henteu aya kasus escalation konci di dieu, dimana anjeun nyobian nyerah hiji konci pikeun ngenalkeun anu langkung kuat. Di dieu eta ngan ngaronjatkeun pencegahan ieu sakuliah dewan, jadi teu ngabalukarkeun konflik nanaon. Tapi éta patarosan anu saé. Hatur nuhun pisan pikeun naroskeun ieu!
Naon anu urang kedah laksanakeun pikeun ngahindarkeun kaayaan buntu nalika urang gaduh seueur sesi, sajumlah ageung pangguna?
Postgres otomatis perhatikeun kaayaan deadlock. Sareng otomatis bakal ngahapus salah sahiji sesi. Hiji-hijina jalan pikeun nyegah pamblokiran maot nyaéta pikeun meungpeuk jalma dina urutan anu sami. Janten nalika anjeun ningali aplikasi anjeun, sering janten alesan pikeun deadlocks ... Hayu urang ngabayangkeun yén kuring hoyong meungpeuk dua hal anu béda. Hiji aplikasi ngonci méja 1, sarta aplikasi sejen ngonci 2, lajeng méja 1. Jeung cara panggampangna pikeun nyingkahan deadlocks nyaéta katingal dina aplikasi anjeun sarta nyoba pastikeun yén ngonci lumangsung dina urutan anu sarua dina sakabéh aplikasi. Sareng ieu biasana ngaleungitkeun 80% tina masalah, sabab sagala jinis jalma nyerat aplikasi ieu. Sareng upami anjeun meungpeuk aranjeunna dina urutan anu sami, maka anjeun moal mendakan kaayaan buntu.
Hatur nuhun pisan pikeun pagelaran anjeun! Anjeun nyarioskeun ngeunaan vakum pinuh sareng, upami kuring ngartos leres, vakum pinuh ngarobih urutan rékaman dina panyimpenan anu misah, ku kituna aranjeunna tetep rékaman ayeuna henteu robih. Naha vakum pinuh nyandak aksés konci ekslusif sareng naha éta bertentangan sareng operasi nyerat?
Éta patarosan anu saé. Alesanna nyaéta vakum pinuh nyandak méja. Sarta kami dasarna nyieun versi anyar tina tabél. Jeung tabél bakal anyar. Tétéla ieu bakal versi lengkep anyar tina tabél. Sareng masalahna nyaéta nalika urang ngalakukeun ieu, urang henteu hoyong jalma anu maca éta kusabab urang peryogi aranjeunna ningali tabel énggal. Sareng ieu nyambung ka patarosan sateuacana. Upami urang tiasa maca dina waktos anu sami, urang moal tiasa mindahkeun éta sareng ngarahkeun jalma kana méja énggal. Urang bakal kudu ngadagoan dulur rengse maca tabel ieu, sarta jadi dasarna mangrupa kaayaan konci ekslusif.
Kami ngan ukur nyarios yén kami ngonci ti mimiti sabab kami terang yén dina tungtungna kami peryogi konci ekslusif pikeun mindahkeun sadayana kana salinan énggal. Janten urang berpotensi tiasa ngabéréskeun ieu. Sarta kami ngalakukeun eta ku cara kieu jeung indexing simultaneous. Tapi ieu leuwih hese pikeun ngalakukeun. Sareng ieu pisan aya hubunganana sareng patarosan sateuacana ngeunaan konci ekslusif.
Naha mungkin pikeun nambihan waktos konci pikeun Postgres? Dina Oracle, kuring tiasa, contona, nyerat "pilih pikeun ngapdet" sareng ngantosan 50 detik sateuacan ngapdet. Éta saé pikeun aplikasi. Tapi dina Postgres, kuring kedah ngalakukeun éta langsung sareng henteu ngantosan pisan, atanapi ngantosan dugi ka sababaraha waktos.
Leres, anjeun tiasa milih waktos béak dina konci anjeun, dina konci anjeun. Anjeun oge bisa ngaluarkeun paréntah no way, nu bakal ... lamun teu bisa langsung ménta konci. Ku alatan éta, boh waktu konci konci atawa hal sejenna anu bakal ngidinan Anjeun pikeun ngalakukeun ieu. Ieu henteu dilakukeun dina tingkat sintaksis. Hal ieu dilakukeun salaku variabel dina server. Kadang ieu teu bisa dipaké.
Dupi anjeun tiasa muka slide 75?
Sumuhun.
Sareng patarosan abdi nyaéta kieu. Naha duanana prosés update ngaharepkeun 703?
Sareng ieu mangrupikeun patarosan anu saé. Abdi henteu ngartos, ku jalan kitu, naha Postgres ngalakukeun ieu. Tapi nalika 703 diciptakeun, éta ngarepkeun 702. Sareng nalika 704 sareng 705 muncul, sigana aranjeunna henteu terang naon anu diarepkeun sabab teu aya nanaon. Sareng Postgres ngalakukeun ieu ku cara kieu: nalika anjeun henteu tiasa kéngingkeun konci, nyerat "Naon gunana ngolah anjeun?", Kusabab anjeun parantos ngantosan batur. Janten urang ngantepkeun éta ngagantung dina hawa, éta moal ngapdet pisan. Tapi naon anu lumangsung di dieu? Pas 702 réngsé prosés sareng 703 nampi konci na, sistemna balik deui. Sareng anjeunna nyarios yén ayeuna urang gaduh dua jalma anu ngantosan. Lajeng hayu urang ngamutahirkeun aranjeunna babarengan. Sareng hayu urang nunjukkeun yén duanana ngarep-ngarep.
Kuring henteu weruh naha Postgres ngalakukeun ieu. Tapi aya masalah anu disebut f…. Sigana mah ieu téh lain istilah di Rusia. Ieu nalika sadayana ngantosan hiji kastil, sanaos aya 20 otoritas anu ngantosan benteng. Sarta ujug-ujug aranjeunna sadayana hudang dina waktos anu sareng. Jeung dulur mimiti nyoba meta. Tapi sistem ngajadikeun eta sadayana ngantosan 703. Kusabab aranjeunna sadayana ngantosan, sarta kami baris geura-giru baris aranjeunna sadayana up. Sareng upami aya pamundut énggal anu muncul saatos ieu, contona, 707, maka bakal aya kosong deui.
Sareng sigana kuring yén ieu dilakukeun ku kituna urang tiasa nyarios yén dina tahap ieu 702 ngantosan 703, sareng sadayana anu sumping saatos éta moal ngagaduhan éntri dina widang ieu. Tapi pas palayan munggaran angkat, sadaya jalma anu ngantosan dina waktos éta sateuacan pembaruan nampi token anu sami. Sareng kuring pikir ieu dilakukeun supados urang tiasa ngolah supados aranjeunna leres-leres dipesen.
Kuring sok nempo ieu fenomena rada aneh. Kusabab di dieu, contona, urang henteu daptar aranjeunna sadayana. Tapi sigana mah unggal waktos urang masihan konci anyar, urang kasampak di sakabeh jalma anu dina prosés ngantosan. Teras we baris aranjeunna sadayana. Lajeng nu mana wae nu anyar nu datang ngan meunang kana antrian lamun jalma salajengna geus rengse diprosés. Patarosan anu saé pisan. Hatur nuhun pisan pikeun patarosan anjeun!
Sigana mah eta leuwih logis lamun 705 ekspektasi 704.
Tapi masalahna di dieu nyaéta di handap ieu. Téhnisna, anjeun tiasa hudang hiji atawa lianna. Sarta sangkan urang bakal hudang hiji atawa lianna. Tapi naon anu lumangsung dina sistem? Anjeun tiasa ningali kumaha 703 di luhur pisan ngablokir ID transaksi na sorangan. Ieu kumaha Postgres jalan. Sareng 703 diblokir ku ID transaksi sorangan, janten upami aya anu hoyong ngantosan, maka aranjeunna bakal ngantosan 703. Sareng, panggih, 703 parantos réngsé. Sareng ngan saatos réngsé salah sahiji prosés ngahudangkeun. Sareng urang henteu terang naon persisna prosés ieu bakal. Teras we ngolah sadayana sacara bertahap. Tapi teu jelas prosés mana anu dihudangkeun heula, sabab tiasa waé tina prosés ieu. Intina, urang ngagaduhan jadwal anu nyarios yén urang ayeuna tiasa ngahudangkeun prosés ieu. Urang ngan milih hiji sacara acak. Ku kituna duanana perlu diperhatikeun sabab urang bisa ngahudangkeun duanana.
Jeung masalahna nyaeta urang boga CP-teu aya watesna. Ku kituna, éta rada kamungkinan yén urang bisa hudang hiji engké. Sareng upami, contona, urang ngahudangkeun anu engke, urang bakal ngantosan anu nembé nampi blok, janten urang henteu nangtukeun saha anu leres-leres bakal dihudangkeun heula. Urang saukur nyieun kaayaan kitu, sarta sistem bakal awaken aranjeunna dina urutan acak.
aya . Tingali, aranjeunna ogé metot sarta mangpaat. Topik, tangtosna, rumit pisan. Hatur nuhun pisan, Bruce!
sumber: www.habr.com