Брюс Момжиандын 2020-жылдагы "Postgres кулпу менеджеринин кулпусун ачуу" баяндамасынын стенограммасы.
(Эскертүү: слайддардагы бардык SQL сурамдарын бул шилтемеден алса болот: )
Салам! Бул жерде кайрадан Россияда болуу абдан жакшы. Былтыр келе албай калганыма өкүнөм, бирок быйыл Иван экөөбүздүн пландарыбыз чоң. Мен бул жерде дагы көп болот деп үмүттөнөм. Мен Россияга келгенди жакшы көрөм. Тюменьге, Тверьге барам. Мен бул шаарларды кыдырганыма абдан кубанычтамын.
Менин атым Брюс Момжян. Мен EnterpriseDBде иштейм жана Postgres менен 23 жылдан ашык иштеп келем. Мен АКШнын Филадельфия шаарында жашайм. Мен жылына 90 күн саякат кылам. Ал эми 40ка жакын конференцияга катышам. менин , анда мен азыр көрсөтө турган слайддар бар. Ошондуктан, конференциядан кийин аларды менин жеке сайтымдан көчүрүп алсаңыз болот. Ошондой эле 30га жакын презентацияларды камтыйт. Ошондой эле видеолор жана көптөгөн блог жазуулары бар, 500дөн ашык. Бул кыйла маалыматтык ресурс. Жана эгер сизди бул материал кызыктырса, анда мен сизди аны колдонууга чакырам.
Мен Postgres менен иштешкенге чейин мугалим, профессор болгом. Жана мен азыр сизге айта турган нерсемди айта алганыма абдан кубанычтамын. Бул менин эң кызыктуу презентацияларымдын бири. Ал эми бул презентацияда 110 слайд бар. Жөнөкөй нерселерден сүйлөй баштайбыз, акырында баяндама барган сайын татаалдашып, кыйла татаал болуп калат.
Бул абдан жагымсыз сүйлөшүү. Бөгөттөө эң популярдуу тема эмес. Биз мунун бир жерде жок болушун каалайбыз. Бул тиш доктурга баргандай.
- Кулпулоо - бул маалымат базаларында иштеген жана бир эле учурда бир нече процесс иштеген көптөгөн адамдар үчүн көйгөй. Аларга бөгөт коюу керек. Башкача айтканда, бүгүн мен сизге блоктоо боюнча негизги билимдерди берем.
- Транзакция ID'лери. Бул презентациянын абдан кызыксыз бөлүгү, бирок аларды түшүнүү керек.
- Кийинки биз бөгөттөөнүн түрлөрү жөнүндө сүйлөшөбүз. Бул бир кыйла механикалык бөлүгү болуп саналат.
- Ал эми төмөндө биз бөгөт коюунун бир нече мисалдарын келтиребиз. Жана аны түшүнүү абдан кыйын болот.
Келгиле, бөгөт коюу жөнүндө сүйлөшөлү.
Биздин терминология абдан татаал. Бул үзүндү кайдан келгенин канчаңыз билесиз? Эки киши. Бул Colossal Cave Adventure деп аталган оюндан. Бул 80-жылдары текстке негизделген компьютердик оюн болчу, менимче. Ал жерде сиз үңкүргө, лабиринтке киришиңиз керек болчу, текст өзгөрдү, бирок мазмуну ар дайым бирдей болгон. Мен бул оюнду ошентип эстедим.
Жана бул жерде биз Oracle бизге келген кулпулардын атын көрүп жатабыз. Биз аларды колдонобуз.
Бул жерде мени чаташтырган терминдерди көрүп жатабыз. Мисалы, SHARE UPDATE ECXLUSIVE. Кийинки SHARE RAW ECXLUSIVE. Чынын айтсам, бул ысымдар анча так эмес. Биз аларды кененирээк карап чыгууга аракет кылабыз. Кээ бирлери бөлүү дегенди билдирген "үлүш" деген сөздү камтыйт. Айрымдарында "эксклюзивдик" деген сөз бар. Айрымдарында бул эки сөз тең камтылган. Мен бул кулпулар кантип иштешинен баштагым келет.
Ал эми "мүмкүнчүлүк" деген сөз да абдан маанилүү. Ал эми "катар" деген сөздөр сап болуп саналат. Башкача айтканда, кирүү бөлүштүрүү, катар бөлүштүрүү.
Postgresте түшүнүшү керек болгон дагы бир маселе, тилекке каршы, мен өз баяндамамда айта албайм, бул MVCC. Менин веб-сайтымда бул тема боюнча өзүнчө презентациям бар. Эгер сиз бул презентацияны кыйын деп ойлосоңуз, MVCC менин эң кыйыным. Ал эми сизди кызыктырса сайттан көрсөңүз болот. Сиз видеону көрө аласыз.
Биз түшүнүшүбүз керек болгон дагы бир нерсе - транзакциянын ID'лери. Көптөгөн транзакциялар уникалдуу идентификаторсуз иштей албайт. Жана бул жерде биз транзакция деген эмне экенин түшүндүрөбүз. Postgres эки транзакцияны номерлөө системасы бар. Мен бул абдан жакшы чечим эмес экенин билем.
Ошондой эле слайддарды түшүнүү бир топ кыйын болорун эстен чыгарбаңыз, андыктан кызыл түс менен белгиленген нерсеге көңүл бурушуңуз керек.
көрөлү. Транзакциянын номери кызыл түс менен белгиленген. SELECT pg_back функциясы бул жерде көрсөтүлгөн. Ал менин транзакциямды жана транзакциянын идентификаторун кайтарат.
Дагы бир нерсе, эгер сизге бул презентация жакса жана аны өз базаңызда иштеткиңиз келсе, анда бул шилтемеге кызгылт түстө өтүп, бул презентация үчүн SQL жүктөп алсаңыз болот. Жана сиз аны жөн гана PSQLде иштетсеңиз болот жана бүт презентация дароо экраныңызда болот. Анда гүл болбойт, бирок биз аны көрө алабыз.
Бул учурда биз транзакция идентификаторун көрөбүз. Бул биз ага берген номер. Ал эми Postgresте транзакция идентификаторунун дагы бир түрү бар, ал виртуалдык транзакция ID деп аталат
Жана биз муну түшүнүшүбүз керек. Бул абдан маанилүү, антпесе Postgresте кулпулоону түшүнө албайбыз.
Виртуалдык транзакция идентификатору туруктуу маанилерди камтыбаган транзакция ID болуп саналат. Мисалы, мен SELECT буйругун иштетсем, анда мен маалымат базасын өзгөртпөйм, эч нерсени кулпулап салбайм. Ошентип, биз жөнөкөй ТАНДООну иштеткенде, биз ал транзакцияга туруктуу ID бербейбиз. Биз ага виртуалдык ID гана беребиз.
Жана бул Postgres ишин жакшыртат, тазалоо мүмкүнчүлүктөрүн жакшыртат, ошондуктан виртуалдык транзакция ID эки сандан турат. Кыйык сызыктын алдындагы биринчи сан - арткы идентификатор. Ал эми оң жакта биз жөн гана эсептегичти көрөбүз.
Ошондуктан, мен суранычты иштетсем, ал backend ID 2 деп айтылат.
Эгерде мен мындай транзакциялардын сериясын жүргүзсөм, анда мен суроону аткарган сайын эсептегич көбөйөрүн көрөбүз. Мисалы, мен суроону иштеткенде 2/10, 2/11, 2/12 ж.б.
Бул жерде эки тилке бар экенин унутпаңыз. Сол жакта биз виртуалдык транзакциянын идентификаторун көрөбүз – 2/12. Ал эми оң жакта бизде туруктуу транзакция ID бар. Жана бул талаа бош. Жана бул транзакция маалымат базасын өзгөртпөйт. Ошондуктан мен ага туруктуу транзакция ID бербейм.
Талдоо буйругун ((ANALYZE)) иштетээрим менен, ошол эле суроо мага туруктуу транзакция ID берет. Бул биз үчүн кандай өзгөргөнүн караңыз. Мурда менде бул ID жок болчу, бирок азыр бар.
Ошентип, бул жерде дагы бир өтүнүч, дагы бир транзакция. Виртуалдык транзакциянын номери 2/13. Эгерде мен туруктуу транзакция идентификаторун сурасам, анда мен сурамды иштеткенде, мен аны алам.
Ошентип, дагы бир жолу. Бизде виртуалдык транзакция ID жана туруктуу транзакция ID бар. Postgres жүрүм-турумун түшүнүү үчүн бул пунктту түшүнүү.
Биз үчүнчү бөлүмгө өтөбүз. Бул жерде биз жөн гана Postgres кулпуларынын ар кандай түрлөрүн кыдырып чыгабыз. Бул абдан кызыктуу эмес. Акыркы бөлүм алда канча кызыктуу болот. Бирок биз негизги нерселерди эске алышыбыз керек, анткени антпесе мындан ары эмне болорун түшүнбөй калабыз.
Биз бул бөлүмдү карап чыгабыз, кулпунун ар бир түрүн карап чыгабыз. Мен сизге алардын кантип орнотулганын, кантип иштешин мисалдарды көрсөтөм, мен сизге Postgres'те кулпулоо кандай иштээрин көрүү үчүн колдоно турган кээ бир суроолорду көрсөтөм.
Сурам түзүү жана Postgresте эмне болуп жатканын көрүү үчүн, биз сурамды системанын көрүнүшүндө чыгарышыбыз керек. Бул учурда, pg_lock кызыл менен белгиленет. Pg_lock – Postgresте кандай кулпулар колдонулуп жатканын айтып турган системалык таблица.
Бирок, мен үчүн сизге pg_lock көрсөтүү абдан кыйын, анткени ал абдан татаал. Ошентип, мен pg_locks көрсөткөн көрүнүш түздүм. Ошондой эле бул мага жакшыраак түшүнүүгө мүмкүндүк берген кээ бир иштерди аткарат. Башкача айтканда, ал менин кулпуларымды, өзүмдүн сеансымды ж.б. киргизбейт. Бул жөн гана стандарттуу SQL жана сизге эмне болуп жатканын жакшыраак көрсөтүүгө мүмкүндүк берет.
Дагы бир көйгөй, бул көрүнүш абдан кенен, ошондуктан мен экинчисин түзүшүм керек - lockview2.
Ал мага таблицадан көбүрөөк мамычаларды көрсөтөт. Ал эми калган тилкелерди көрсөткөн дагы бир. Бул абдан татаал, ошондуктан мен аны мүмкүн болушунча жөнөкөй көрсөтүүгө аракет кылдым.
Ошентип, биз Lockdemo деп аталган таблицаны түздүк. Жана биз ошол жерде бир линия түздүк. Бул биздин үлгү стол болуп саналат. Жана биз сизге кулпулардын мисалдарын көрсөтүү үчүн бөлүмдөрдү түзөбүз.
Ошентип, бир катар, бир тилке. Кулпунун биринчи түрү ACCESS SHARE деп аталат. Бул эң аз чектөөчү бөгөттөө. Бул иш жүзүндө башка кулпулар менен карама-каршы келбейт дегенди билдирет.
Ал эми кулпуну так аныктагыбыз келсе, биз "кулпу таблицасы" буйругун аткарабыз. Ал ачык эле бөгөттөлөт, б.а. ACCESS SHARE режиминде биз кулпу үстөлүн ишке киргизебиз. Эгерде мен PSQLди фондо иштетсем, анда биринчи сессиямдан экинчи сессияны ушинтип баштайм. Башкача айтканда, мен бул жерде эмне кылам? Мен башка сессияга барып, ага "бул сурамдын кулпусун көрсөт" деп айтам. Бул жерде менде бул таблицада AccessShareLock бар. Бул так мен суранган нерсе. Анан блок дайындалды дейт. Өтө жөнөкөй.
Андан ары, экинчи тилкеге карасак, анда эч нерсе жок. Алар бош.
Жана эгер мен "ТАНДОО" буйругун иштетсем, анда бул AccessShareLock өтүнүчүнүн ачык (ачык) жолу. Ошентип, мен таблицамды бошотуп, суроону иштетем жана сурам бир нече саптарды кайтарат. Жана саптардын биринде биз AccessShareLock көрөбүз. Ошентип, SELECT столдо AccessShareLockти чакырат. Жана бул иш жүзүндө эч нерсеге карама-каршы келбейт, анткени ал төмөнкү деңгээлдеги кулпу.
Мен SELECT иштетсем жана үч башка таблицага ээ болсом эмне болот? Мурда мен бир гана столду иштетип жүрсөм, азыр үчөөнү иштетип жатам: pg_class, pg_namespace жана pg_attribute.
Эми мен суроону караганымда, үч таблицада 9 AccessShareLocks көрөм. Неге? Үч таблица көк түс менен белгиленген: pg_attribute, pg_class, pg_namespace. Бирок сиз бул таблицалар аркылуу аныкталган бардык индекстерде AccessShareLock да бар экенин көрө аласыз.
Жана бул иш жүзүндө башкалар менен карама-каршы келбейт кулпу болуп саналат. Жана мунун баары, биз аны тандап жатканда, үстөлдү баштапкы абалга келтирүүгө жол бербейт. Бул мааниси бар. Башкача айтканда, эгерде биз таблицаны тандасак, ал ошол учурда жок болот, демек бул туура эмес, ошондуктан AccessShare бул төмөнкү деңгээлдеги кулпу, ал бизге "мен иштеп жатканда бул үстөлдү түшүрбөңүз" дейт. Негизи, ал мунун баары.
ROW SHARE - Бул кулпу бир аз башкачараак.
Мисал келтирели. SELECT ROW SHARE ыкмасы ар бир сапты өзүнчө бекитүү. Ошентип, биз көрүп турганда аларды эч ким жок кыла албайт же өзгөртө албайт.
Ошентип, SHARE LOCK эмне кылат? Биз транзакция ID SELECT үчүн 681 экенин көрөбүз. Жана бул кызыктуу. Бул жерде эмне болду? Биринчи жолу биз номерди "Кулпу" талаасында көрүп жатабыз. Биз транзакциянын идентификаторун алабыз жана ал эксклюзивдүү режимде аны бөгөттөп жатканын айтат. Мунун баары менде столдун бир жеринде техникалык жактан кулпуланган катар бар деп айтылат. Бирок ал так кайда экенин айткан жок. Бул тууралуу бир аздан кийин кененирээк карап чыгабыз.
Бул жерде кулпу бизде колдонулат деп айтабыз.
Ошентип, эксклюзивдүү кулпу анын эксклюзивдүү экенин ачык айтат. Ошондой эле, эгерде сиз бул таблицадагы сапты жок кылсаңыз, анда сиз көрүп тургандай, ушундай болот.
SHARE EXCLUSIVE – бул узунураак кулпу.
Бул колдонула турган (ANALYZE) анализатор буйругу.
SHARE LOCK – бөлүшүү режиминде ачык кулпулай аласыз.
Сиз ошондой эле уникалдуу индексти түзө аласыз. Жана ошол жерден алардын бир бөлүгү болгон SHARE LOCKту көрө аласыз. Ал эми үстөлдү бекитип, ага SHARE LOCK коет.
Демейки боюнча, үстөлдөгү SHARE LOCK башка адамдар таблицаны окуй алат, бирок аны эч ким өзгөртө албайт дегенди билдирет. Жана уникалдуу индексти түзгөндө дал ушундай болот.
Эгер мен бир убакта уникалдуу индекс түзсөм, анда менде кулпулоонун башка түрүнө ээ болом, анткени, эсиңизде болгондой, бир эле учурда индекстерди колдонуу кулпулоо талабын азайтат. Эгерде мен кадимки кулпуну, кадимки индексти колдонсом, анда мен таблицанын индекси түзүлүп жатканда жазууга жол бербейм. Эгерде мен бир эле учурда индексти колдонсом, анда мен кулпулоонун башка түрүн колдонушум керек.
SHARE ROW EXCLUSIVE – дагы аны ачык (ачык) коюуга болот.
Же биз эреже түзө алабыз, б.а., ал колдонула турган конкреттүү учурду алсак болот.
ЭКСКЛЮЗИВДУУ кулпу үстөлдү башка эч ким өзгөртө албайт дегенди билдирет.
Бул жерде биз кулпулардын ар кандай түрлөрүн көрөбүз.
ACCESS EXCLUSIVE, мисалы, бөгөттөө буйругу. Мисалы, эгер сиз CLUSTER table, анда бул эч ким ал жерге жаза албайт дегенди билдирет. Ал үстөлдүн өзүн гана эмес, индекстерди да бекитет.
Бул ACCESS EXCLUSIVE бөгөттөөнүн экинчи барагы, анда биз таблицада эмнени блоктоп жатканын так көрөбүз. Ал жеке үстөл катарларын бекитет, бул абдан кызыктуу.
Бул мен бергим келген негизги маалымат. Биз кулпулар жөнүндө, транзакция идентификаторлору жөнүндө, виртуалдык транзакция идентификаторлору жөнүндө, туруктуу транзакция идентификаторлору жөнүндө сүйлөштүк.
Эми биз кээ бир бөгөттөөчү мисалдарды карап чыгабыз. Бул эң кызыктуу бөлүгү. Биз абдан кызыктуу учурларды карап чыгабыз. Бул презентациядагы менин максатым Postgres кээ бир нерселерди блоктоого аракет кылганда эмне кылып жатканын жакшыраак түшүнүү. Менимче, ал бөлүктөрүн жабууда абдан жакшы.
Келгиле, кээ бир конкреттүү мисалдарды карап көрөлү.
Биз таблицалардан жана таблицадагы бир катардан баштайбыз. Мен бир нерсени киргизгенимде үстөлдө ExclusiveLock, Transaction ID жана ExclusiveLock көрсөтүлөт.
Дагы эки сап киргизсем эмне болот? Ал эми азыр биздин столдо үч катар бар. Мен бир катар киргизип, муну жыйынтык катары алдым. Анан дагы эки катар киргизсем, мунун эмнеси кызык? Бул жерде кызык нерсе бар, анткени мен бул таблицага үч катар коштум, бирок кулпу столунда дагы эки катар бар. Бул Постгрестин негизги жүрүм-туруму.
Көптөр маалымат базасында 100 сапты кулпулап койсоңуз, анда 100 кулпу жазуусун түзүшүңүз керек болот деп ойлошот. Эгерде мен бир эле учурда 1 сапты бөгөттөп койсом, анда мага 000 суроо керек болот. Ал эми бөгөт коюу үчүн миллион же миллиард керек болсо. Бирок муну кылсак, анда ал жакшы иштебейт. Эгер сиз ар бир жеке сап үчүн бөгөттөөчү жазууларды түзгөн системаны колдонгон болсоңуз, анда бул татаал экенин көрө аласыз. Анткени сиз дароо толуп кете турган кулпу таблицасын аныкташыңыз керек, бирок Postgres андай кылбайт.
Жана бул слайддын эң маанилүүсү, ал MVCC ичинде башка бир системанын бар экенин ачык көрсөтүп турат, ал жеке катарларды бекитет. Ошентип, сиз миллиарддаган саптарды бекиткенде, Postgres миллиарддаган өзүнчө кулпулоо буйруктарын түзбөйт. Ал эми бул өндүрүмдүүлүккө абдан жакшы таасирин тийгизет.
Жаңыртуу жөнүндө эмне айтууга болот? Мен азыр катарды жаңыртып жатам, ал бир эле учурда эки башка операцияны аткарганын көрө аласыз. Ал ошол эле учурда үстөлдү бекитти, бирок индексти да бекитти. Жана ал индексти бекитиши керек болчу, анткени бул таблицада уникалдуу чектөөлөр бар. А биз аны эч ким өзгөртпөшүнө ынангыбыз келет, ошондуктан ага бөгөт коёбуз.
Эки сапты жаңыртайын десем эмне болот? Ал эми өзүн ошондой алып жүргөнүн көрүп жатабыз. Биз эки эсе көп жаңыртууларды жасайбыз, бирок кулпу линияларынын саны так ошондой.
Эгер сиз Postgres муну кантип жасайт деп ойлонуп жатсаңыз, Postgres бул саптарды кантип өзгөртүп жатканын билүү үчүн MVCC боюнча менин сүйлөшүүлөрүмдү угушуңуз керек болот. Ал эми Postgres муну жасоо ыкмасына ээ, бирок ал муну столдун кулпу деңгээлинде эмес, аны төмөнкү жана натыйжалуураак деңгээлде жасайт.
Мен бир нерсени жок кылгым келсе эмне болот? Эгер мен, мисалы, бир катарды жок кылсам, менде дагы эле эки бөгөттөөчү киргизүүм бар жана алардын баарын жок кылгым келсе дагы, алар дагы эле бар.
Жана, мисалы, мен 1 сапты киргизгим келет, андан кийин 000 сапты өчүрүп же кошкум келет, андан кийин мен кошкон же өзгөрткөн жеке саптар бул жерде жазылган эмес. Алар сериянын ичинде төмөнкү деңгээлде жазылган. Ал эми MVCC сөзүндө мен бул тууралуу кеңири айттым. Бирок кулпуларды талдап жатканыңызда, үстөл деңгээлинде кулпулап жатканыңызды жана бул жерде жеке саптар кандайча жазылып жатканын көрбөй жатканыңызды текшерүү абдан маанилүү.
Ачык бөгөт коюу жөнүндө эмне айтууга болот?
Жаңылоону чыкылдатсам, менде эки катар кулпуланган. Эгер мен алардын баарын тандап, "бардык жерде жаңыртуу" дегенди чыкылдатсам, менде дагы эле эки блоктоочу жазуу бар.
Биз ар бир жеке сап үчүн өзүнчө жазууларды түзбөйбүз. Анткени анда өндүрүмдүүлүк төмөндөйт, ал өтө көп болушу мүмкүн. Жана биз жагымсыз жагдайга туш болушубуз мүмкүн.
Жана ошол эле нерсе, эгерде биз бөлүшкөн болсок, мунун бардыгын 30 жолу жасай алабыз.
Биз жадыбалыбызды калыбына келтиребиз, баарын жок кылабыз, анан кайра бир катар киргизебиз.
Postgresте сиз көргөн дагы бир жүрүм-турум, бул абдан белгилүү жана каалаган жүрүм-турум, сиз жаңыртуу же тандоо жасай аласыз. Жана сиз муну бир эле учурда кыла аласыз. Жана тандоо жаңыртууга бөгөт койбойт жана ошол эле нерсени карама-каршы багытта. Окурманга жазуучуну тоспогула дейбиз, жазуучу да окурманды тоскон эмес.
Мен мунун бир мисалын көрсөтөм. Мен азыр тандоо жасайм. Андан кийин INSERT жасайбыз. Ошондо сиз көрө аласыз - 694. Бул киргизүүнү аткарган транзакциянын идентификаторун көрө аласыз. Мына ушундай иштейт.
Эми мен өзүмдүн идентификаторумду карасам, ал азыр 695.
Менин үстөлүмдө 695 пайда болгонун көрө алам.
Эгерде мен бул жерде ушинтип жаңырсам, анда мен башка окуяны алам. Бул учурда, 695 эксклюзивдүү кулпу болуп саналат жана жаңыртуу бирдей жүрүм-турумга ээ, бирок алардын ортосунда эч кандай конфликт жок, бул адаттан тыш көрүнүш.
Ал эми жогору жагында ShareLock, ал эми ылдый жагында ExclusiveLock экенин көрө аласыз. Жана эки транзакция тең ишке ашты.
Бул кантип болуп жатканын түшүнүү үчүн MVCCдеги менин баяндамамды угушуңуз керек. Бирок бул сиз муну бир эле учурда жасай ала турган мисал, б.а. бир эле учурда ТАНДОО жана ЖАҢЫРТУУ.
Калыбына келтирип, дагы бир операция жасайлы.
Эгер сиз бир эле сапта эки жаңыртууну иштетүүгө аракет кылсаңыз, ал бөгөттөлөт. Эсиңде болсун, окурман жазуучуну, жазуучу окурманды тоспойт, бир жазуучу экинчи жазуучуну тосот деп айткам. Башкача айтканда, бир эле учурда эки адам бир катарды жаңырта албайт. Алардын бири бүткүчө күтүшүңүз керек.
Муну көрсөтүү үчүн мен Lockdemo таблицасын карайм. Жана биз бир катар карап чыгабыз. Бир транзакция үчүн 698.
Биз муну 2ге жаңырттык. 699 биринчи жаңыртуу. Жана ал ийгиликтүү болду же ал күтүлүп жаткан транзакцияда жана биздин ырастообузду же жокко чыгаруубузду күтүп жатат.
Бирок, дагы бир нерсени карагыла - 2/51 биздин биринчи транзакциябыз, биздин биринчи сессиябыз. 3/112 бул жогору жактан келген экинчи өтүнүч, бул маанини 3кө өзгөрттү. Эгер байкасаңыз, үстүнкүсү өзү кулпулап калды, ал 699. Бирок 3/112 кулпуну берген жок. Lock_mode тилкеси эмнени күтүп жатканын айтат. Ал 699 күтөт. Ал эми 699 кайда экенин карасаңыз, ал жогору. Анан биринчи сессия эмне кылды? Ал өзүнүн транзакция идентификаторунда эксклюзивдүү кулпу жараткан. Postgres муну ушундай кылат. Ал өзүнүн транзакция идентификаторун бөгөттөйт. Ал эми кимдир бирөөнүн ырастоосун же жокко чыгаруусун күткүңүз келсе, анда күтүлүп жаткан транзакция болгондо күтүшүңүз керек. Мына ошондуктан биз кызыктай сызыкты көрө алабыз.
Келгиле, кайра карап көрөлү. Сол жакта биз иштетүү идентификаторубузду көрөбүз. Экинчи тилкеде биз виртуалдык транзакция идентификаторубузду, үчүнчүдө биз lock_type көрөбүз. Бул эмнени билдирет? Негизинен ал транзакциянын идентификаторун бөгөттөп жатат деп айтылат. Бирок ылдыйдагы бардык саптар байланышты айтып жатканын байкаңыз. Ошентип, үстөлдө кулпулардын эки түрү бар. байланыш кулпусу бар. Андан кийин транзакциянын бөгөттөөсү бар, бул жерде сиз өзүңүз блоктоп коёсуз, дал ушул нерсе биринчи катарда же эң ылдыйда болот, транзакцияиди кайда, биз 699 анын ишин бүтүргөнчө күтөбүз.
Мен бул жерде эмне болорун көрөм. Ал эми бул жерде эки нерсе бир убакта болот. Сиз биринчи сапта транзакциянын ID кулпусун карап жатасыз, ал өзүн бекитет. Жана ал адамдарды күтүүгө мажбурлоо үчүн өзүн блокадага салат.
Эгерде сиз 6-сапты карасаңыз, бул биринчиси менен бирдей. Ошентип, транзакция 699 бөгөттөлгөн. 700 да өзүн-өзү кулпулоо болуп саналат. Анан ылдыйкы сапта биз 699 анын ишин бүтүрүшүн күтүп жатканыбызды көрөсүз.
Ал эми lock_type, кортежде сиз сандарды көрөсүз.
Сиз 0/10 экенин көрө аласыз. Жана бул барактын номери, ошондой эле бул өзгөчө катардын жылышуусу.
Жана биз жаңыртканыбызда 0/11 болуп калганын көрөсүз.
Бирок чындыгында бул 0/10, анткени бул операцияны күтүү бар. Бул мен ырастоону күтүп жаткан серия экенин көрүү мүмкүнчүлүгүбүз бар.
Биз аны ырастап, милдеттенмени басканда, жаңыртуу аяктагандан кийин, биз дагы бир жолу алабыз. Транзакция 700 - бул жалгыз кулпу, ал башка эч кимди күтпөйт, анткени ал жасалган. Ал жөн гана транзакциянын аягына чыгышын күтөт. 699 түгөнгөндө, биз эч нерсе күтпөйбүз. Ал эми азыр транзакция 700 баары жакшы экенин, бардык уруксат берилген столдордо керектүү кулпулары бар экенин айтат.
Жана мунун баарын ого бетер татаалдаштыруу үчүн, биз бул жолу бизге иерархияны камсыз кылган дагы бир көз карашты түзөбүз. Мен сизден бул өтүнүчтү түшүнөт деп күтпөйм. Бирок бул бизге эмне болуп жатканы тууралуу так көз карашты берет.
Бул дагы бир бөлүмү бар рекурсивдүү көрүнүш. Анан баарын кайра бириктирет. Муну колдонолу.
Бир эле учурда үч жаңыртуу жасап, катар азыр үчөө деп айтсак кандай болот. Ал эми биз 3төн 4кө алмаштырабыз.
Ал эми бул жерде биз көрүп 4. Жана транзакция ID 702.
Анан мен 4төн 5ке өзгөрөм. Жана 5тен 6га, 6дан 7ге. Жана ушул бир транзакциянын бүтүшүн күтүп жаткан бир нече адамдарды тизем.
Ошондо баары айкын болуп калат. Биринчи катар кандай? Бул 702. Бул транзакциянын идентификатору, башында бул маанини койгон. Менин берилген тилкеме эмне жазылган? Менде белгилер бар f. Бул менин жаңыртууларым (5, 6, 7) бекитилбейт, анткени биз ID 702 транзакциясынын бүтүшүн күтүп жатабыз. Ал жерде биз транзакция ID бөгөттөө бар. Бул 5 транзакциялык ID кулпусун алып келет.
Ал эми 704, 705ти карасаңыз, ал жерде эч нерсе жазыла элек, анткени алар азырынча эмне болуп жатканын билишпейт. Алар жөн гана эмне болуп жатканын билишпейт деп жазышат. Жана алар жөн эле уктап калышат, анткени алар кимдир-бирөөнүн бүтүшүн жана катарларды алмаштырууга мүмкүнчүлүк болгондо ойгонушун күтүп жатышат.
Бул көрүнүш мына мындай. Алардын баары 12-линияны күтүп жатканы көрүнүп турат.
Бул жерде биз көргөн нерсебиз. Бул жерде 0/12.
Ошентип, биринчи транзакция бекитилгенден кийин, иерархия кантип иштээрин бул жерден көрө аласыз. Эми баары ачыкка чыгат. Алардын баары таза болуп калат. Жана алар чындыгында дагы эле күтүп жатышат.
Бул жерде эмне болуп жатат. 702 милдеттендирет. Ал эми азыр 703 бул катар кулпусун алат, андан кийин 704 703 жасоону күтүп баштайт. 705 да муну күтүп жатат. Мунун баары бүткөндөн кийин өздөрүн тазалашат. Ал эми бардыгы катар тизилип жатканын белгилегим келет. Ал эми бул баары биринчи машинаны күтүп турган тыгындагы кырдаалга абдан окшош. Биринчи машина токтоп, баары узун кезекке турушат. Андан кийин ал жылат, андан кийин кийинки машина алдыга айдап, анын блогун алат ж.б.
Эгер бул сизге анча татаал көрүнбөсө, анда биз сиз менен туюктар жөнүндө сүйлөшөбүз. Силердин кимиңер аларга жолукканын билбейм. Бул маалымат базасы системаларында бир кыйла таралган көйгөй болуп саналат. Бирок туюктуктар бир сессия башка сессияны бир нерсе кылууну күтүп жатканда. Ал эми ушул учурда дагы бир сессия биринчи сессияны бир нерсе кылууну күтүп жатат.
Ал эми, мисалы, Иван: «Мага бир нерсе бер» десе, мен: «Жок, башка нерсе берсең гана берем» деп айтам. Ал: «Жок, сен бербесең, мен сага бербейм» дейт. Анан туңгуюк абалга келип калдык. Иван мындай кылбайт деп ишенем, бирок бизде бир нерсе алгысы келген эки адам бар, экинчиси каалаганын бергиче, аны берүүгө даяр эмес дегенди түшүнөсүң. Анан эч кандай чечим жок.
Жана негизинен, сиздин маалымат базаңыз муну аныкташы керек. Анан сеанстардын бирин жок кылуу же жабуу керек, анткени антпесе алар ошол жерде түбөлүккө кала беришет. Ал эми биз аны маалымат базаларынан көрөбүз, операциялык системалардан көрөбүз. Ал эми бизде параллелдүү процесстер болгон бардык жерлерде мындай болушу мүмкүн.
Эми эки туюк орнотобуз. Биз 50 жана 80 коебуз. Биринчи катарда мен 50дөн 50гө чейин жаңыртам. Мен 710 транзакция номерин алам.
Анан 80ди 81ге, 50ну 51ге алмаштырам.
Мына ушундай болот. Ошентип, 710 бир катар бөгөттөлгөн жана 711 ырастоону күтүп жатат. Биз муну жаңыртканда көрдүк. 710 биздин сериянын ээси. Ал эми 711 бүтүмдү аяктоо үчүн 710 күтөт.
Ал тургай туюктар кайсы катарда болуп жатканы да айтылат. Жана бул жерде кызыктай баштайт.
Азыр 80ден 80ге чейин жаңылап жатабыз.
Мына ушул жерден туюктар башталат. 710 711ден жооп күтүүдө, ал эми 711 710дон. Мунун аягы жакшылык менен бүтпөйт. Жана мындан чыгуунун жолу жок. Жана алар бири-биринен жооп күтүшөт.
Жана жөн гана баарын кечеңдете баштайт. А биз муну каалабайбыз.
Ал эми Postgres бул качан байкай турган жолдору бар. Жана бул болгондо, сиз бул катаны аласыз. Мына ушундан көрүнүп тургандай, баланча процесс башка процесстен, б.а. 711 процесси тарабынан бөгөттөлгөн PHARE LOCKду күтүп жатат. Жана бул процесс баланча транзакция идентификаторунда SHARE LOCK берилишин күтүп жаткан жана тигил же бул процесс тарабынан бөгөттөлгөн. Демек, бул жерде туюк абал бар.
Үч тараптуу туюктар барбы? Бул мүмкүнбү? Ооба.
Бул сандарды таблицага киргизебиз. 40тан 40ка алмаштырабыз, блокировка кылабыз.
60ты 61ге, 80ди 81ге алмаштырабыз.
Анан биз 80ди өзгөртөбүз, анан бум!
Ал эми 714 азыр 715ти күтүп жатат. 716-715-ти күтүп жатат. Жана эч нерсе кыла албайт.
Бул жерде эки киши жок, үч киши бар. Мен сенден бир нерсе каалайм, бул үчүнчү адамдан, үчүнчү адам менден бир нерсе каалайт. Жана биз үч тараптуу күтүүгө дуушар болобуз, анткени баарыбыз башка адам эмне кылышы керек экенин күтүп жатабыз.
Ал эми Postgres бул кайсы катарда болгонун билет. Ошентип, ал сизге төмөнкү билдирүүнү берет, бул сизде үч киргизүү бири-бирине бөгөт коюп жаткан көйгөй бар экенин көрсөтөт. Жана бул жерде эч кандай чектөөлөр жок. Бул 20 жазуу бири-бирине бөгөт коюшу мүмкүн.
Кийинки көйгөй сериялаштыруу болуп саналат.
Эгерде атайын сериялык кулпу.
Ал эми биз кайра 719. Анын чыгышы нормалдуу.
Жана сиз транзакцияны сериялаштыруу үчүн чыкылдатсаңыз болот.
Эми сизде SA кулпусунун башка түрү бар экенин түшүндүңүз - бул сериялаштырууну билдирет.
Ошентип, бизде SARieadLock деп аталган кулпунун жаңы түрү бар, ал сериялык кулпу болуп саналат жана сериалдарды киргизүүгө мүмкүндүк берет.
Ошондой эле сиз уникалдуу индекстерди киргизе аласыз.
Бул таблицада уникалдуу индекстер бар.
Демек, мен бул жерге 2 санын койсом, анда менде 2 бар. Бирок эң жогору жагында мен дагы 2 койдум. Ал эми 721дин өзгөчө кулпу бар экенин көрө аласыз. Бирок азыр 722 721дин ишин аякташын күтүп жатат, анткени ал 2ге эмне болорун билмейинче 721ди киргизе албайт.
Ал эми субтранзакция жасасак.
Бул жерде бизде 723 бар.
Ал эми биз чекитти сактап, анан аны жаңыртсак, анда жаңы транзакция идентификаторун алабыз. Бул сиз билишиңиз керек болгон дагы бир жүрүм-турум үлгүсү. Эгер биз муну кайтарсак, транзакция идентификатору жок болот. 724 кетип жатат. Бирок азыр бизде 725.
Анда мен бул жерде эмне кылууга аракет кылып жатам? Мен сизге адаттан тыш кулпулардын мисалдарын көрсөтүүгө аракет кылып жатам, сиз таба аласыз: бул сериялаштырыла турган кулпуларбы же SAVEPOINTбы, бул кулпу таблицасында пайда боло турган кулпулардын ар кандай түрлөрү.
Бул pg_advisory_lock бар ачык (ачык) кулпуларды түзүү.
Жана сиз бөгөттөө түрү кеңеш берүүчү катары саналганын көрөсүз. Ал эми бул жерде кызыл менен "кеңеш берүү" деп жазылган. Жана сиз бир эле учурда pg_advisory_unlock менен ушундай бөгөттөй аласыз.
Жыйынтыктап айтканда, мен сизге дагы бир акылга сыйбаган нерсени көрсөткүм келет. Мен башка көрүнүштү түзөм. Бирок мен pg_locks таблицасына pg_stat_activity таблицасы менен кошулам. Анан эмне үчүн мен муну жасагым келет? Анткени бул мага бардык учурдагы сессияларды карап, көрүүгө жана алар кандай кулпуларды күтүп жатканын так көрүүгө мүмкүндүк берет. Бул кулпу үстөлүн жана суроо таблицасын чогуу койгондо абдан кызыктуу.
Жана бул жерде биз pg_stat_view түзөбүз.
Жана биз катарды бирден жаңыртабыз. Жана бул жерде биз 724 көрөбүз. Анан биз катарыбызды үчкө жаңыртабыз. Эми бул жерден эмнени көрүп жатасың? Бул суроо-талаптар, б.а. сиз сол тилкеде тизмеленген суроо-талаптардын толук тизмесин көрөсүз. Анан оң жагында бөгөттөрдү жана алар жараткан нерселерди көрө аласыз. Жана ар бир сессияга кайра барып, ага кошулушуңуз керекпи же жокпу, көрүүнүн кереги жок болушу үчүн, бул сиз үчүн түшүнүктүү болушу мүмкүн. Алар муну биз үчүн жасашат.
абдан пайдалуу дагы бир өзгөчөлүгү болуп саналат pg_blocking_pids. Сиз ал жөнүндө эч качан укпагандырсыз. Ал эмне кылып жатат? Бул 11740 бул сессия үчүн кандай конкреттүү процесс идентификаторлорун күтүп жатканын айтууга мүмкүндүк берет. Ал эми 11740 724тү күтүп жатканын көрө аласыз. Ал эми 724 эң башында турат. Ал эми 11306 сиздин процесс ID болуп саналат. Негизинен, бул функция кулпу үстөлүңүз аркылуу өтөт. Мен билем, бул бир аз татаал, бирок сиз аны түшүнүүгө жетишесиз. Негизинен бул функция бул кулпу таблицасы аркылуу өтөт жана бул процесстин идентификаторуна ал күтүп жаткан кулпулар кайда берилгенин табууга аракет кылат. Ошондой эле, ал кулпусун күтүп жаткан процесстин идентификаторун аныктоого аракет кылат. Ошентип, сиз бул функцияны иштете аласыз pg_blocking_pids.
Жана бул абдан пайдалуу болушу мүмкүн. Биз муну 9.6 версиясында гана кошконбуз, андыктан бул функция болгону 5 жашта, бирок ал абдан, абдан пайдалуу. Ошол эле экинчи өтүнүчкө да тиешелүү. Бул так биз көрүшүбүз керек экенин көрсөтүп турат.
Мен сиз менен ушул жөнүндө сүйлөшкүм келди. Жана мен күткөндөй, слайддар көп болгондуктан, биз бардык убактыбызды короттук. Жана слайддарды жүктөп алуу үчүн жеткиликтүү. Бул жерде болгонуңуз үчүн рахмат айткым келет. Конференциянын калган бөлүгү сиздерге жагымдуу болот деп ишенем, чоң рахмат!
суроолор:
Мисалы, мен саптарды жаңыртууга аракет кылып жатсам, ал эми экинчи сессия бүт таблицаны жок кылууга аракет кылып жатса. Мен түшүнгөндөй, ниет кулпу сыяктуу бир нерсе болушу керек. Постгресте ушундай нерсе барбы?
Келгиле, эң башталышына кайрылалы. Сиз кандайдыр бир нерсени жасаганыңызда, мисалы, SELECT жасаганыңызда, биз AccessShareLock чыгараарыбызды эсиңизде чыгарсаңыз болот. Жана бул үстөлдүн түшүп калышына жол бербейт. Демек, сиз, мисалы, таблицадагы сапты жаңырткыңыз келсе же сапты жок кылгыңыз келсе, анда кимдир бирөө бир эле учурда бүт таблицаны жок кыла албайт, анткени сиз бул AccessShareLockту бүт таблицада жана сапта кармап турасыз. Жана сиз бүтүргөндөн кийин, алар аны жок кыла алышат. Бирок сиз ошол жерде бир нерсени түздөн-түз өзгөртүп жатканыңызда, алар муну кыла алышпайт.
Келгиле, кайра жасайлы. Келгиле, жок кылуу мисалына өтөбүз. Жана сиз бүт үстөлдүн үстүндөгү катарда эксклюзивдүү кулпу бар экенин көрүп турасыз.
Бул кулпу эксклюзивдүү окшойт, туурабы?
Ооба, ошондой окшойт. Эмне жөнүндө айтып жатканыңызды түшүнөм. Сиз айтып жатасызбы, эгерде мен ТАНДОО жасасам, анда менде ShareExclusive бар, анан аны Row Exclusive кылам, бул көйгөй болуп калабы? Бирок таң калыштуусу, бул көйгөй жаратпайт. Бул кулпу даражасын жогорулатуу сыяктуу көрүнөт, бирок менде жок кылууну болтурбай турган кулпу бар. Эми мен бул кулпуну күчтүүрөөк кылганда, ал дагы эле жок кылынбайт. Ошентип, мен көтөрүлүп жаткан жокмун. Башкача айтканда, ал төмөнкү деңгээлде болгондо да алдын алган, ошондуктан мен анын деңгээлин көтөргөндө ал дагы эле таблицанын жок кылынышына жол бербейт.
Эмне жөнүндө айтып жатканыңызды түшүнөм. Бул жерде эч кандай кулпуну эскалациялоо иши жок, мында сиз күчтүүрөөк кулпуну киргизүү үчүн бир кулпудан баш тартууга аракет кылып жатасыз. Бул жерде бул жөн гана бул алдын алууну күчөтөт, ошондуктан эч кандай чыр-чатакка алып келбейт. Бирок бул жакшы суроо. Муну сураганыңыз үчүн чоң рахмат!
Сеанстар көп, колдонуучулардын саны көп болгондо туюк кырдаалга туш болбоо үчүн эмне кылышыбыз керек?
Postgres туюк кырдаалды автоматтык түрдө байкайт. Жана ал автоматтык түрдө сессиялардын бирин жок кылат. Өлгөн бөгөттөөдөн сактануунун бирден бир жолу - адамдарды бирдей тартипте бөгөттөө. Ошентип, сиз арызыңызды караганыңызда, көбүнчө туюктардын себеби... Келгиле, мен эки башка нерсени блоктогум келет деп элестетип көрөлү. Бир тиркеме 1-таблицаны, ал эми башка тиркеме 2-таблицаны, анан 1-таблицаны кулпулайт. Ал эми туюктан сактануунун эң оңой жолу - колдонмоңузду карап чыгып, кулпу бардык тиркемелерде бирдей тартипте ишке ашканына ынанууга аракет кылуу. Жана бул, адатта, көйгөйлөрдүн 80% жок кылат, анткени бул тиркемелерди ар кандай адамдар жазат. Эгер сиз аларды бирдей тартипте бөгөттөсөңүз, анда туюк кырдаалга туш болбойсуз.
Сиздин аткарууңуз үчүн чоң рахмат! Сиз вакуум толгон жөнүндө айттыңыз, эгер мен туура түшүнсөм, вакуум толук өзүнчө сактагычтагы жазуулардын тартибин бурмалайт, ошондуктан алар учурдагы жазууларды өзгөрүүсүз сактап турушат. Эмне үчүн вакуум толук эксклюзивдүү кулпу мүмкүнчүлүгүн алат жана эмне үчүн ал жазуу операцияларына карама-каршы келет?
Бул жакшы суроо. Себеби, вакуум толгон үстөлдү алат. Жана биз таблицанын жаңы версиясын түзүп жатабыз. Жана үстөл жаңы болот. Көрсө, бул таблицанын таптакыр жаңы версиясы болот. Ал эми маселе, биз муну жасаганда, биз адамдардын аны окушун каалабайбыз, анткени бизге жаңы таблицаны көрүшү керек. Ошентип, бул мурунку суроо менен байланыштырат. Эгерде биз бир убакта окуй алсак, анда аны жылдырып, адамдарды жаңы үстөлгө багыттай алмак эмеспиз. Биз ар бир адам бул таблицаны окуп бүткүчө күтүшүбүз керек, ошондуктан бул кулпуланган өзгөчө кырдаал.
Биз башынан эле кулпулап жатабыз деп айтабыз, анткени бардыгын жаңы көчүрмөгө жылдыруу үчүн эң аягында бизге эксклюзивдүү кулпу керек болорун билебиз. Ошентип, биз муну чече алабыз. Жана биз муну бир эле убакта индекстөө менен жасайбыз. Бирок муну жасоо алда канча кыйын. Жана бул сиздин мурунку сурооңузга байланыштуу, эксклюзивдүү кулпу.
Postgresке кулпу тайм-аутун кошууга болобу? Oracle'да мен, мисалы, "жаңыртуу үчүн тандоо" деп жазып, жаңыртуудан мурун 50 секунд күтө алам. Бул колдонмо үчүн жакшы болду. Бирок Postgresте мен муну дароо жасашым керек жана такыр күтпөйм, же бир аз убакытка чейин күтүшүм керек.
Ооба, кулпуларыңызда, кулпуларыңызда тайм-аутту тандай аласыз. Сиз ошондой эле эч кандай жол бербөө буйругун чыгара аласыз, эгерде сиз дароо кулпуну ала албасаңыз. Ошондуктан, же кулпу тайм-ауту же муну жасоого мүмкүндүк берүүчү башка нерсе. Бул синтаксистик деңгээлде жасалбайт. Бул серверде өзгөрмө катары жасалат. Кээде бул колдонуу мүмкүн эмес.
75-слайдты ача аласызбы?
Ооба.
Ал эми менин суроом төмөнкүдөй. Эмне үчүн экөө тең жаңыртуу процесстери 703 күтүүдө?
Жана бул чоң суроо. Баса, Postgres эмне үчүн мындай кылганын түшүнбөйм. Бирок 703 түзүлгөндө, ал 702ни күткөн. Ал эми 704 жана 705 пайда болгондо, алар эмнени күтүп жатышканын билишпейт окшойт, анткени ал жерде азырынча эч нерсе жок. Ал эми Postgres муну мындай кылат: кулпу ала албай калганда, ал "Сизди иштетүүнүн эмне кереги бар?" деп жазат, анткени сиз кимдир бирөөнү күтүп жатасыз. Андыктан биз аны абада илип коёбуз, ал такыр жаңыртпайт. Бирок бул жерде эмне болду? 702 процессти аяктап, 703 кулпусун алгандан кийин, система кайра кайтып келди. Ал эми азыр эки киши күтүп турганын айтты. Анан аларды чогуу жаңырталы. Жана экөө тең күтүп жатканын белгилейли.
Мен Postgres эмне үчүн мындай кылганын билбейм. Бирок f... деген маселе бар. Мага бул орусча термин эмес окшойт. Бул сепилди күтүп жаткан 20 бийлик болсо да, баары бир сепилди күтүп жаткан учур. Анан күтүлбөгөн жерден баары бир убакта ойгонот. Ошондо баары жооп берүүгө аракет кыла баштайт. Бирок система 703тү баары күтүп тургандай кылып койду. Анткени алардын баары күтүп жатышат, биз дароо алардын баарын тизебиз. Жана андан кийин пайда болгон башка жаңы суроо пайда болсо, мисалы, 707, анда кайрадан боштук пайда болот.
Бул менин оюмча, бул этапта 702 703тү күтүп жатат, андан кийин келгендердин баары бул тармакка эч кандай киришпейт деп айтуу үчүн жасалгандай сезилет. Бирок биринчи официант кетээри менен, жаңылануу алдында ошол учурда күтүп жаткандардын бардыгы бирдей белгини алышат. Ошентип, мен ойлойм, бул биз аларды туура иретке келтирип, иретке келтиришибиз үчүн жасалды.
Мен муну дайыма кызыктай көрүнүш катары карачумун. Анткени бул жерде, мисалы, биз аларды такыр санабайбыз. Бирок мага жаңы кулпуну берген сайын күтүү процессинде жүргөндөрдүн баарын карап тургандай сезилет. Анан алардын баарын тизебиз. Андан кийин келген жаңысы кийинки адам иштетилип бүткөндөн кийин гана кезекке кирет. Абдан жакшы суроо. Сурооңуз үчүн чоң рахмат!
Менимче, 705 704 күткөндө алда канча логикалуураак окшойт.
Бирок бул жерде маселе төмөнкүдөй. Техникалык жактан, сиз тигил же бул ойгото аласыз. Ошентип, биз тигил же бул ойгонот. Бирок системада эмне болот? Сиз эң жогору жактагы 703 өзүнүн транзакция идентификаторун кантип бөгөттөп койгонун көрө аласыз. Postgres ушундай иштейт. Ал эми 703 өзүнүн транзакция идентификатору менен бөгөттөлгөн, ошондуктан кимдир бирөө күтүүнү кааласа, анда алар 703тү күтүшөт. Ал эми 703 бүтөт. Жана ал аяктагандан кийин гана процесстердин бири ойгонот. Ал эми бул процесс так кандай болорун билбейбиз. Анан баарын акырындык менен иштетебиз. Бирок кайсы процесс алгач ойгону белгисиз, анткени бул процесстердин кайсынысы болушу мүмкүн. Негизи, бизде азыр бул процесстердин каалаганын ойгото ала турган пландоочу бар болчу. Биз жөн гана кокусунан бирин тандайбыз. Демек, экөөнү тең белгилеш керек, анткени экөөнү тең ойгото алабыз.
Ал эми маселе бизде CP-чексиздикте. Демек, биз кийинкисин ойгото алабыз. Ал эми, мисалы, кийинкисин ойготсок, блокту жаңы эле алганды күтөбүз, андыктан ким биринчи ойготорун так аныктай албайбыз. Биз жөн гана ушундай кырдаалды түзөбүз, система аларды туш келди иретте ойготот.
бар . Карачы, алар да кызыктуу жана пайдалуу. Тема, албетте, абдан татаал. Чоң рахмат, Брюс!
Source: www.habr.com