Bryus Momjianning 2020 yildagi "Postgres qulflash menejerini ochish" nutqining transkripti.
(Eslatma: Slaydlardagi barcha SQL so'rovlarini ushbu havoladan olish mumkin: )
Salom! Bu yerda yana Rossiyada bo'lish juda yaxshi. O‘tgan yili kela olmaganimdan afsusdaman, lekin bu yil Ivan bilan katta rejalarimiz bor. Men bu erda tez-tez bo'lishga umid qilaman. Men Rossiyaga kelishni yaxshi ko'raman. Men Tyumen, Tverga tashrif buyuraman. Men bu shaharlarni ziyorat qilish imkoniyatiga ega bo'lganimdan juda xursandman.
Mening ismim Bryus Momjian. Men EnterpriseDB da ishlayman va Postgres bilan 23 yildan ortiq ishlayapman. Men AQShning Filadelfiya shahrida yashayman. Men yiliga 90 kun sayohat qilaman. Men esa 40 ga yaqin anjumanlarda qatnashaman. mening , unda men hozir ko'rsatadigan slaydlar mavjud. Shuning uchun, konferentsiyadan so'ng ularni shaxsiy veb-saytimdan yuklab olishingiz mumkin. Unda 30 ga yaqin taqdimotlar ham mavjud. Bundan tashqari, videolar va ko'plab blog yozuvlari mavjud, 500 dan ortiq. Bu juda ma'lumot beruvchi manba. Va agar siz ushbu materialga qiziqsangiz, men sizni undan foydalanishga taklif qilaman.
Men Postgres bilan ishlashni boshlashdan oldin o'qituvchi, professor bo'lganman. Va endi sizga aytmoqchi bo'lganlarimni aytib bera olishimdan juda xursandman. Bu mening eng qiziqarli taqdimotlarimdan biri. Ushbu taqdimot 110 ta slaydni o'z ichiga oladi. Biz oddiy narsalar bilan gaplashishni boshlaymiz va oxirigacha hisobot tobora murakkablashadi va ancha murakkablashadi.
Bu juda yoqimsiz suhbat. Bloklash eng mashhur mavzu emas. Biz buning biror joyda yo'qolishini xohlaymiz. Bu tish shifokoriga borishga o'xshaydi.
- Qulflash ma'lumotlar bazalarida ishlaydigan va bir vaqtning o'zida bir nechta jarayonlarga ega bo'lgan ko'plab odamlar uchun muammodir. Ular blokirovkaga muhtoj. Ya'ni, bugun men sizga blokirovka bo'yicha asosiy bilimlarni beraman.
- Tranzaksiya identifikatorlari. Bu taqdimotning juda zerikarli qismi, ammo ularni tushunish kerak.
- Keyinchalik blokirovka turlari haqida gapiramiz. Bu juda mexanik qism.
- Va quyida biz blokirovka qilishning ba'zi misollarini beramiz. Va buni tushunish juda qiyin bo'ladi.
Keling, blokirovka haqida gapiraylik.
Bizning terminologiyamiz ancha murakkab. Qanchangiz bu parcha qayerdan kelganini bilasizmi? Ikki kishi. Bu Colossal Cave Adventure deb nomlangan o'yindan. Bu 80-yillarda matnga asoslangan kompyuter o'yini edi, menimcha. U erda siz g'orga, labirintga kirishingiz kerak edi va matn o'zgardi, lekin mazmun har safar taxminan bir xil edi. Men bu o'yinni shunday eslayman.
Va bu erda biz Oracle'dan bizga kelgan qulflarning nomini ko'ramiz. Biz ulardan foydalanamiz.
Bu erda biz meni chalkashtirib yuboradigan atamalarni ko'ramiz. Masalan, SHARE UPDATE ECXLUSIVE. Keyingi SHARE RAW EKXLUSIVE. Rostini aytsam, bu nomlar unchalik aniq emas. Biz ularni batafsilroq ko'rib chiqishga harakat qilamiz. Ba'zilarida ajratish degan ma'noni anglatuvchi "ulush" so'zi mavjud. Ba'zilarida "eksklyuziv" so'zi mavjud. Ba'zilarida bu ikkala so'z ham mavjud. Men bu qulflar qanday ishlashidan boshlamoqchiman.
Va "kirish" so'zi ham juda muhimdir. Va "qator" so'zlari qatordir. Ya'ni, kirish taqsimoti, qatorlarni taqsimlash.
Postgresda tushunilishi kerak bo'lgan yana bir masala, afsuski, men o'z nutqimda yorita olmayman - MVCC. Mening veb-saytimda ushbu mavzu bo'yicha alohida taqdimotim bor. Va agar siz ushbu taqdimotni qiyin deb hisoblasangiz, MVCC, ehtimol, men uchun eng qiyin. Va agar qiziqsangiz, uni veb-saytda ko'rishingiz mumkin. Videoni tomosha qilishingiz mumkin.
Biz tushunishimiz kerak bo'lgan yana bir narsa - tranzaksiya identifikatorlari. Ko'pgina operatsiyalar noyob identifikatorlarsiz ishlamaydi. Va bu erda biz tranzaktsiya nima ekanligini tushuntiramiz. Postgres ikkita tranzaksiyani raqamlash tizimiga ega. Bilaman, bu juda chiroyli yechim emas.
Shuni ham yodda tutingki, slaydlarni tushunish juda qiyin, shuning uchun qizil rang bilan ta'kidlangan narsaga e'tibor berishingiz kerak.
Ko'raylikchi. Tranzaksiya raqami qizil rang bilan ta'kidlangan. SELECT pg_back funksiyasi bu yerda ko'rsatilgan. U mening tranzaksiyam va tranzaksiya identifikatorini qaytaradi.
Yana bir narsa, agar sizga ushbu taqdimot yoqqan bo'lsa va uni ma'lumotlar bazasida ishga tushirishni istasangiz, pushti rangdagi ushbu havolaga o'ting va ushbu taqdimot uchun SQL-ni yuklab olishingiz mumkin. Siz uni oddiygina PSQL-da ishga tushirishingiz mumkin va butun taqdimot darhol ekraningizda bo'ladi. Unda gullar bo'lmaydi, lekin hech bo'lmaganda biz buni ko'ramiz.
Bunday holda biz tranzaksiya identifikatorini ko'ramiz. Bu biz unga bergan raqam. Postgres-da tranzaksiya identifikatorining yana bir turi mavjud bo'lib, u virtual tranzaksiya identifikatori deb ataladi
Va biz buni tushunishimiz kerak. Bu juda muhim, aks holda biz Postgres-da qulflashni tushuna olmaymiz.
Virtual tranzaksiya identifikatori doimiy qiymatlarni o'z ichiga olmaydigan tranzaksiya identifikatoridir. Misol uchun, agar men SELECT buyrug'ini ishga tushirsam, ehtimol ma'lumotlar bazasini o'zgartirmayman, hech narsani bloklamayman. Shunday qilib, biz oddiy SELECTni ishga tushirganimizda, biz ushbu tranzaksiyaga doimiy identifikatorni bermaymiz. Biz unga faqat virtual identifikatorni beramiz.
Va bu Postgres ish faoliyatini yaxshilaydi, tozalash imkoniyatlarini yaxshilaydi, shuning uchun virtual tranzaksiya identifikatori ikkita raqamdan iborat. Eğik chiziqdan oldingi birinchi raqam backend ID hisoblanadi. Va o'ng tomonda biz faqat hisoblagichni ko'ramiz.
Shuning uchun, agar men so'rovni bajarsam, u backend ID 2 ekanligini aytadi.
Va agar men bunday tranzaktsiyalar seriyasini amalga oshirsam, har safar so'rovni bajarganimda hisoblagich ko'payganini ko'ramiz. Misol uchun, so'rovni bajarganimda 2/10, 2/11, 2/12, va hokazo.
Bu erda ikkita ustun mavjudligini yodda tuting. Chapda biz virtual tranzaksiya identifikatorini ko'ramiz - 2/12. Va o'ng tomonda bizda doimiy tranzaksiya identifikatori mavjud. Va bu maydon bo'sh. Va bu tranzaksiya ma'lumotlar bazasini o'zgartirmaydi. Shuning uchun men unga doimiy tranzaksiya identifikatorini bermayman.
Tahlil buyrug'ini ((ANALIZE) ishga tushirishim bilanoq, xuddi shu so'rov menga doimiy tranzaksiya identifikatorini beradi. Bu biz uchun qanday o'zgarganiga qarang. Ilgari menda bu identifikator yo'q edi, lekin hozir menda bor.
Demak, yana bir so‘rov, yana bir tranzaksiya. Virtual tranzaksiya raqami 2/13. Va agar men doimiy tranzaksiya identifikatorini so'rasam, so'rovni bajarganimda, men uni olaman.
Shunday qilib, yana bir marta. Bizda virtual tranzaksiya identifikatori va doimiy tranzaksiya identifikatori mavjud. Postgres xatti-harakatini tushunish uchun ushbu nuqtani tushunish kifoya.
Biz uchinchi bo'limga o'tamiz. Bu erda biz Postgres-dagi har xil turdagi qulflar bo'ylab yuramiz. Bu unchalik qiziq emas. Oxirgi bo'lim yanada qiziqarli bo'ladi. Ammo biz asosiy narsalarni ko'rib chiqishimiz kerak, chunki aks holda biz keyin nima bo'lishini tushunmaymiz.
Biz ushbu bo'limni ko'rib chiqamiz, har bir qulf turini ko'rib chiqamiz. Va men sizga ularning qanday o'rnatilishi, qanday ishlashi haqida misollar ko'rsataman, Postgres-da qulflash qanday ishlashini ko'rish uchun foydalanishingiz mumkin bo'lgan ba'zi so'rovlarni ko'rsataman.
So'rov yaratish va Postgres-da nima sodir bo'layotganini ko'rish uchun biz so'rovni tizim ko'rinishida berishimiz kerak. Bunday holda, pg_lock qizil rang bilan ta'kidlangan. Pg_lock - bu Postgres-da hozirda qanday qulflar qo'llanilayotganligini aytib beradigan tizim jadvali.
Biroq, sizga pg_lockni o'zi ko'rsatish men uchun juda qiyin, chunki bu juda murakkab. Shunday qilib, men pg_locks ko'rsatadigan ko'rinish yaratdim. Va bu menga yaxshiroq tushunishga imkon beradigan ba'zi ishlarni bajaradi. Ya'ni, u mening qulflarimni, o'z seansimni va hokazolarni o'z ichiga olmaydi. Bu shunchaki standart SQL va u sizga nima bo'layotganini yaxshiroq ko'rsatish imkonini beradi.
Yana bir muammo shundaki, bu ko'rinish juda keng, shuning uchun men ikkinchisini yaratishim kerak - lockview2.
Va u menga jadvaldan ko'proq ustunlarni ko'rsatadi. Va menga qolgan ustunlarni ko'rsatadigan yana biri. Bu juda murakkab, shuning uchun men uni iloji boricha sodda tarzda taqdim etishga harakat qildim.
Shunday qilib, biz Lockdemo deb nomlangan jadval yaratdik. Va biz u erda bitta chiziq yaratdik. Bu bizning namunaviy jadvalimiz. Va biz sizga qulflar misollarini ko'rsatish uchun bo'limlarni yaratamiz.
Shunday qilib, bitta qator, bitta ustun. Birinchi turdagi qulf ACCESS SHARE deb ataladi. Bu eng kam cheklovchi blokirovka. Bu shuni anglatadiki, u boshqa qulflar bilan deyarli zid kelmaydi.
Va agar biz qulfni aniq belgilashni istasak, biz "qulflash jadvali" buyrug'ini bajaramiz. Va u aniq bloklanadi, ya'ni ACCESS SHARE rejimida biz blokirovka jadvalini ishga tushiramiz. Va agar men PSQL-ni fonda ishga tushirsam, ikkinchi seansni birinchi sessiyamdan shu tarzda boshlayman. Ya'ni, men bu erda nima qilaman? Men boshqa seansga o'taman va unga "ushbu so'rov uchun qulf ko'rinishini ko'rsating" deyman. Va menda ushbu jadvalda AccessShareLock bor. Bu men so'ragan narsadir. Va u blok tayinlanganligini aytadi. Juda oddiy.
Bundan tashqari, agar biz ikkinchi ustunga qarasak, unda hech narsa yo'q. Ular bo'sh.
Va agar men "SELECT" buyrug'ini ishga tushirsam, bu AccessShareLock so'rovining yashirin (aniq) usulidir. Shuning uchun men jadvalimni qo'yib yuboraman va so'rovni bajaraman va so'rov bir nechta qatorlarni qaytaradi. Va qatorlardan birida biz AccessShareLock-ni ko'ramiz. Shunday qilib, SELECT stolda AccessShareLock-ni chaqiradi. Va u deyarli hech narsaga zid kelmaydi, chunki u past darajadagi qulfdir.
SELECT-ni ishga tushirsam va uchta turli jadvalga ega bo'lsam nima bo'ladi? Ilgari men faqat bitta jadval bilan ishlayapman, endi uchta ishlayapman: pg_class, pg_namespace va pg_attribute.
Va endi men so'rovga qaraganimda, uchta jadvalda 9 ta AccessShareLocks ni ko'raman. Nega? Uchta jadval ko'k rangda ajratilgan: pg_attribute, pg_class, pg_namespace. Ammo, shuningdek, ushbu jadvallar orqali aniqlangan barcha indekslarda AccessShareLock ham borligini ko'rishingiz mumkin.
Va bu boshqalar bilan deyarli zid kelmaydigan qulf. Va bu faqat biz uni tanlashda jadvalni qayta o'rnatishimizga to'sqinlik qiladi. Bu mantiqiy. Ya'ni, agar biz jadvalni tanlasak, u o'sha paytda yo'qoladi, demak bu noto'g'ri, shuning uchun AccessShare - bu past darajadagi qulf bo'lib, u "men ishlayotganimda ushbu jadvalni tashlab ketmang". Umuman olganda, u shunday qiladi.
ROW SHARE - Bu qulf biroz boshqacha.
Keling, bir misol keltiraylik. SELECT ROW SHARE usuli har bir qatorni alohida qulflash. Shunday qilib, biz ularni kuzatayotganimizda hech kim ularni o'chira olmaydi yoki o'zgartira olmaydi.
Xo'sh, SHARE LOCK nima qiladi? Biz SELECT uchun tranzaksiya identifikatori 681 ekanligini ko'ramiz. Va bu qiziq. Bu erda nima bo'ldi? Raqamni birinchi marta "Qulflash" maydonida ko'ramiz. Biz tranzaksiya identifikatorini olamiz va u eksklyuziv rejimda uni bloklayotganini aytadi. Bu menda stolning biror joyida texnik jihatdan qulflangan qator borligini aytadi. Ammo u aniq qayerda ekanligini aytmaydi. Buni biroz keyinroq batafsil ko'rib chiqamiz.
Bu erda biz qulfni biz ishlatayotganini aytamiz.
Shunday qilib, eksklyuziv qulf bu eksklyuziv ekanligini aniq aytadi. Va agar siz ushbu jadvaldagi qatorni o'chirsangiz, ko'rib turganingizdek, shunday bo'ladi.
SHARE EXCLUSIVE - bu uzunroq qulf.
Bu foydalaniladigan (ANALIZE) analizator buyrug'i.
SHARE LOCK – siz almashish rejimida aniq bloklashingiz mumkin.
Bundan tashqari, noyob indeks yaratishingiz mumkin. Va u erda siz ularning bir qismi bo'lgan SHARE LOCK-ni ko'rishingiz mumkin. Va u stolni qulflaydi va unga SHARE LOCK qo'yadi.
Odatiy bo'lib, jadvaldagi SHARE LOCK boshqa odamlar jadvalni o'qishi mumkin, lekin hech kim uni o'zgartira olmaydi. Va bu noyob indeks yaratganingizda sodir bo'ladi.
Agar men bir vaqtning o'zida noyob indeks yaratsam, men boshqa turdagi blokirovkaga ega bo'laman, chunki siz eslaganingizdek, bir vaqtning o'zida indekslardan foydalanish qulflash talabini kamaytiradi. Va agar men oddiy qulfdan, oddiy indeksdan foydalansam, u yaratilayotgan vaqtda jadval indeksiga yozishni oldini olaman. Agar men bir vaqtning o'zida indeksdan foydalansam, boshqa turdagi qulflashdan foydalanishim kerak.
SHARE ROW EXCLUSIVE – yana uni aniq (aniq) belgilash mumkin.
Yoki biz qoida yaratishimiz mumkin, ya'ni u qo'llaniladigan muayyan holatni olamiz.
EXCLUSIVE qulflash stolni boshqa hech kim o'zgartira olmasligini anglatadi.
Bu erda biz har xil turdagi qulflarni ko'ramiz.
ACCESS EXCLUSIVE, masalan, blokirovka qiluvchi buyruqdir. Misol uchun, agar shunday qilsangiz CLUSTER table, keyin bu hech kim u erda yoza olmasligini anglatadi. Va u nafaqat jadvalning o'zini, balki indekslarni ham qulflaydi.
Bu ACCESS EXCLUSIVE blokirovkasining ikkinchi sahifasi bo'lib, biz jadvalda aynan nimani bloklashini ko'ramiz. U alohida jadval qatorlarini qulflaydi, bu juda qiziq.
Bu men bermoqchi bo'lgan barcha asosiy ma'lumotlar. Biz qulflar, tranzaksiya identifikatorlari haqida, virtual tranzaksiya identifikatorlari, doimiy tranzaksiya identifikatorlari haqida gaplashdik.
Va endi biz bir nechta blokirovka qiluvchi misollarni ko'rib chiqamiz. Bu eng qiziqarli qism. Biz juda qiziqarli holatlarni ko'rib chiqamiz. Va mening ushbu taqdimotdagi maqsadim sizga Postgres ba'zi narsalarni blokirovka qilishga urinayotganda nima qilayotganini yaxshiroq tushunishdir. Menimcha, u qismlarni to'sib qo'yishda juda yaxshi.
Keling, ba'zi aniq misollarni ko'rib chiqaylik.
Biz jadvallar va jadvaldagi bir qatordan boshlaymiz. Men biror narsani kiritganimda, stolda ExclusiveLock, Transaction ID va ExclusiveLock ko'rsatiladi.
Yana ikkita qator qo'ysam nima bo'ladi? Va endi bizning stolimiz uchta qatorga ega. Va men bitta qatorni kiritdim va buni natija sifatida oldim. Va agar yana ikkita qator qo'ysam, buning nimasi g'alati? Bu erda g'alati narsa bor, chunki men ushbu jadvalga uchta qator qo'shdim, lekin qulflangan stolda hali ham ikkita qator bor. Va bu Postgresning asosiy xatti-harakatidir.
Ko'pchilik, agar siz ma'lumotlar bazasida 100 ta qatorni qulflasangiz, 100 ta blokirovka yozuvlarini yaratishingiz kerak deb o'ylashadi. Agar men bir vaqtning o'zida 1 ta qatorni bloklasam, menga 000 ta shunday so'rovlar kerak bo'ladi. Va agar menga blokirovka qilish uchun million yoki milliard kerak bo'lsa. Ammo buni qilsak, unchalik yaxshi ishlamaydi. Agar siz har bir alohida qator uchun blokirovka yozuvlarini yaratadigan tizimdan foydalangan bo'lsangiz, bu juda murakkab ekanligini ko'rishingiz mumkin. Chunki siz darhol to'lib ketishi mumkin bo'lgan blokirovka jadvalini belgilashingiz kerak, ammo Postgres buni qilmaydi.
Va bu slaydning eng muhimi shundaki, u MVCC ichida alohida satrlarni bloklaydigan boshqa tizim mavjudligini aniq ko'rsatib beradi. Shunday qilib, siz milliardlab qatorlarni qulflaganingizda, Postgres milliardlab alohida qulflash buyruqlarini yaratmaydi. Va bu hosildorlikka juda yaxshi ta'sir qiladi.
Yangilanish haqida nima deyish mumkin? Men hozir qatorni yangilayapman va u bir vaqtning o'zida ikki xil operatsiyani bajarganini ko'rishingiz mumkin. U bir vaqtning o'zida stolni qulfladi, lekin indeksni ham qulfladi. Va u indeksni qulflashi kerak edi, chunki bu jadvalda noyob cheklovlar mavjud. Va biz buni hech kim o'zgartirmasligiga ishonch hosil qilishni xohlaymiz, shuning uchun uni bloklaymiz.
Ikki qatorni yangilamoqchi bo'lsam nima bo'ladi? Va biz uning xuddi shunday yo'l tutishini ko'ramiz. Biz ikki baravar ko'p yangilanishlarni qilamiz, lekin aynan bir xil miqdordagi qulflash chiziqlari.
Agar siz Postgres buni qanday amalga oshirayotganiga qiziqsangiz, Postgres o'zgartiradigan satrlarni qanday qilib ichki belgilaganini bilish uchun MVCC-dagi suhbatlarimni tinglashingiz kerak bo'ladi. Va Postgresda buni qilish usuli bor, lekin u buni stolni qulflash darajasida qilmaydi, uni pastroq va samaraliroq darajada qiladi.
Agar biror narsani o'chirmoqchi bo'lsam nima bo'ladi? Agar men, masalan, bitta qatorni o'chirib tashlasam va menda ikkita blokirovka qiluvchi kirishlar mavjud bo'lsa ham, ularning barchasini o'chirmoqchi bo'lsam ham, ular hali ham mavjud.
Va, masalan, men 1 ta qatorni qo'shishni xohlayman, keyin esa 000 qatorni o'chirish yoki qo'shishni xohlayman, keyin men qo'shadigan yoki o'zgartiradigan alohida satrlar bu erda yozilmaydi. Ular seriyaning o'zida pastroq darajada yozilgan. Va MVCC nutqida men bu haqda batafsil gapirib berdim. Lekin siz bloklarni tahlil qilayotganda jadval darajasida qulflanganligingizga va bu yerda alohida satrlar qanday yozilayotganini ko‘rmasligingizga ishonch hosil qilish juda muhim.
Aniq blokirovka haqida nima deyish mumkin?
Yangilash tugmasini bossam, menda ikkita qator qulflangan. Va agar men ularning barchasini tanlasam va "hamma joyda yangilash" tugmasini bossam, menda hali ham ikkita blokirovka qiluvchi yozuv bor.
Biz har bir alohida qator uchun alohida yozuvlar yaratmaymiz. Chunki keyin hosildorlik pasayadi, u juda ko'p bo'lishi mumkin. Va biz o'zimizni yoqimsiz vaziyatga duchor qilishimiz mumkin.
Xuddi shu narsa, agar biz baham ko'rsak, barchasini 30 marta bajarishimiz mumkin.
Biz jadvalimizni tiklaymiz, hamma narsani o'chirib tashlaymiz, keyin yana bitta qatorni qo'shamiz.
Postgres-da ko'rgan yana bir xatti-harakat juda yaxshi ma'lum va kerakli xatti-harakatlardir, siz yangilash yoki tanlashni amalga oshirishingiz mumkin. Va buni bir vaqtning o'zida qilishingiz mumkin. Va tanlash yangilanishni bloklamaydi va xuddi shu narsani teskari yo'nalishda. Biz o‘quvchiga yozuvchiga to‘siq qo‘yma deymiz, yozuvchi esa o‘quvchini to‘smagan.
Men sizga buning misolini ko'rsataman. Men hozir tanlov qilaman. Keyin INSERT ni bajaramiz. Va keyin siz ko'rishingiz mumkin - 694. Siz ushbu kiritishni amalga oshirgan tranzaksiya identifikatorini ko'rishingiz mumkin. Va u shunday ishlaydi.
Va agar men hozir backend identifikatorimga qarasam, u hozir 695.
Va mening jadvalimda 695 ko'rinishini ko'rishim mumkin.
Va agar men bu erda shunday yangilansam, men boshqa holatga duch kelaman. Bunday holda, 695 eksklyuziv qulf bo'lib, yangilanish bir xil harakatga ega, ammo ular o'rtasida hech qanday ziddiyat yo'q, bu juda g'ayrioddiy.
Va yuqori qismida u ShareLock, pastki qismida esa ExclusiveLock ekanligini ko'rishingiz mumkin. Va ikkala tranzaktsiya ham amalga oshdi.
Va bu qanday sodir bo'lishini tushunish uchun MVCCdagi nutqimni tinglashingiz kerak. Ammo bu siz buni bir vaqtning o'zida bajarishingiz mumkin bo'lgan illyustratsiya, ya'ni bir vaqtning o'zida SELECT va UPDATE ni bajarishingiz mumkin.
Keling, qayta o'rnatamiz va yana bitta operatsiyani bajaramiz.
Agar bir vaqtning o'zida ikkita yangilanishni bir qatorda ishga tushirishga harakat qilsangiz, u bloklanadi. Yodingizda bo‘lsin, o‘quvchi yozuvchini to‘sib qo‘ymaydi, yozuvchi ham o‘quvchini to‘smaydi, bir yozuvchi boshqa yozuvchini to‘sadi, degandim. Ya'ni, bir vaqtning o'zida ikkita odam bir qatorni yangilay olmaydi. Ulardan biri tugaguncha kutishingiz kerak.
Va buni tasvirlash uchun men Lockdemo jadvalini ko'rib chiqaman. Va biz bitta qatorni ko'rib chiqamiz. Har bir tranzaksiya uchun 698.
Biz buni 2 ga yangiladik. 699 - bu birinchi yangilanish. Va u muvaffaqiyatli bo'ldi yoki u kutilayotgan tranzaksiyada va biz tasdiqlash yoki bekor qilishimizni kutmoqda.
Ammo boshqa narsaga qarang - 2/51 - bu bizning birinchi tranzaksiyamiz, birinchi sessiyamiz. 3/112 yuqoridan kelgan ikkinchi so'rov bo'lib, bu qiymatni 3 ga o'zgartirdi. Agar e'tibor bersangiz, yuqoridagi so'rov o'zini qulflab qo'ydi, ya'ni 699. Lekin 3/112 qulfni bermadi. Lock_mode ustuni nima kutayotganini aytadi. U 699 ni kutmoqda. Agar 699 qaerda ekanligiga qarasangiz, u yuqoriroq. Va birinchi sessiya nima qildi? U o'zining tranzaksiya identifikatorida eksklyuziv qulf yaratdi. Postgres buni shunday qiladi. U o'z tranzaksiya identifikatorini bloklaydi. Va agar kimdir tasdiqlash yoki bekor qilishini kutmoqchi bo'lsangiz, kutilayotgan tranzaksiya mavjud bo'lganda kutishingiz kerak. Va shuning uchun biz g'alati chiziqni ko'rishimiz mumkin.
Keling, yana qaraylik. Chapda biz ishlov berish identifikatorini ko'ramiz. Ikkinchi ustunda biz virtual tranzaksiya identifikatorini, uchinchisida esa lock_type ni ko'ramiz. Bu nimani anglatadi? Asosan, u tranzaksiya identifikatorini blokirovka qilishini aytadi. Ammo e'tibor bering, pastki qismdagi barcha qatorlar munosabatni bildiradi. Shunday qilib, stolda ikkita turdagi qulflar mavjud. Aloqa blokirovkasi mavjud. Va keyin tranzaksid blokirovkasi mavjud, bu erda siz o'zingiz bloklaysiz, aynan birinchi qatorda yoki eng pastki qismida sodir bo'ladi, tranzakid qaerda, biz 699 uning ishlashini kutamiz.
Bu erda nima bo'lishini ko'raman. Va bu erda ikkita narsa bir vaqtning o'zida sodir bo'ladi. Siz birinchi qatordagi tranzaksiya identifikatori qulfiga qarayapsiz, u o'zini qulflaydi. Va u odamlarni kutishga majbur qilish uchun o'zini to'sadi.
Agar siz 6-qatorga qarasangiz, u birinchisi bilan bir xil yozuvdir. Va shuning uchun tranzaksiya 699 bloklanadi. 700 ham o'z-o'zidan qulflanadi. Va keyin pastki qatorda biz 699 uning ishlashini kutayotganimizni ko'rasiz.
Va lock_type, kortejda siz raqamlarni ko'rasiz.
Siz 0/10 ekanligini ko'rishingiz mumkin. Va bu sahifa raqami, shuningdek, ushbu qatorning ofsetidir.
Va biz yangilaganimizda 0/11 bo'lishini ko'rasiz.
Lekin aslida bu 0/10, chunki bu operatsiyani kutish mavjud. Bu men tasdiqlashni kutayotgan seriya ekanligini ko'rish imkoniga egamiz.
Biz buni tasdiqlab, majburiyatni bosganimizdan so'ng va yangilanish tugagach, biz yana shu narsaga erishamiz. Tranzaksiya 700 - bu yagona qulf, u boshqa hech kimni kutmaydi, chunki u amalga oshirilgan. Bu shunchaki tranzaksiya tugashini kutadi. 699 tugagach, biz boshqa hech narsani kutmaymiz. Va endi 700 tranzaksiyasi hamma narsa yaxshi ekanligini, barcha ruxsat etilgan jadvallarda kerak bo'lgan barcha qulflarga ega ekanligini aytadi.
Va bu ishni yanada murakkablashtirish uchun biz boshqa ko'rinishni yaratamiz, bu safar bizga ierarxiyani taqdim etadi. Bu iltimosni tushunishingizni kutmayman. Ammo bu bizga nima bo'layotganini aniqroq ko'rish imkonini beradi.
Bu boshqa bo'limga ega bo'lgan rekursiv ko'rinishdir. Va keyin hamma narsani yana birlashtiradi. Keling, buni ishlataylik.
Agar biz bir vaqtning o'zida uchta yangilanishni amalga oshirsak va qator endi uchta ekanligini aytsak nima bo'ladi. Va biz 3 ni 4 ga almashtiramiz.
Va bu erda biz ko'ramiz 4. Va tranzaksiya ID 702.
Va keyin men 4 ni 5 ga o'zgartiraman. 5 ni 6 ga va 6 ni 7 ga o'zgartiraman. Va men bu bitta tranzaksiya tugashini kutadigan bir qancha odamlarni qatorga qo'yaman.
Va hamma narsa aniq bo'ladi. Birinchi qator nima? Bu 702. Bu qiymatni dastlab belgilagan tranzaksiya identifikatori. Mening berilgan ustunimda nima yozilgan? Menda belgilar bor f. Bu mening yangilanishlarim, ularni (5, 6, 7) tasdiqlash mumkin emas, chunki biz ID 702 tranzaksiya tugashini kutmoqdamiz. U erda bizda tranzaksiya ID blokirovkasi mavjud. Va bu 5 ta tranzaksiya ID blokirovkasiga olib keladi.
Va agar siz 704, 705 ga qarasangiz, u erda hali hech narsa yozilmagan, chunki ular hali nima bo'layotganini bilishmaydi. Ular shunchaki nima bo'layotganini bilmasliklarini yozadilar. Va ular shunchaki uyquga ketishadi, chunki ular qatorlarni o'zgartirish imkoniyati mavjud bo'lganda, kimdir tugatishini va uyg'onishini kutishadi.
Bu shunday ko'rinadi. Ularning barchasi 12-qatorni kutishayotgani aniq.
Bu biz bu erda ko'rgan narsamiz. Mana 0/12.
Shunday qilib, birinchi tranzaktsiya tasdiqlangandan so'ng, bu erda ierarxiya qanday ishlashini ko'rishingiz mumkin. Va endi hamma narsa aniq bo'ladi. Ularning barchasi toza bo'ladi. Va ular haqiqatan ham kutishmoqda.
Mana nima bo'lyapti. 702 ta majburiyat. Va endi 703 bu qator qulfini oladi va keyin 704 703 ning bajarilishini kuta boshlaydi. 705 ham buni kutmoqda. Va bularning barchasi tugagach, ular o'zlarini tozalaydilar. Va shuni ta'kidlashni istardimki, hamma navbatda turibdi. Va bu hamma birinchi mashinani kutayotgan tirbandlikdagi vaziyatga juda o'xshaydi. Birinchi mashina to'xtaydi va hamma uzun navbatda turishadi. Keyin u harakat qiladi, keyin keyingi mashina oldinga siljishi va blokini olishi mumkin va hokazo.
Va agar bu sizga etarlicha murakkab bo'lmasa, biz endi siz bilan boshi berk ko'chaga chiqish haqida gaplashamiz. Qaysi biringiz ularga duch kelganingizni bilmayman. Bu ma'lumotlar bazasi tizimlarida juda keng tarqalgan muammo. Biroq, bir seans boshqa bir seansni biror narsa qilishini kutayotganda, boshi berk ko'chaga kirishadi. Va hozirda yana bir sessiya birinchi sessiyani kutmoqda.
Va, masalan, agar Ivan: "Menga biror narsa bering", deb aytsa va men: "Yo'q, men sizga boshqa narsa bersangizgina beraman" desam. Va u: "Yo'q, agar menga bermasangiz, men sizga bermayman", deydi. Va biz boshi berk ko'chaga tushib qolamiz. Ishonchim komilki, Ivan buni qilmaydi, lekin siz bizda nimanidir olishni xohlaydigan ikkita odam borligini tushunasiz va ular boshqa odam xohlagan narsasini bermaguncha uni berishga tayyor emaslar. Va hech qanday yechim yo'q.
Va aslida, sizning ma'lumotlar bazangiz buni aniqlashi kerak. Va keyin siz sessiyalardan birini o'chirishingiz yoki yopishingiz kerak, chunki aks holda ular u erda abadiy qoladilar. Va biz buni ma'lumotlar bazalarida ko'ramiz, biz buni operatsion tizimlarda ko'ramiz. Va bizda parallel jarayonlar mavjud bo'lgan barcha joylarda bu sodir bo'lishi mumkin.
Va endi biz ikkita qulfni o'rnatamiz. Biz 50 va 80 ni qo'yamiz. Birinchi qatorda men 50 dan 50 gacha yangilayman. Men 710 tranzaksiya raqamini olaman.
Keyin 80 ni 81 ga, 50 ni 51 ga almashtiraman.
Va bu shunday ko'rinadi. Shunday qilib, 710 qator bloklangan va 711 tasdiqlashni kutmoqda. Biz buni yangilaganimizda ko'rdik. 710 bizning seriyamizning egasi. Va 711 tranzaktsiyani yakunlash uchun 710 ni kutadi.
Va hatto qaysi qatorda boshi berk ko'chaga tushishi aytiladi. Va bu erda g'alati bo'la boshlaydi.
Endi biz 80 dan 80 gacha yangilayapmiz.
Va bu erda to'siqlar boshlanadi. 710 711 dan javob kutmoqda, 711 esa 710 ni kutmoqda. Va bu yaxshilik bilan tugamaydi. Va bundan chiqishning iloji yo'q. Va ular bir-birlaridan javob kutishadi.
Va u faqat hamma narsani kechiktira boshlaydi. Va biz buni xohlamaymiz.
Va Postgres bu sodir bo'lganda payqash usullariga ega. Va bu sodir bo'lganda, siz ushbu xatoni olasiz. Va bundan ko'rinib turibdiki, falon jarayon boshqa jarayondan, ya'ni 711 jarayoni tomonidan bloklangan SHARE LOCKni kutmoqda. Va bu jarayon falon tranzaksiya identifikatorida SHARE LOCK berilishini kutayotgan va falon jarayon tomonidan bloklangan edi. Shu sababli, bu erda boshi berk ko'chaga tushib qolgan.
Uch tomonlama o'lik bormi? Buni iloji bormi? Ha.
Biz bu raqamlarni jadvalga kiritamiz. Biz 40 ni 40 ga almashtiramiz, biz blokirovka qilamiz.
Biz 60 ni 61 ga, 80 ni 81 ga almashtiramiz.
Va keyin biz 80 ni o'zgartiramiz va keyin bum!
Va 714 endi 715ni kutmoqda. 716-chi 715-ni kutmoqda. Va bu haqda hech narsa qilish mumkin emas.
Bu yerda endi ikki kishi yo‘q, bu yerda allaqachon uch kishi bor. Men sizdan nimadir xohlayman, bu uchinchi shaxsdan, uchinchisi esa mendan nimanidir xohlaydi. Va biz uch tomonlama kutish bilan yakun topamiz, chunki biz hammamiz boshqa odam nima qilishi kerakligini kutamiz.
Va Postgres bu qaysi qatorda sodir bo'lishini biladi. Shunday qilib, u sizga quyidagi xabarni beradi, bu sizning uchta kirish bir-biriga to'sqinlik qiladigan muammo borligini ko'rsatadi. Va bu erda hech qanday cheklovlar yo'q. Bu 20 ta yozuv bir-birini to'sib qo'yadigan holat bo'lishi mumkin.
Keyingi muammo seriyali bo'lishi mumkin.
Agar maxsus seriyali qulf bo'lsa.
Va biz 719 ga qaytamiz. Uning chiqishi juda normal.
Va tranzaktsiyani ketma-ketlashtirilishi mumkin qilish uchun bosing.
Va endi sizda boshqa turdagi SA qulfi borligini tushunasiz - bu seriyali bo'lishini anglatadi.
Shunday qilib, bizda SARieadLock deb nomlangan yangi turdagi qulf mavjud, bu ketma-ket qulf bo'lib, seriallarni kiritish imkonini beradi.
Shuningdek, siz noyob indekslarni kiritishingiz mumkin.
Ushbu jadvalda bizda noyob indekslar mavjud.
Shunday qilib, agar men bu erda 2 raqamini qo'ysam, menda 2 bor. Lekin eng yuqori qismida men yana 2 qo'ydim. Va siz 721da eksklyuziv qulf borligini ko'rishingiz mumkin. Ammo hozir 722 721 o'z ishini yakunlashini kutmoqda, chunki u 2 bilan nima bo'lishini bilmaguncha 721 ni kirita olmaydi.
Va agar biz subtransaktsiya qilsak.
Bu erda bizda 723 bor.
Va agar biz nuqtani saqlasak va keyin uni yangilasak, biz yangi tranzaksiya identifikatorini olamiz. Bu siz bilishingiz kerak bo'lgan yana bir xatti-harakat namunasidir. Agar biz buni qaytarsak, tranzaksiya identifikatori o'chib ketadi. 724 ketmoqda. Ammo hozir bizda 725 bor.
Xo'sh, men bu erda nima qilmoqchiman? Men sizga g'ayrioddiy qulflar misollarini ko'rsatishga harakat qilyapman: siz seriyali qulflar yoki SAVEPOINT bo'ladimi, bu bloklash jadvalida paydo bo'ladigan har xil turdagi qulflar.
Bu pg_advisory_lock-ga ega bo'lgan aniq (aniq) qulflarni yaratishdir.
Va siz blokirovka turi maslahat sifatida ko'rsatilganligini ko'rasiz. Va bu erda qizil rangda "maslahat" deb yozilgan. Va siz bir vaqtning o'zida pg_advisory_unlock bilan shunday bloklashingiz mumkin.
Xulosa qilib, men sizga yana bir hayratlanarli narsani ko'rsatmoqchiman. Men boshqa ko'rinish yarataman. Lekin men pg_locks jadvaliga pg_stat_activity jadvali bilan qo'shilaman. Va nega men buni qilishni xohlayman? Chunki bu menga barcha joriy seanslarni ko'rish va ko'rish va ular qanday qulflarni kutayotganini ko'rish imkonini beradi. Va bu biz qulflash jadvali va so'rovlar jadvalini birlashtirganda juda qiziq.
Va bu erda biz pg_stat_view yaratamiz.
Va biz qatorni birma-bir yangilaymiz. Va bu erda biz 724 ni ko'ramiz. Va keyin biz uchta qatorni yangilaymiz. Va endi bu erda nimani ko'ryapsiz? Bu so'rovlar, ya'ni siz chap ustunda ko'rsatilgan so'rovlarning to'liq ro'yxatini ko'rasiz. Va keyin o'ng tomonda siz blokirovkalarni va ular yaratadigan narsalarni ko'rishingiz mumkin. Va bu siz uchun yanada aniqroq bo'lishi mumkin, shunda siz har safar har bir sessiyaga qaytib, unga qo'shilish kerakmi yoki yo'qligini ko'rishingiz shart emas. Ular buni biz uchun qilishadi.
Juda foydali bo'lgan yana bir xususiyat pg_blocking_pids. Ehtimol, siz u haqida hech qachon eshitmagansiz. U nima ish qiladi? Bu 11740 seans uchun qanday aniq jarayon identifikatorlarini kutayotganini aytishga imkon beradi. Va siz 11740 724 ni kutayotganini ko'rishingiz mumkin. Va 724 eng tepada. Va 11306 sizning jarayon identifikatoringiz. Asosan, bu funksiya sizning qulflash stolingiz orqali o'tadi. Bilaman, bu biroz murakkab, lekin siz buni tushunishga muvaffaq bo'ldingiz. Asosan, bu funktsiya ushbu qulflash jadvalidan o'tadi va bu jarayon identifikatoriga u kutayotgan qulflar qayerda berilganligini topishga harakat qiladi. Shuningdek, u qulfni kutayotgan jarayon qaysi jarayon identifikatoriga ega ekanligini aniqlashga harakat qiladi. Shunday qilib, siz ushbu funktsiyani ishga tushirishingiz mumkin pg_blocking_pids.
Va bu juda foydali bo'lishi mumkin. Biz buni faqat 9.6 versiyasida qo'shdik, shuning uchun bu xususiyat faqat 5 yoshda, lekin u juda va juda foydali. Va xuddi shu narsa ikkinchi so'rov uchun ham amal qiladi. Bu biz ko'rishimiz kerak bo'lgan narsani aniq ko'rsatadi.
Men siz bilan gaplashmoqchi bo'lgan narsam shu edi. Va men kutganimdek, slaydlar juda ko'p bo'lgani uchun biz hamma vaqtimizni sarfladik. Va slaydlar yuklab olish uchun mavjud. Bu erda bo'lganingiz uchun sizga rahmat aytmoqchiman. Ishonchim komilki, konferentsiyaning qolgan qismi sizga yoqadi, katta rahmat!
Savollar:
Misol uchun, agar men qatorlarni yangilamoqchi bo'lsam va ikkinchi seans butun jadvalni o'chirishga harakat qilsa. Men tushunganimdek, niyat qulfiga o'xshash narsa bo'lishi kerak. Postgresda shunday narsa bormi?
Keling, eng boshiga qaytaylik. Esingizda bo'lishi mumkinki, biror narsa qilganingizda, masalan, SELECTni amalga oshirganingizda, biz AccessShareLock-ni chiqaramiz. Va bu stol tushishiga yo'l qo'ymaydi. Agar siz, masalan, jadvaldagi satrni yangilamoqchi bo'lsangiz yoki qatorni o'chirmoqchi bo'lsangiz, kimdir bir vaqtning o'zida butun jadvalni o'chira olmaydi, chunki siz ushbu AccessShareLock-ni butun jadval va qator ustida ushlab turasiz. Va tugatganingizdan so'ng, ular uni o'chirib tashlashi mumkin. Ammo siz u erda biror narsani to'g'ridan-to'g'ri o'zgartirsangiz, ular buni qila olmaydi.
Keling, yana qilaylik. Keling, o'chirish misoliga o'tamiz. Va siz butun stol ustidagi qatorda qanday qilib eksklyuziv qulf borligini ko'rasiz.
Bu eksklyuziv qulf kabi ko'rinadi, to'g'rimi?
Ha, shunday ko'rinadi. Men nima haqida gapirayotganingizni tushunaman. Siz aytmoqchisizki, agar men SELECT qilsam, menda ShareExclusive bor va keyin uni Row Exclusive qilaman, bu muammoga aylanadimi? Ammo ajablanarlisi shundaki, bu muammo tug'dirmaydi. Bu qulflash darajasini oshirishga o'xshaydi, lekin aslida menda o'chirishni oldini oladigan qulf bor. Va endi, men bu qulfni yanada kuchliroq qilsam, u hali ham o'chirishni oldini oladi. Demak, men yuqoriga ko'tarilmayman. Ya'ni, u pastroq darajada bo'lganida ham sodir bo'lishining oldini oldi, shuning uchun men uning darajasini ko'targanimda, u hali ham jadvalni o'chirishga to'sqinlik qiladi.
Men nima haqida gapirayotganingizni tushunaman. Bu erda qulfni kuchaytirish holati yo'q, bu erda siz kuchliroqni kiritish uchun bitta qulfdan voz kechmoqchisiz. Bu erda u faqat kengash bo'ylab bu oldinini oshiradi, shuning uchun u hech qanday ziddiyatga olib kelmaydi. Lekin bu yaxshi savol. Buni so'raganingiz uchun katta rahmat!
Ko'p seanslar, ko'p sonli foydalanuvchilar bo'lsa, boshi berk ko'chaga tushib qolmaslik uchun nima qilishimiz kerak?
Postgres o'lik holatlarni avtomatik ravishda sezadi. Va u avtomatik ravishda seanslardan birini o'chiradi. O'lik blokirovkadan qochishning yagona yo'li odamlarni bir xil tartibda blokirovka qilishdir. Shunday qilib, arizangizni ko'rib chiqsangiz, ko'pincha blokirovkalar sababi ... Tasavvur qilaylik, men ikki xil narsani bloklamoqchiman. Bitta ilova 1-jadvalni, ikkinchisi esa 2-jadvalni, keyin esa 1-jadvalni bloklaydi. Oʻyin-kulgidan qochishning eng oson yoʻli ilovangizni koʻrib chiqish va qulflash barcha ilovalarda bir xil tartibda sodir boʻlishiga ishonch hosil qilishga harakat qilishdir. Va bu odatda muammolarning 80 foizini yo'q qiladi, chunki bu ilovalarni har xil turdagi odamlar yozadilar. Va agar siz ularni bir xil tartibda to'sib qo'ysangiz, siz boshi berk ko'chaga duch kelmaysiz.
Sizning ijroingiz uchun katta rahmat! Siz to'liq vakuum haqida gapirdingiz va agar men to'g'ri tushunsam, vakuum to'liq alohida saqlashdagi yozuvlar tartibini buzadi, shuning uchun ular joriy yozuvlarni o'zgarishsiz saqlaydi. Nima uchun vakuum to'liq eksklyuziv blokirovkaga kirish huquqini oladi va nima uchun u yozish operatsiyalariga zid keladi?
Bu yaxshi savol. Sababi, vakuum to'la stolni oladi. Va biz aslida jadvalning yangi versiyasini yaratmoqdamiz. Va stol yangi bo'ladi. Ma'lum bo'lishicha, bu jadvalning mutlaqo yangi versiyasi bo'ladi. Muammo shundaki, biz buni qilganimizda, odamlar uni o'qishini xohlamaymiz, chunki bizga yangi jadvalni ko'rishlari kerak. Va shuning uchun bu avvalgi savolga bog'lanadi. Agar biz bir vaqtning o‘zida o‘qiy olsak, uni ko‘chirib, odamlarni yangi stolga yo‘naltira olmas edik. Biz hamma ushbu jadvalni o'qishni tugatguncha kutishimiz kerak, shuning uchun bu aslida qulflangan eksklyuziv holat.
Biz boshidanoq qulflaymiz, deymiz, chunki bilamizki, oxirida hammani yangi nusxaga o'tkazish uchun eksklyuziv qulf kerak bo'ladi. Shunday qilib, biz buni potentsial ravishda hal qila olamiz. Va biz buni bir vaqtning o'zida indeksatsiya qilish bilan qilamiz. Ammo buni qilish ancha qiyin. Va bu sizning oldingi savolingizga eksklyuziv qulf bilan bog'liq.
Postgres-ga blokirovka qilish vaqtini qo'shish mumkinmi? Oracle'da men, masalan, "yangilash uchun tanlang" deb yozishim va yangilashdan oldin 50 soniya kutishim mumkin. Bu dastur uchun yaxshi bo'ldi. Ammo Postgresda men buni darhol qilishim kerak va umuman kutmasligim kerak yoki biroz vaqt kutishim kerak.
Ha, siz qulflaringizda, qulflaringizda taym-autni tanlashingiz mumkin. Shuningdek, siz qulfni darhol qo'lga kirita olmasangiz, hech qanday yo'l qo'ymaslik buyrug'ini ham berishingiz mumkin. Shuning uchun, qulflash vaqti tugashi yoki buni amalga oshirishga imkon beradigan boshqa narsa. Bu sintaktik darajada bajarilmaydi. Bu serverda o'zgaruvchi sifatida amalga oshiriladi. Ba'zan buni ishlatib bo'lmaydi.
75-slaydni ocha olasizmi?
Ha.
Va mening savolim quyidagicha. Nima uchun ikkala yangilash jarayoni ham 703 ni kutmoqda?
Va bu ajoyib savol. Aytgancha, Postgres nima uchun bunday qilishini tushunmayapman. Ammo 703 yaratilganda, u 702 ni kutayotgan edi. 704 va 705 paydo bo'lganda, ular nima kutishayotganini bilishmaganga o'xshaydi, chunki u erda hali hech narsa yo'q. Va Postgres buni shunday qiladi: siz qulfni ololmasangiz, u "Sizni qayta ishlashdan nima foyda?" Deb yozadi, chunki siz allaqachon kimnidir kutmoqdasiz. Shunday qilib, biz uni havoda osib qo'yishga ruxsat beramiz, u umuman yangilamaydi. Lekin bu erda nima bo'ldi? 702 jarayonni tugatgandan so'ng va 703 o'z qulfini olishi bilan tizim orqaga qaytdi. Va uning aytishicha, hozir bizda ikki kishi kutmoqda. Va keyin ularni birgalikda yangilaymiz. Keling, ikkalasi ham kutayotganini aytaylik.
Postgres nima uchun buni qilayotganini bilmayman. Lekin f... deb nomlangan muammo bor. Menimcha, bu rus tilidagi atama emas. Bu qasrni kutayotgan 20 ta hokimiyat bo'lsa ham, hamma bitta qal'ani kutmoqda. Va birdan ularning hammasi bir vaqtning o'zida uyg'onadi. Va hamma javob berishga harakat qila boshlaydi. Ammo tizim shunday qiladiki, hamma 703 ni kutmoqda. Chunki ularning hammasi kutmoqda va biz ularni darhol qatorga qo'yamiz. Va agar bundan keyin yaratilgan boshqa yangi so'rov paydo bo'lsa, masalan, 707, yana bo'shlik paydo bo'ladi.
Va bu menimcha, bu bosqichda 702 703 ni kutayotganini aytishimiz uchun qilingandek tuyuladi va undan keyin kelganlarning hammasi bu sohaga kirishmaydi. Ammo birinchi ofitsiant ketishi bilanoq, o'sha paytda yangilanishni kutganlarning barchasi bir xil tokenni olishadi. Va shuning uchun menimcha, bu biz ularni to'g'ri tartibga solishimiz uchun tartibda ishlov berishimiz uchun qilingan.
Men buni har doim juda g'alati hodisa sifatida qarardim. Chunki bu erda, masalan, biz ularni umuman sanab o'tmaymiz. Ammo menimcha, biz har safar yangi qulf berganimizda, biz kutish jarayonida bo'lganlarning barchasiga qaraymiz. Keyin ularning barchasini bir qatorga qo'yamiz. Va keyin kelgan har qanday yangi faqat keyingi shaxs ishlov berishni tugatgandan keyingina navbatga tushadi. Juda yaxshi savol. Savolingiz uchun katta rahmat!
Menimcha, 705 704 ni kutsa, bu ancha mantiqiyroq.
Ammo bu erda muammo quyidagicha. Texnik jihatdan, siz bir yoki boshqasini uyg'otishingiz mumkin. Shunday qilib, biz birini yoki boshqasini uyg'otamiz. Ammo tizimda nima sodir bo'ladi? Yuqoridagi 703 o'z tranzaksiya identifikatorini qanday bloklaganini ko'rishingiz mumkin. Postgres shunday ishlaydi. Va 703 o'z tranzaksiya identifikatori bilan bloklangan, shuning uchun kimdir kutishni xohlasa, ular 703 ni kutishadi. Va, aslida, 703 tugaydi. Va faqat u tugaganidan keyin jarayonlardan biri uyg'onadi. Va biz bu jarayonning aniq nima bo'lishini bilmaymiz. Keyin hamma narsani asta-sekin qayta ishlaymiz. Ammo qaysi jarayon birinchi bo'lib uyg'onishi aniq emas, chunki bu jarayonlarning har biri bo'lishi mumkin. Aslini olganda, bizda ushbu jarayonlarning istalganini uyg'otishimiz mumkinligini aytadigan rejalashtiruvchimiz bor edi. Biz tasodifiy birini tanlaymiz. Shuning uchun ikkalasini ham qayd etish kerak, chunki biz ulardan birini uyg'otishimiz mumkin.
Va muammo shundaki, bizda CP-infinity mavjud. Va shuning uchun biz keyingisini uyg'otishimiz mumkin. Va agar, masalan, biz keyingisini uyg'otadigan bo'lsak, biz blokni hozirgina olganni kutamiz, shuning uchun kim birinchi bo'lib uyg'onishini aniqlay olmaymiz. Biz shunchaki shunday vaziyatni yaratamiz va tizim ularni tasodifiy tartibda uyg'otadi.
bor . Qarang, ular ham qiziqarli va foydali. Mavzu, albatta, juda murakkab. Katta rahmat, Bryus!
Manba: www.habr.com