Брюс Момжианның 2020 жылғы "Postgres Lock Manager құлпын ашу" баяндамасының транскрипциясы.
(Ескерту: слайдтардағы барлық SQL сұрауларын мына сілтемеден алуға болады: )
Сәлеметсіз бе! Ресейде тағы болғаным өте жақсы. Өткен жылы келе алмағаныма өкінемін, бірақ биыл Иван екеуміздің жоспарларымыз үлкен. Мен мұнда жиі боламын деп үміттенемін. Мен Ресейге келгенді жақсы көремін. Мен Тюмень, Тверь қалаларына барамын. Мен бұл қалаларды аралай алатыныма өте қуаныштымын.
Менің атым Брюс Момжиан. Мен EnterpriseDB-де жұмыс істеймін және Postgres-пен 23 жылдан астам жұмыс істеймін. Мен Филадельфияда, АҚШ-та тұрамын. Мен жылына 90 күн саяхаттаймын. Ал мен 40-қа жуық конференцияға қатысамын. менің , онда мен қазір көрсететін слайдтар бар. Сондықтан конференциядан кейін оларды менің жеке сайтымнан жүктеп алуға болады. Онда 30-ға жуық презентация бар. Сондай-ақ бейнелер мен көптеген блог жазбалары бар, 500-ден астам. Бұл жеткілікті ақпараттық ресурс. Ал егер сізді осы материал қызықтырса, мен сізді оны пайдалануға шақырамын.
Мен Postgres-пен жұмыс істегенге дейін мұғалім, профессор болдым. Енді мен сізге айтайын дегенімді айта алатыныма өте қуаныштымын. Бұл менің ең қызықты презентацияларымның бірі. Ал бұл презентацияда 110 слайд бар. Біз қарапайым нәрселермен сөйлесуді бастаймыз, ал соңында есеп барған сайын күрделене түседі және айтарлықтай күрделі болады.
Бұл өте жағымсыз әңгіме. Блоктау ең танымал тақырып емес. Біз мұның бір жерде жоғалғанын қалаймыз. Бұл тіс дәрігеріне барған сияқты.
- Құлыптау дерекқорларда жұмыс істейтін және бір уақытта бірнеше процестерді орындайтын көптеген адамдар үшін мәселе. Оларға блоктау керек. Яғни, бүгін мен сізге блоктау туралы негізгі білім беремін.
- Транзакция идентификаторлары. Бұл презентацияның өте қызық бөлігі, бірақ оларды түсіну керек.
- Әрі қарай блоктау түрлері туралы айтатын боламыз. Бұл өте механикалық бөлік.
- Ал төменде біз блоктаудың бірнеше мысалдарын береміз. Және оны түсіну өте қиын болады.
Блоктау туралы сөйлесейік.
Біздің терминологиямыз өте күрделі. Бұл үзіндінің қайдан шыққанын қанша адам біледі? Екі адам. Бұл Colossal Cave Adventure деп аталатын ойыннан. Бұл 80-жылдары мәтінге негізделген компьютерлік ойын болды, менің ойымша. Ол жерде үңгірге, лабиринтке кіруге тура келді, мәтін өзгерді, бірақ мазмұны әр жолы шамамен бірдей болды. Бұл ойын осылай есімде.
Міне, біз Oracle-дан бізге келген құлыптардың атын көреміз. Біз оларды пайдаланамыз.
Мұнда мені шатастыратын терминдерді көреміз. Мысалы, SHARE UPDATE ECXLUSIVE. Келесі SHARE RAW ECXLUSIVE. Шынымды айтсам, бұл атаулар онша түсінікті емес. Біз оларды толығырақ қарастыруға тырысамыз. Кейбіреулерінде бөлу дегенді білдіретін «бөліс» сөзі бар. Кейбіреулерінде «ерекше» деген сөз бар. Кейбіреулерде осы екі сөз де бар. Мен бұл құлыптардың қалай жұмыс істейтінінен бастағым келеді.
Және «қолжетімділік» сөзі де өте маңызды. Ал «қатар» сөздері жол болып табылады. Яғни қол жеткізуді тарату, жолды тарату.
Postgres-те түсінуді қажет ететін тағы бір мәселе, өкінішке орай, мен өз баяндамамда айта алмаймын - MVCC. Менің веб-сайтымда осы тақырып бойынша жеке презентациям бар. Егер сіз бұл презентацияны қиын деп ойласаңыз, MVCC менің ең қиыны шығар. Ал егер сізді қызықтырса, сайттан көре аласыз. Бейнені көре аласыз.
Біз түсінуіміз керек тағы бір нәрсе - транзакция идентификаторлары. Көптеген транзакциялар бірегей идентификаторларсыз жұмыс істей алмайды. Мұнда біз транзакцияның не екенін түсіндірдік. Postgres-те екі транзакцияны нөмірлеу жүйесі бар. Мен бұл өте жақсы шешім емес екенін білемін.
Сондай-ақ, слайдтарды түсіну өте қиын болатынын есте сақтаңыз, сондықтан қызыл түспен белгіленген нәрсеге назар аудару керек.
Қарайық. Транзакция нөмірі қызыл түспен белгіленген. SELECT pg_back функциясы осы жерде көрсетілген. Ол менің транзакциямды және транзакция идентификаторын қайтарады.
Тағы бір нәрсе, егер сізге бұл презентация ұнаса және оны дерекқорда іске қосқыңыз келсе, онда сіз қызғылт түспен осы сілтемеге өтіп, осы презентацияның SQL нұсқасын жүктей аласыз. Сіз оны жай ғана PSQL-де іске қоса аласыз және бүкіл презентация дереу экранда болады. Онда гүлдер болмайды, бірақ біз оны көре аламыз.
Бұл жағдайда біз транзакция идентификаторын көреміз. Бұл біз оған берген нөмір. Postgres-те транзакция идентификаторының басқа түрі бар, ол виртуалды транзакция идентификаторы деп аталады
Және біз мұны түсінуіміз керек. Бұл өте маңызды, әйтпесе Postgres-те құлыптауды түсіне алмаймыз.
Виртуалды транзакция идентификаторы тұрақты мәндерді қамтымайтын транзакция идентификаторы болып табылады. Мысалы, мен ТАҢДАУ пәрменін орындасам, дерекқорды өзгертпеймін, ештеңені құлыптамаймын. Сондықтан біз қарапайым ТАҢДАУды іске қосқанда, біз бұл транзакцияға тұрақты идентификатор бермейміз. Біз оған тек виртуалды ID береміз.
Және бұл Postgres өнімділігін жақсартады, тазалау мүмкіндіктерін жақсартады, сондықтан виртуалды транзакция идентификаторы екі саннан тұрады. Қиғаш сызық алдындағы бірінші сан сервер идентификаторы болып табылады. Ал оң жақта біз тек есептегішті көреміз.
Сондықтан, егер сұрауды орындасам, ол сервер идентификаторы 2 екенін айтады.
Ал егер мен осындай транзакциялар сериясын орындасам, онда мен сұрауды орындаған сайын есептегіш көбейетінін көреміз. Мысалы, сұрауды іске қосқан кезде 2/10, 2/11, 2/12, т.б.
Мұнда екі баған бар екенін есте сақтаңыз. Сол жақта виртуалды транзакция идентификаторын көреміз – 2/12. Ал оң жақта бізде тұрақты транзакция идентификаторы бар. Ал бұл өріс бос. Және бұл транзакция дерекқорды өзгертпейді. Сондықтан мен оған тұрақты транзакция идентификаторын бермеймін.
Талдау пәрменін ((ТАЛДАУ)) іске қосқаннан кейін сол сұрау маған тұрақты транзакция идентификаторын береді. Бұл біз үшін қалай өзгергенін қараңыз. Бұрын менде бұл идентификатор болмаған, бірақ қазір бар.
Міне, тағы бір сұрау, тағы бір транзакция. Виртуалды транзакция нөмірі 2/13. Егер мен тұрақты транзакция идентификаторын сұрасам, сұрауды іске қосқан кезде мен оны аламын.
Сонымен, тағы бір рет. Бізде виртуалды транзакция идентификаторы және тұрақты транзакция идентификаторы бар. 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 не істейді? Транзакция идентификаторы SELECT үшін 681 екенін көреміз. Және бұл қызықты. Мұнда не болды? Нөмірді бірінші рет «Құлыптау» өрісінде көреміз. Біз транзакция идентификаторын аламыз және ол оны эксклюзивті режимде бұғаттап жатқанын айтады. Мұның бәрі менде кестенің бір жерінде техникалық құлыптаулы жол бар екенін айтады. Бірақ ол нақты қай жерде екенін айтпайды. Мұны сәл кейінірек толығырақ қарастырамыз.
Бұл жерде құлыпты өзіміз пайдаланады дейміз.
Сонымен, эксклюзивті құлып оның эксклюзивті екенін анық айтады. Сондай-ақ, егер сіз осы кестедегі жолды жойсаңыз, көріп тұрғаныңыздай, осылай болады.
SHARE EXCLUSIVE — ұзағырақ құлып.
Бұл қолданылатын (АНАЛИЗ) анализатор командасы.
SHARE LOCK – бөлісу режимінде анық құлыптауға болады.
Сіз сондай-ақ бірегей индекс жасай аласыз. Және сол жерде сіз олардың бөлігі болып табылатын SHARE LOCK-ті көре аласыз. Және ол үстелді құлыптап, оған SHARE LOCK қояды.
Әдепкі бойынша, кестедегі SHARE LOCK басқа адамдар кестені оқи алатынын, бірақ оны ешкім өзгерте алмайтынын білдіреді. Бұл бірегей индексті жасағанда дәл солай болады.
Егер мен бір мезгілде бірегей индекс жасасам, онда менде құлыптаудың басқа түрі болады, өйткені, есіңізде болса, бір мезгілде индекстерді пайдалану құлыптау талаптарын азайтады. Егер мен қалыпты құлыпты, қалыпты индексті пайдалансам, мен кесте индексін құру кезінде оған жазуды болдырмаймын. Егер мен бір мезгілде индексті қолданатын болсам, басқа түрдегі құлыптауды пайдалануым керек.
SHARE ROW EXCLUSIVE – қайтадан оны анық (анық) орнатуға болады.
Немесе біз ереже жасай аламыз, яғни ол қолданылатын нақты жағдайды аламыз.
ЭКСКЛЮЗИВТІ құлыптау кестені басқа ешкім өзгерте алмайтындығын білдіреді.
Мұнда біз құлыптардың әртүрлі түрлерін көреміз.
ACCESS EXCLUSIVE, мысалы, блоктау пәрмені. Мысалы, егер сіз жасасаңыз CLUSTER table, онда бұл ол жерде ешкім жаза алмайтынын білдіреді. Және ол кестенің өзін ғана емес, индекстерді де құлыптайды.
Бұл ACCESS EXCLUSIVE блоктаудың екінші беті, мұнда кестеде оның нені блоктайтынын көреміз. Ол жеке кесте жолдарын құлыптайды, бұл өте қызықты.
Бұл мен бергім келген негізгі ақпараттың барлығы. Біз құлыптар туралы, транзакция идентификаторлары туралы, виртуалды транзакция идентификаторлары туралы, тұрақты транзакция идентификаторлары туралы айттық.
Ал енді біз кейбір бұғаттау мысалдарын қарастырамыз. Бұл ең қызықты бөлігі. Біз өте қызықты жағдайларды қарастырамыз. Бұл презентациядағы менің мақсатым - белгілі бір нәрселерді бұғаттауға тырысқанда Postgres не істеп жатқанын жақсырақ түсіну. Менің ойымша, ол бөліктерді жабуда өте жақсы.
Кейбір нақты мысалдарды қарастырайық.
Біз кестелерден және кестедегі бір жолдан бастаймыз. Мен бір нәрсені енгізген кезде кестеде ExclusiveLock, транзакция идентификаторы және 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 оның жұмысын аяқтауын күтеміз.
Мен мұнда не болатынын көремін. Ал мұнда екі нәрсе қатар жүреді. Сіз бірінші жолдағы транзакция идентификаторының құлпын қарап жатырсыз, ол өзін құлыптайды. Ол адамдарды күту үшін өзін блоктайды.
Егер сіз 6-шы жолды қарасаңыз, бұл бірінші жолға ұқсас жазба. Сондықтан 699 транзакциясы бұғатталды. 700 сонымен қатар өздігінен құлыпталады. Содан кейін төменгі қатарда сіз оның жұмысын аяқтау үшін 699 күтіп тұрғанымызды көресіз.
Ал lock_type, кортежде сандарды көресіз.
Сіз 0/10 екенін көре аласыз. Бұл бет нөмірі, сонымен қатар осы жолдың ығысуы.
Жаңартқан кезде ол 0/11 болатынын көресіз.
Бірақ іс жүзінде бұл 0/10, өйткені бұл операцияны күту бар. Бұл мен растауды күтетін серия екенін көру мүмкіндігіміз бар.
Біз оны растап, міндеттемені басқаннан кейін және жаңарту аяқталғаннан кейін біз қайтадан аламыз. 700 транзакциясы - жалғыз құлып, ол басқа ешкімді күтпейді, себебі ол жасалған. Ол жай ғана транзакцияның аяқталуын күтеді. 699 таусылғаннан кейін, біз енді ештеңе күтпейміз. Ал қазір 700 транзакциясында бәрі жақсы, барлық рұқсат етілген кестелерде оған қажетті құлыптар бар.
Осының бәрін одан да күрделі ету үшін біз бұл жолы иерархияны қамтамасыз ететін басқа көріністі жасаймыз. Сіз бұл өтінішті түсінесіз деп күтпеймін. Бірақ бұл бізге не болып жатқанын нақтырақ көрсетеді.
Бұл басқа бөлімі бар рекурсивті көрініс. Содан кейін ол бәрін қайтадан біріктіреді. Осыны қолданайық.
Егер біз бір уақытта үш жаңартуды жасасақ және жол енді үш деп айтсақ ше? Ал біз 3-тен 4-ке ауыстырамыз.
Ал мұнда біз 4 көреміз. Және транзакция идентификаторы 702.
Содан кейін мен 4-ті 5-ке ауыстырамын. Ал 5-ті 6-ға, 6-дан 7-ге ауыстырамын. Мен осы бір транзакцияның аяқталуын күтетін бірнеше адамды қатарға қоямын.
Және бәрі түсінікті болады. Бірінші қатар қандай? Бұл 702. Бұл бастапқыда осы мәнді орнатқан транзакция идентификаторы. Менің берілген бағанымда не жазылған? Менде белгілер бар f. Бұл менің жаңартуларым, оларды (5, 6, 7) бекіту мүмкін емес, себебі біз 702 транзакцияның аяқталуын күтіп отырмыз. Онда бізде транзакция идентификаторын блоктау бар. Бұл 5 транзакциялық идентификаторды құлыпқа әкеледі.
Егер сіз 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. Ал мұның соңы жақсылыққа апармайды. Және бұл жағдайдан шығудың жолы жоқ. Және олар бір-бірінен жауап күтетін болады.
Және ол бәрін кейінге қалдыра бастайды. Ал біз мұны қаламаймыз.
Постгрестің бұл жағдайды байқайтын жолдары бар. Және бұл орын алғанда, сіз осы қатені аласыз. Және осыдан анау-мынау процесс басқа процесстен, яғни 711 процессімен блокталған SHARE LOCK-ты күтіп тұрғаны анық. Және бұл процесс осындай және осындай транзакция идентификаторында SHARE LOCK берілуін күтті және осындай және осындай процесс арқылы бұғатталды. Сондықтан бұл жерде тығырыққа тірелген жағдай бар.
Үш жақты тығырықтар бар ма? Бұл мүмкін бе? Иә.
Бұл сандарды кестеге енгіземіз. 40-ты 40-қа ауыстырамыз, блоктау жасаймыз.
60-ты 61-ге, 80-ді 81-ге ауыстырамыз.
Содан кейін біз 80 өзгертеміз, содан кейін бум!
Ал 714-і қазір 715-ті күтуде. 716-сы 715-ті күтіп тұр. Және бұл туралы ештеңе істеу мүмкін емес.
Мұнда енді екі адам жоқ, үш адам бар. Мен сенен бірдеңе қалаймын, мынау үшіншіден, үшінші адам менен бірдеңені қалайды. Және біз үш жақты күтеміз, өйткені біз бәріміз басқа адамның не істеу керек екенін аяқтауын күтеміз.
Постгрес бұл қай қатарда болатынын біледі. Осылайша ол сізге келесі хабарламаны береді, ол сізде үш кіріс бір-бірін блоктайтын мәселе бар екенін көрсетеді. Және бұл жерде ешқандай шектеулер жоқ. Бұл 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 - процесс идентификаторы. Негізінде, бұл функция құлыптау үстеліңіз арқылы өтеді. Мен бұл аздап күрделі екенін білемін, бірақ сіз оны түсіне аласыз. Негізінде бұл функция осы құлыптау кестесі арқылы өтеді және бұл процесс идентификаторына ол күтіп тұрған құлыптар қай жерде берілгенін табуға тырысады. Сондай-ақ ол құлыптауды күтіп тұрған процесте қандай процесс идентификаторы бар екенін анықтауға тырысады. Сондықтан сіз бұл функцияны іске қоса аласыз pg_blocking_pids.
Және бұл өте пайдалы болуы мүмкін. Біз мұны тек 9.6 нұсқасында қостық, сондықтан бұл мүмкіндік тек 5 жаста, бірақ ол өте пайдалы. Екінші сұранысқа да қатысты. Ол бізге нені көру керектігін көрсетеді.
Бұл туралы мен сізбен сөйлескім келді. Мен күткендей, слайдтар көп болғандықтан, біз барлық уақытымызды жұмсадық. Ал слайдтар жүктеп алуға болады. Мен сізге осында болғаныңыз үшін алғыс айтқым келеді. Конференцияның қалған бөлігі сізге ұнайтынына сенімдімін, көп рахмет!
Сұрақтар:
Мысалы, егер мен жолдарды жаңартуға тырыссам, ал екінші сеанс бүкіл кестені жоюға тырысса. Менің түсінуімше, ниет құлпы сияқты нәрсе болуы керек. Постгресте мұндай нәрсе бар ма?
Ең басына оралайық. Сіз кез келген әрекетті орындаған кезде, мысалы, ТАҢДАУ жасағанда, біз AccessShareLock беретінімізді есте сақтауыңыз мүмкін. Және бұл кестенің түсіп кетуіне жол бермейді. Сондықтан, мысалы, кестедегі жолды жаңартқыңыз келсе немесе жолды жойғыңыз келсе, біреу бүкіл кестені бір уақытта жоя алмайды, себебі сіз осы AccessShareLock бағдарламасын бүкіл кестеде және жолдың үстінде ұстап тұрсыз. Аяқтағаннан кейін олар оны жоя алады. Бірақ сіз сол жерде бір нәрсені тікелей өзгерткеніңізде, олар мұны істей алмайды.
Қайтадан жасайық. Жою үлгісіне көшейік. Сіз бүкіл үстелдің үстіндегі жолда эксклюзивті құлыптың қалай бар екенін көресіз.
Бұл эксклюзивті құлыпқа ұқсайды, солай ма?
Иә, солай көрінеді. Не туралы айтып тұрғаныңызды түсінемін. Сіз айтасыз ба, егер мен SELECT жасасам, менде 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-шексіздігі бар. Сондықтан, біз кейінгісін оятуымыз әбден мүмкін. Ал егер, мысалы, біз кейінгісін оятатын болсақ, біз блокты жаңа ғана алған адамды күтеміз, сондықтан кімнің бірінші оянатынын анықтамаймыз. Біз жай ғана осындай жағдайды жасаймыз, ал жүйе оларды кездейсоқ ретпен оятады.
бар . Қараңызшы, олар да қызықты және пайдалы. Тақырып, әрине, өте күрделі. Сізге көп рахмет, Брюс!
Ақпарат көзі: www.habr.com