Брюс Момжианы 2020 онд "Postgres Lock Manager-ийн түгжээг тайлах нь" илтгэлийн транскрипт.
(Тэмдэглэл: Слайд дээрх бүх SQL асуулгыг энэ холбоосоос авах боломжтой: )
Сайн уу? Орост дахин ирсэнд үнэхээр сайхан байна. Өнгөрсөн жил ирж чадаагүйдээ харамсаж байна, гэхдээ энэ жил Иван бид хоёр маш том төлөвлөгөөтэй байгаа. Би энд илүү олон удаа байх болно гэж найдаж байна. Би Орост ирэх дуртай. Би Тверь, Тюмень хотод очно. Эдгээр хотуудаар зочлох боломжтой болсондоо маш их баяртай байна.
Намайг Брюс Момжиан гэдэг. Би EnterpriseDB-д ажилладаг бөгөөд Postgres-тэй 23 гаруй жил хамтран ажиллаж байна. Би АНУ-ын Филадельфи хотод амьдардаг. Би жилийн 90 орчим өдөр аялдаг. Тэгээд би 40 орчим хуралд оролцдог. миний , миний одоо танд үзүүлэх слайдуудыг агуулсан. Тиймээс, хурлын дараа та тэдгээрийг миний хувийн вэбсайтаас татаж авах боломжтой. Мөн 30 орчим илтгэлийг багтаасан болно. Мөн видео бичлэгүүд, олон тооны блог оруулгууд байдаг, 500 гаруй. Энэ бол нэлээд мэдээллийн эх сурвалж юм. Хэрэв та энэ материалыг сонирхож байгаа бол үүнийг ашиглахыг урьж байна.
Би Postgres-тэй ажиллахаасаа өмнө багш, профессор байсан. Тэгээд одоо та нарт хэлэх гэж байгаа зүйлээ хэлэх боломжтой болсондоо маш их баяртай байна. Энэ бол миний хамгийн сонирхолтой илтгэлүүдийн нэг юм. Энэхүү танилцуулгад 110 слайд багтсан болно. Бид энгийн зүйлээр ярьж эхлэх бөгөөд эцэст нь тайлан улам бүр төвөгтэй болж, нэлээд төвөгтэй болно.
Энэ бол нэлээд тааламжгүй яриа юм. Блоклох нь хамгийн алдартай сэдэв биш юм. Бид үүнийг хаа нэгтээ алга болгомоор байна. Шүдний эмч рүү явж байгаа юм шиг.
- Түгжих нь мэдээллийн санд ажилладаг, олон процесс нэгэн зэрэг ажилладаг олон хүмүүст тулгардаг асуудал юм. Тэд хаах хэрэгтэй. Өөрөөр хэлбэл, өнөөдөр би танд блоклох талаар анхан шатны мэдлэг өгөх болно.
- Гүйлгээний ID. Энэ бол илтгэлийн нэлээд уйтгартай хэсэг боловч тэдгээрийг ойлгох хэрэгтэй.
- Дараа нь бид блоклох төрлүүдийн талаар ярих болно. Энэ бол нэлээд механик хэсэг юм.
- Мөн доор бид блоклох зарим жишээг өгөх болно. Мөн ойлгоход нэлээд хэцүү байх болно.
Блоклох талаар ярилцъя.
Манай нэр томъёо нэлээд төвөгтэй. Энэ хэсэг хаанаас гарсныг та нарын хэд нь мэдэх вэ? Хоёр хүн. Энэ бол "Colossal Cave Adventure" нэртэй тоглоом юм. Энэ бол 80-аад оны үед текст дээр суурилсан компьютер тоглоом байсан гэж би бодож байна. Тэнд та агуй руу, лабиринт руу орох хэрэгтэй болж, текст өөрчлөгдсөн боловч агуулга нь ойролцоогоор ижил байсан. Би энэ тоглолтыг ингэж санаж байна.
Энд бид Oracle-аас бидэнд ирсэн цоожны нэрийг харж байна. Бид тэдгээрийг ашигладаг.
Эндээс бид намайг төөрөлдүүлж буй нэр томъёог харж байна. Жишээлбэл, SHARE UPDATE ECXLUSIVE. Дараагийн ТҮҮХИЙГ ХУВААЛЦАХ ЭКСПЛЮСИВ. Үнэнийг хэлэхэд эдгээр нэр тийм ч тодорхой биш байна. Бид тэдгээрийг илүү нарийвчлан авч үзэхийг хичээх болно. Зарим нь салгах гэсэн утгатай “хуваалцах” гэдэг үгийг агуулдаг. Зарим нь "онцгой" гэсэн үгийг агуулдаг. Зарим нь энэ хоёр үгийг агуулдаг. Би эдгээр түгжээ хэрхэн ажилладаг талаар эхэлмээр байна.
"Хандалт" гэдэг үг бас маш чухал юм. Мөн "мөр" гэсэн үгс нь мөр юм. Энэ нь хандалтын хуваарилалт, эгнээний хуваарилалт юм.
Postgres-д ойлгох ёстой өөр нэг асуудал бол харамсалтай нь миний ярианд тусгаж чадахгүй байгаа нь MVCC юм. Би вэбсайт дээрээ энэ сэдвээр тусдаа илтгэл тавьсан. Хэрэв та энэ танилцуулгыг хэцүү гэж бодож байгаа бол MVCC магадгүй миний хамгийн хэцүү байх болно. Хэрэв та сонирхож байвал вэбсайтаас үзэх боломжтой. Та видеог үзэж болно.
Бидний ойлгох ёстой өөр нэг зүйл бол гүйлгээний ID юм. Өвөрмөц танигчгүйгээр олон гүйлгээ ажиллах боломжгүй. Энд бид гүйлгээ гэж юу болох талаар тайлбартай байна. Postgres нь гүйлгээний дугаарлах хоёр системтэй. Энэ тийм ч сайхан шийдэл биш гэдгийг би мэднэ.
Мөн слайдыг ойлгоход нэлээд хэцүү байх болно гэдгийг санаарай, тиймээс улаанаар тодорсон зүйл нь таны анхаарах ёстой зүйл юм.
Харцгаая. Гүйлгээний дугаарыг улаанаар тодруулсан. SELECT pg_back функцийг энд харуулав. Энэ нь миний гүйлгээ болон гүйлгээний ID-г буцааж өгдөг.
Бас нэг зүйл хэлэхэд, хэрэв танд энэ танилцуулга таалагдаж, өөрийн мэдээллийн сан дээрээ ажиллуулахыг хүсвэл ягаан өнгийн энэ линкээр орж энэхүү үзүүлэнгийн SQL-г татаж авах боломжтой. Та үүнийг зүгээр л PSQL дээрээ ажиллуулж болох бөгөөд үзүүлэнг бүхэлд нь шууд дэлгэцэн дээр харуулах болно. Энэ нь цэцэг агуулаагүй, гэхдээ ядаж бид үүнийг харж болно.
Энэ тохиолдолд бид гүйлгээний ID-г харна. Энэ бол бидний түүнд өгсөн дугаар юм. Postgres-д өөр төрлийн гүйлгээний ID байдаг бөгөөд үүнийг виртуал гүйлгээний ID гэж нэрлэдэг
Мөн бид үүнийг ойлгох ёстой. Энэ нь маш чухал, эс тэгвээс бид Postgres-д түгжигдэхийг ойлгох боломжгүй болно.
Виртуал гүйлгээний ID нь байнгын утгыг агуулаагүй гүйлгээний ID юм. Жишээлбэл, хэрэв би SELECT командыг ажиллуулбал мэдээллийн баазыг өөрчлөхгүй, юу ч түгжихгүй байх магадлалтай. Тиймээс бид энгийн SELECT-ийг ажиллуулахдаа тэр гүйлгээнд байнгын ID өгдөггүй. Бид түүнд зөвхөн виртуал үнэмлэх өгдөг.
Энэ нь Postgres-ийн гүйцэтгэлийг сайжруулж, цэвэрлэх чадварыг сайжруулдаг тул виртуал гүйлгээний ID нь хоёр тооноос бүрдэнэ. Ташуу зураасны өмнөх эхний тоо нь арын дугаар юм. Баруун талд нь бид зүгээр л тоолуурыг харж байна.
Тиймээс, хэрэв би хүсэлтийг ажиллуулах юм бол энэ нь backend ID нь 2 гэсэн байна.
Хэрэв би хэд хэдэн ийм гүйлгээ хийвэл би асуулга явуулах бүрт тоолуур нэмэгдэж байгааг бид харж байна. Жишээлбэл, би 2/10, 2/11, 2/12 гэх мэт асуулга ажиллуулах үед.
Энд хоёр багана байгаа гэдгийг санаарай. Зүүн талд бид виртуал гүйлгээний ID-г харж байна – 2/12. Мөн баруун талд бид байнгын гүйлгээний ID байна. Мөн энэ талбар хоосон байна. Мөн энэ гүйлгээ нь мэдээллийн санг өөрчлөхгүй. Тиймээс би түүнд байнгын гүйлгээний ID өгдөггүй.
Би анализ хийх командыг ((ANALYZE)) ажиллуулангуут ижил асуулга надад байнгын гүйлгээний ID өгдөг. Энэ нь бидний хувьд хэрхэн өөрчлөгдсөнийг хараарай. Би өмнө нь энэ үнэмлэхгүй байсан, гэхдээ одоо надад байгаа.
Ингээд дахиад нэг хүсэлт, өөр нэг гүйлгээ байна. Виртуал гүйлгээний дугаар нь 2/13 байна. Хэрэв би байнгын гүйлгээний ID-г асуувал асуулга явуулахад би үүнийг авах болно.
Тэгэхээр дахиад нэг удаа. Бидэнд виртуал гүйлгээний ID болон байнгын гүйлгээний ID байна. Postgres-ийн зан төлөвийг ойлгохын тулд энэ зүйлийг ойлгоход л хангалттай.
Бид гурав дахь хэсэг рүү шилжиж байна. Энд бид зүгээр л Postgres-ийн янз бүрийн төрлийн цоожуудыг үзэх болно. Энэ нь тийм ч сонирхолтой биш юм. Сүүлийн хэсэг нь илүү сонирхолтой байх болно. Гэхдээ бид үндсэн зүйлсийг авч үзэх ёстой, эс тэгвээс бид дараа нь юу болохыг ойлгохгүй байх болно.
Бид энэ хэсгийг үзэх болно, бид цоожны төрөл бүрийг авч үзэх болно. Би танд тэдгээрийг хэрхэн суулгаж, хэрхэн ажилладагийг жишээ болгон харуулах болно, Postgres дээр түгжих хэрхэн ажилладагийг харахын тулд ашиглаж болох зарим асуултуудыг танд үзүүлэх болно.
Асуулга үүсгэж, Postgres-д юу болж байгааг харахын тулд бид системийн харагдац дээр асуулга гаргах хэрэгтэй. Энэ тохиолдолд pg_lock улаанаар тодорсон байна. Pg_lock нь Postgres-д одоогоор ямар түгжээ ашиглагдаж байгааг хэлж өгдөг системийн хүснэгт юм.
Гэсэн хэдий ч, энэ нь нэлээд төвөгтэй тул pg_lock-ыг танд харуулах нь надад маш хэцүү байдаг. Тиймээс би pg_locks-г харуулсан харагдац үүсгэсэн. Мөн энэ нь надад илүү сайн ойлгох боломжийг олгодог зарим ажлыг гүйцэтгэдэг. Энэ нь миний түгжээ, миний өөрийн сесс гэх мэтийг оруулаагүй болно. Энэ бол зүгээр л стандарт SQL бөгөөд юу болж байгааг танд илүү сайн харуулах боломжийг олгодог.
Өөр нэг асуудал бол энэ үзэл бодол нь маш өргөн тул би хоёр дахь нь - lockview2 үүсгэх ёстой.
Мөн энэ нь надад хүснэгтээс илүү олон баганыг харуулж байна. Мөн үлдсэн багануудыг надад харуулсан өөр нэг. Энэ бол нэлээд төвөгтэй тул би үүнийг аль болох энгийн байдлаар танилцуулахыг хичээсэн.
Тиймээс бид Lockdemo нэртэй хүснэгт үүсгэсэн. Тэгээд бид тэнд нэг мөр үүсгэсэн. Энэ бол бидний жишээ хүснэгт юм. Мөн бид танд цоожны жишээг харуулахын тулд хэсэг үүсгэх болно.
Тэгэхээр нэг мөр, нэг багана. Эхний төрлийн түгжээг ACCESS SHARE гэж нэрлэдэг. Энэ бол хамгийн бага хязгаарлалттай хориг юм. Энэ нь бусад цоожтой бараг зөрчилддөггүй гэсэн үг юм.
Хэрэв бид түгжээг тодорхой тодорхойлохыг хүсвэл "түгжих хүснэгт" командыг ажиллуулна. Энэ нь мэдээж хаах болно, өөрөөр хэлбэл ACCESS SHARE горимд бид түгжих хүснэгтийг ажиллуулна. Хэрэв би PSQL-г далд ажиллуулж байгаа бол эхний сешнээсээ хоёр дахь сессийг ингэж эхлүүлнэ. Энэ нь би энд юу хийх вэ? Би өөр сесс рүү очоод "энэ хүсэлтийн түгжээг харуулах" гэж хэлнэ. Энд надад энэ хүснэгтэд AccessShareLock байна. Энэ бол яг миний хүсэлт байсан юм. Тэгээд блок томилогдсон гэж байна. Маш энгийн.
Цаашилбал, хэрэв бид хоёр дахь баганыг харвал тэнд юу ч байхгүй. Тэд хоосон байна.
Хэрэв би "SELECT" командыг ажиллуулбал, энэ нь 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 байгааг бид харж байна. Мөн энэ нь сонирхолтой юм. Энд юу болсон бэ? Эхний удаа бид "Түгжих" талбарт дугаарыг харж байна. Бид гүйлгээний ID-г авдаг бөгөөд энэ нь үүнийг онцгой горимд хааж байна гэж хэлдэг. Энэ нь надад хүснэгтийн хаа нэгтээ техникийн хувьд түгжигдсэн эгнээтэй байна гэсэн үг юм. Гэхдээ яг хаана гэдгийг нь хэлэхгүй байна. Бид үүнийг дараа нь илүү нарийвчлан авч үзэх болно.
Энд бид цоожыг манайд ашигладаг гэж хэлж байна.
Тиймээс онцгой цоож нь онцгой гэж тодорхой хэлдэг. Мөн хэрэв та энэ хүснэгтийн мөрийг устгавал таны харж байгаагаар ийм зүйл тохиолдох болно.
SHARE EXCLUSIVE бол илүү урт түгжээ юм.
Энэ бол ашиглагдах (ANALYZE) анализаторын команд юм.
SHARE LOCK – та хуваалцах горимд шууд түгжих боломжтой.
Та мөн өвөрмөц индекс үүсгэж болно. Мөн тэнд та тэдгээрийн нэг хэсэг болох SHARE LOCK-г харж болно. Тэгээд ширээгээ түгжиж, дээр нь SHARE LOCK тавьдаг.
Анхдагч байдлаар, SHARE LOCK нь хүснэгтийг бусад хүмүүс унших боломжтой боловч хэн ч үүнийг өөрчлөх боломжгүй гэсэн үг юм. Мөн та өвөрмөц индекс үүсгэх үед яг ийм зүйл тохиолддог.
Хэрэв би нэгэн зэрэг өвөрмөц индекс үүсгэвэл би өөр төрлийн түгжээтэй байх болно, учир нь таны санаж байгаагаар индексүүдийг зэрэгцүүлэн ашиглах нь түгжих хэрэгцээг бууруулдаг. Хэрэв би ердийн цоож, ердийн индекс ашигладаг бол хүснэгтийн индексийг үүсгэх үед бичихээс сэргийлнэ. Хэрэв би зэрэгцээ индекс ашигладаг бол өөр төрлийн түгжээг ашиглах шаардлагатай болно.
ROW EXCLUSIVE SHARE – дахин үүнийг тодорхой (тодорхойгоор) тохируулах боломжтой.
Эсвэл бид дүрэм үүсгэж болно, өөрөөр хэлбэл үүнийг ашиглах тодорхой тохиолдлыг авч болно.
ОНЦГОЙ түгжээ гэдэг нь өөр хэн ч ширээг өөрчлөх боломжгүй гэсэн үг.
Энд бид янз бүрийн төрлийн түгжээг харж байна.
Жишээлбэл, ACCESS EXCLUSIVE нь хаах команд юм. Жишээлбэл, хэрэв та үүнийг хийвэл CLUSTER table, тэгвэл энэ нь хэн ч тэнд бичих боломжгүй болно гэсэн үг юм. Мөн энэ нь зөвхөн хүснэгтийг өөрөө төдийгүй индексүүдийг түгждэг.
Энэ бол ACCESS EXCLUSIVE блоклох хоёр дахь хуудас бөгөөд бид яг юу блоклодогийг хүснэгтээс харж болно. Энэ нь бие даасан хүснэгтийн мөрүүдийг түгждэг бөгөөд энэ нь нэлээд сонирхолтой юм.
Энэ бол миний өгөхийг хүссэн бүх үндсэн мэдээлэл юм. Бид цоожны тухай, гүйлгээний ID-ийн тухай, виртуал гүйлгээний ID-ийн тухай, байнгын гүйлгээний ID-ийн тухай ярьсан.
Одоо бид хааж буй зарим жишээг авч үзэх болно. Энэ бол хамгийн сонирхолтой хэсэг юм. Бид маш сонирхолтой тохиолдлуудыг авч үзэх болно. Энэ илтгэлийн миний зорилго бол Postgres зарим зүйлийг хаахыг оролдох үед яг юу хийж байгааг илүү сайн ойлгох явдал юм. Би түүнийг хэсэг хэсгүүдийг хааж боохдоо маш сайн гэж бодож байна.
Зарим тодорхой жишээг авч үзье.
Бид хүснэгтүүд болон хүснэгтийн нэг эгнээнээс эхэлнэ. Би ямар нэг зүйл оруулахад ширээн дээр ExclusiveLock, Transaction ID болон ExclusiveLock гарч ирнэ.
Хэрэв би дахиад хоёр мөр оруулбал юу болох вэ? Одоо манай ширээ гурван эгнээтэй байна. Тэгээд би нэг мөр оруулаад үүнийг гаралт болгон авсан. Хэрэв би дахиад хоёр мөр оруулбал юу нь хачирхалтай вэ? Энд нэг хачирхалтай зүйл байна, учир нь би энэ хүснэгтэд гурван эгнээ нэмсэн боловч цоожны ширээн дээр хоёр эгнээ хэвээр байна. Энэ нь үндсэндээ Postgres-ийн үндсэн зан чанар юм.
Хэрэв та мэдээллийн санд 100 мөр түгжээд байвал 100 цоожны оруулга үүсгэх шаардлагатай гэж олон хүмүүс боддог. Хэрэв би 1 мөрийг нэг дор хаавал 000 ийм асуулга хэрэгтэй болно. Тэгээд би блоклох сая, тэрбум хэрэгтэй бол. Гэхдээ бид үүнийг хийвэл тийм ч сайн ажиллахгүй. Хэрэв та мөр бүрт блоклох оруулгууд үүсгэдэг систем ашигласан бол энэ нь төвөгтэй гэдгийг харж болно. Учир нь та халих боломжтой цоожны хүснэгтийг нэн даруй тодорхойлох хэрэгтэй, гэхдээ Postgres үүнийг хийдэггүй.
Мөн энэ слайдын хамгийн чухал зүйл бол MVCC дотор мөрүүдийг хаадаг өөр систем ажилладаг гэдгийг тодорхой харуулж байгаа явдал юм. Тиймээс та хэдэн тэрбум мөрийг түгжихэд Postgres тэрбум тусдаа түгжих команд үүсгэдэггүй. Мөн энэ нь бүтээмжид маш сайн нөлөө үзүүлдэг.
Шинэчлэлийн талаар юу хэлэх вэ? Би одоо мөрийг шинэчилж байгаа бөгөөд энэ нь нэгэн зэрэг хоёр өөр үйлдлийг гүйцэтгэсэн болохыг харж болно. Энэ нь ширээг нэгэн зэрэг түгжихээс гадна индексийг түгжсэн. Мөн энэ хүснэгтэд өвөрмөц хязгаарлалтууд байгаа тул тэр индексийг түгжих шаардлагатай болсон. Мөн бид үүнийг хэн ч өөрчлөхгүй байхыг хүсч байгаа тул үүнийг хааж байна.
Хэрэв би хоёр мөрийг шинэчлэхийг хүсвэл яах вэ? Тэгээд ч тэр адилхан зан гаргаж байгааг бид харж байна. Бид хоёр дахин олон шинэчлэлт хийдэг, гэхдээ яг ижил тооны цоожны шугамууд.
Хэрэв та Postgres үүнийг хэрхэн хийдэг бол гэж гайхаж байгаа бол Postgres эдгээр мөрүүдийг хэрхэн өөрчлөхийг дотооддоо хэрхэн тэмдэглэж байгааг мэдэхийн тулд MVCC дээрх миний яриаг сонсох хэрэгтэй болно. Postgres-д үүнийг хийх арга байдаг, гэхдээ энэ нь үүнийг хүснэгтийн түгжээний түвшинд хийдэггүй, энэ нь үүнийг доод, илүү үр дүнтэй түвшинд хийдэг.
Хэрэв би ямар нэг зүйлийг устгахыг хүсвэл яах вэ? Жишээлбэл, би нэг мөрийг устгаад, би хоёр блоклох оролттой хэвээр байгаа бөгөөд бүгдийг нь устгахыг хүссэн ч тэдгээр нь хэвээр байна.
Жишээлбэл, би 1 мөр оруулахыг хүсч, дараа нь 000 мөрийг устгах эсвэл нэмэхийг хүсч байна, дараа нь миний нэмсэн эсвэл өөрчилсөн мөрүүдийг энд бүртгэдэггүй. Тэдгээр нь цуврал дотроо доод түвшинд бичигдсэн байдаг. MVCC-ийн илтгэлийн үеэр би энэ талаар дэлгэрэнгүй ярьсан. Гэхдээ та түгжээг шинжлэхдээ хүснэгтийн түвшинд түгжиж байгаа эсэх, мөн тус тусын мөрүүдийг энд хэрхэн бүртгэж байгааг харахгүй байгаа эсэхийг шалгах нь маш чухал юм.
Тодорхой блоклох талаар юу хэлэх вэ?
Хэрэв би "refresh" дээр дарвал хоёр мөр түгжигдсэн байна. Хэрэв би бүгдийг нь сонгоод "хаа сайгүй шинэчлэх" дээр дарвал надад блоклох хоёр бичлэг байна.
Бид мөр бүрт тусдаа бүртгэл үүсгэдэггүй. Учир нь дараа нь бүтээмж буурч, энэ нь хэтэрхий их байх болно. Мөн бид таагүй нөхцөл байдалд орж магадгүй юм.
Мөн ижил зүйл, хэрэв бид хуваалцвал бид бүгдийг 30 удаа хийж чадна.
Бид хүснэгтээ сэргээж, бүгдийг устгаад дараа нь дахин нэг мөр оруулна.
Postgres-ээс олж хардаг өөр нэг зан чанар нь маш сайн мэддэг, хүсч буй зан чанар юм, та шинэчлэлт хийх эсвэл сонгох боломжтой. Мөн та үүнийг нэгэн зэрэг хийж болно. Мөн сонгох нь шинэчлэлтийг хориглодоггүй бөгөөд эсрэг чиглэлд ижил зүйл байдаг. Бид уншигчдад зохиолчийг битгий хаагаарай гэж хэлдэг, зохиолч нь уншигчийг хаагаагүй.
Би танд үүний жишээг үзүүлье. Би одоо сонголт хийх болно. Дараа нь бид INSERT хийх болно. Дараа нь та харж болно - 694. Та энэ оруулгыг гүйцэтгэсэн гүйлгээний ID-г харж болно. Тэгээд л ингэж ажилладаг.
Хэрэв би одоо өөрийн ID дугаараа харвал одоо 695 байна.
Миний хүснэгтэд 695 гарч ирэхийг би харж байна.
Хэрэв би энд ингээд шинэчлэгдэх юм бол өөр хэрэг гарч ирнэ. Энэ тохиолдолд 695 нь онцгой түгжээ бөгөөд шинэчлэлт нь ижил үйлдэлтэй боловч тэдгээрийн хооронд зөрчилдөөн байхгүй бөгөөд энэ нь ер бусын юм.
Дээд талд нь ShareLock, доод талд нь ExclusiveLock байгааг харж болно. Мөн хоёр гүйлгээ амжилттай болсон.
Энэ нь яаж болдгийг ойлгохын тулд та MVCC дээр миний яриаг сонсох хэрэгтэй. Гэхдээ энэ бол та нэгэн зэрэг хийж болох жишээ юм, өөрөөр хэлбэл СОНГОХ болон ШИНЭЧЛЭЛТ-ийг нэгэн зэрэг хийж болно.
Дахин тохируулаад дахиад нэг үйлдэл хийцгээе.
Хэрэв та нэг мөрөнд хоёр шинэчлэлтийг зэрэг ажиллуулахыг оролдвол энэ нь хаагдах болно. Уншигч зохиолчоо хаадаггүй, зохиолч нь уншигчаа хаадаггүй, харин нэг зохиолч нөгөө зохиолчоо хаадаг гэж би хэлснийг санаарай. Өөрөөр хэлбэл, бид хоёр хүн нэг мөрийг нэгэн зэрэг шинэчлэх боломжгүй. Та тэдгээрийн аль нэг нь дуусах хүртэл хүлээх хэрэгтэй.
Үүнийг харуулахын тулд би Lockdemo хүснэгтийг харъя. Тэгээд бид нэг мөрийг харна. Гүйлгээ бүрт 698.
Бид үүнийг 2 болгож шинэчилсэн. 699 бол анхны шинэчлэлт юм. Энэ нь амжилттай болсон эсвэл хүлээгдэж буй гүйлгээнд байгаа бөгөөд биднийг баталгаажуулах эсвэл цуцлахыг хүлээж байна.
Гэхдээ өөр зүйлийг хараарай - 2/51 бол бидний анхны гүйлгээ, бидний анхны сесс. 3/112 нь дээрээс ирсэн хоёр дахь хүсэлт бөгөөд энэ утгыг 3 болгож өөрчилсөн. Хэрэв та анзаарсан бол дээд нь өөрөө түгжигдсэн бөгөөд энэ нь 699. Гэвч 3/112 нь түгжээг өгөөгүй. Lock_mode багана нь юу хүлээж байгааг хэлдэг. Энэ нь 699-ийг хүлээж байна. Хэрэв та 699 хаана байгааг харвал энэ нь илүү өндөр байна. Тэгээд эхний хуралдаан юу хийсэн бэ? Тэрээр өөрийн гүйлгээний ID дээр онцгой цоож бүтээжээ. Postgres үүнийг ингэж хийдэг. Энэ нь өөрийн гүйлгээний ID-г блоклодог. Хэрэв та хэн нэгнийг баталгаажуулах эсвэл цуцлахыг хүлээхийг хүсвэл хүлээгдэж буй гүйлгээ байгаа үед хүлээх хэрэгтэй. Тийм ч учраас бид хачирхалтай зураасыг харж болно.
Дахин харцгаая. Зүүн талд бид боловсруулах ID-г харж байна. Хоёрдахь баганад бид виртуал гүйлгээний ID-г, гурав дахь хэсэгт бид lock_type-г харна. Энэ юу гэсэн үг вэ? Үндсэндээ энэ нь гүйлгээний ID-г хааж байна гэсэн үг юм. Гэхдээ доод талд байгаа бүх мөр нь хамаарлыг хэлж байгааг анхаарна уу. Тиймээс та ширээн дээр хоёр төрлийн цоожтой байна. Харилцааны түгжээ байдаг. Тэгээд дараа нь та өөрөө блоклодог транзаксид блок байгаа бөгөөд энэ нь яг эхний мөрөнд эсвэл хамгийн доод хэсэгт тохиолддог, транзакцид байгаа газар, бид 699-ийн ажиллагааг дуусгахыг хүлээж байдаг.
Би энд юу болохыг харъя. Мөн энд хоёр зүйл зэрэг тохиолддог. Та эхний эгнээнд байгаа гүйлгээний ID түгжээг харж байна. Тэгээд тэр хүмүүсийг хүлээхийн тулд өөрийгөө блоклодог.
Хэрэв та 6-р мөрийг харвал эхнийхтэй ижил оруулгатай байна. Тиймээс 699 гүйлгээ хаагдсан байна. 700 нь мөн өөрөө түгжигддэг. Дараа нь доод эгнээнд та бид 699-ийн ажиллагааг дуусгахыг хүлээж байгааг харах болно.
Мөн lock_type, tuple-д тоо харагдана.
Энэ нь 0/10 байгааг харж болно. Энэ бол хуудасны дугаар, мөн энэ мөрийн офсет юм.
Биднийг шинэчлэх үед 0/11 болж байгааг та харж байна.
Гэвч бодит байдал дээр энэ нь 0/10, учир нь энэ үйлдлийг хүлээх хугацаа байгаа юм. Энэ бол миний батлахыг хүлээж байгаа цуврал гэдгийг харах боломж бидэнд байна.
Бид үүнийг баталгаажуулж, "commit" дээр дарж, шинэчлэлт дууссаны дараа бид үүнийг дахин авах болно. Гүйлгээ 700 нь цорын ганц цоож, хийсэн учраас өөр хэнийг ч хүлээхгүй. Энэ нь зүгээр л гүйлгээ дуусахыг хүлээх болно. Нэгэнт 699 дуусвал бид дахиж юу ч хүлээхгүй. Одоо гүйлгээ 700-д бүх зүйл хэвийн, зөвшөөрөгдсөн бүх хүснэгтэд шаардлагатай бүх түгжээ байгаа гэж хэлсэн.
Энэ бүх зүйлийг илүү төвөгтэй болгохын тулд бид өөр нэг үзэл бодлыг бий болгож, энэ удаад шатлалыг өгөх болно. Таныг энэ хүсэлтийг ойлгоно гэж бодохгүй байна. Гэхдээ энэ нь бидэнд юу болж байгааг илүү тодорхой харах боломжийг олгоно.
Энэ бол өөр хэсэгтэй рекурсив харагдац юм. Тэгээд бүх зүйлийг дахин нэгтгэдэг. Үүнийг ашиглацгаая.
Гурван шинэчлэлтийг зэрэг хийчихээд мөр гурав болчихлоо гээд хэлчихвэл яана. Тэгээд бид 3-ыг 4 болгон өөрчлөх болно.
Энд бид 4. Мөн гүйлгээний ID 702-г харж байна.
Тэгээд би 4-ийг 5 болгож, 5-ыг 6, 6-г 7 болгож өөрчилнө. Тэгээд би энэ нэг гүйлгээ дуусахыг хүлээж байгаа хэдэн хүнийг жагсаана.
Тэгээд бүх зүйл тодорхой болно. Эхний эгнээ юу вэ? Энэ бол 702. Энэ нь анх энэ утгыг тохируулсан гүйлгээний ID юм. Миний олгосон баганад юу бичсэн бэ? Надад тэмдэг байна 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 процессоор хаагдсан SHARE LOCK-ийг хүлээж байгаа нь тодорхой байна. Тэгээд тэр процесс ийм ийм гүйлгээний ID дээр 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 байна.
Хэрэв бид цэгийг хадгалаад дараа нь шинэчлэх юм бол бид шинэ гүйлгээний ID авах болно. Энэ бол таны мэдэж байх ёстой зан үйлийн өөр нэг загвар юм. Хэрэв бид үүнийг буцаавал гүйлгээний ID алга болно. 724 навч. Харин одоо 725 болсон.
Тэгэхээр би энд юу хийх гээд байгаа юм бэ? Би танд ер бусын цоожны жишээг харуулахыг хичээж байна: энэ нь цуваа цоож эсвэл SAVEPOINT аль нь ч бай, цоожны хүснэгтэд харагдах өөр өөр төрлийн түгжээнүүд юм.
Энэ нь pg_advisory_lock-той ил тод (тодорхой) түгжээ үүсгэх явдал юм.
Мөн та блоклох төрлийг зөвлөмж болгон жагсаасан байгааг харж байна. Энд улаанаар "зөвлөгөө" гэж бичсэн байна. Мөн та pg_advisory_unlock ашиглан нэгэн зэрэг блоклож болно.
Эцэст нь хэлэхэд би танд бас нэг сэтгэл хөдөлгөм зүйлийг харуулахыг хүсч байна. Би өөр харагдац үүсгэх болно. Гэхдээ би pg_locks хүснэгтэд pg_stat_activity хүснэгттэй нэгдэх болно. Тэгээд би яагаад үүнийг хийхийг хүсч байна вэ? Учир нь энэ нь надад одоо байгаа бүх сессүүдийг харж, харж, яг ямар төрлийн түгжээ хүлээж байгааг харах боломжийг олгоно. Бид цоожны хүснэгт болон асуулгын хүснэгтийг нэгтгэх үед энэ нь маш сонирхолтой юм.
Энд бид pg_stat_view үүсгэдэг.
Мөн бид мөрийг нэг нэгээр нь шинэчилдэг. Энд бид 724-ийг харж байна. Дараа нь бид эгнээгээ гурав болгож шинэчилнэ. Тэгээд одоо энд юу харж байна вэ? Эдгээр нь хүсэлтүүд, өөрөөр хэлбэл та зүүн баганад жагсаасан хүсэлтийн жагсаалтыг бүхэлд нь харах болно. Дараа нь баруун талд та бөглөрөл, юу үүсгэж байгааг харж болно. Энэ нь танд илүү ойлгомжтой байх бөгөөд ингэснээр та сесс болгондоо буцаж очиж, үүнд хамрагдах шаардлагатай эсэхээ харах шаардлагагүй болно. Тэд бидний төлөө үүнийг хийдэг.
Өөр нэг маш ашигтай шинж чанар бол pg_blocking_pids. Та түүний тухай хэзээ ч сонсож байгаагүй байх. Тэр юу хийж байна? Энэ нь 11740 сессийн хувьд ямар тодорхой процессын ID-г хүлээж байгааг хэлэх боломжийг бидэнд олгодог. 11740 нь 724-ийг хүлээж байгааг харж болно. Мөн 724 хамгийн дээд талд байна. Мөн 11306 бол таны процессын ID юм. Үндсэндээ энэ функц нь таны түгжих хүснэгтээр дамждаг. Энэ нь жаахан төвөгтэй гэдгийг би мэднэ, гэхдээ та үүнийг ойлгож чадна. Үндсэндээ энэ функц нь энэ түгжээний хүснэгтээр дамжиж, энэ процессын ID-д хүлээгдэж буй түгжээг хаана өгөхийг олохыг оролддог. Мөн энэ нь түгжээг хүлээж буй процесс ямар процессын ID-тай болохыг олж мэдэхийг оролддог. Тиймээс та энэ функцийг ажиллуулж болно pg_blocking_pids.
Мөн энэ нь маш ашигтай байж болох юм. Бид үүнийг зөвхөн 9.6 хувилбар дээр нэмсэн тул энэ функц нь дөнгөж 5 жилийн настай боловч маш их хэрэгтэй. Хоёрдахь хүсэлтэд мөн адил хамаарна. Энэ нь бидэнд яг юу харах ёстойг харуулж байна.
Энэ бол би чамтай ярилцах гэсэн юм. Мөн миний таамаглаж байсанчлан маш олон слайд байсан тул бид бүх цагаа зарцуулсан. Мөн слайдуудыг татаж авах боломжтой. Энд байгаад баярлалаа гэж хэлмээр байна. Чуулганы үлдсэн хэсэг нь танд таалагдана гэдэгт итгэлтэй байна, маш их баярлалаа!
Асуулт:
Жишээлбэл, хэрэв би мөрүүдийг шинэчлэх гэж байгаа бол хоёр дахь сесс нь хүснэгтийг бүхэлд нь устгахыг оролдож байгаа бол. Миний ойлгож байгаагаар санааны цоож шиг зүйл байх ёстой. Postgres-д ийм зүйл байдаг уу?
Хамгийн эхэнд буцаж орцгооё. Та ямар нэгэн зүйл хийх үед, жишээ нь SELECT хийх үед бид AccessShareLock олгодог гэдгийг санаж байгаа байх. Мөн энэ нь ширээ унахаас сэргийлдэг. Жишээлбэл, хэрэв та хүснэгтийн мөрийг шинэчлэх эсвэл мөрийг устгахыг хүсвэл хэн нэгэн хүснэгтийг бүхэлд нь устгах боломжгүй, учир нь та энэ AccessShareLock-ийг бүх хүснэгт болон мөрийн дээгүүр барьж байгаа тул. Таныг дуусгасны дараа тэд үүнийг устгах боломжтой. Гэхдээ та тэнд ямар нэг зүйлийг шууд өөрчлөх боловч тэд үүнийг хийх боломжгүй болно.
Дахиад хийцгээе. Устгах жишээ рүү шилжье. Бүх хүснэгтийн дээрх эгнээнд онцгой түгжээ хэрхэн байгааг та харж байна.
Энэ нь онцгой түгжээ шиг харагдах болно, тийм үү?
Тийм ээ, энэ нь харагдаж байна. Юу яриад байгааг чинь ойлгож байна. Хэрэв би SELECT хийвэл ShareExclusive-тэй болж, дараа нь түүнийг Row Exclusive болговол энэ нь асуудал болж байна гэж та хэлж байна уу? Гэхдээ хачирхалтай нь энэ нь асуудал үүсгэдэггүй. Энэ нь түгжээний зэрэглэлийг нэмэгдүүлж байгаа мэт харагдаж байгаа ч үндсэндээ би устгахаас сэргийлдэг цоожтой. Одоо би энэ түгжээг илүү хүчирхэг болгоход энэ нь устгахаас сэргийлсэн хэвээр байна. Тэгэхээр би дээшээ гараад байгаа юм биш. Өөрөөр хэлбэл, энэ нь доод түвшинд байх үед тохиолдохоос сэргийлсэн тул би түвшинг нэмэгдүүлэхэд хүснэгтийг устгахаас сэргийлсэн хэвээр байна.
Юу яриад байгааг чинь ойлгож байна. Энд түгжээг нэмэгдүүлэх тохиолдол байхгүй бөгөөд та илүү хүчтэй түгжээг нэвтрүүлэхийн тулд нэг түгжээ өгөхийг оролдож байна. Энд энэ нь зөвхөн урьдчилан сэргийлэх ажлыг бүхэлд нь нэмэгдүүлдэг тул ямар ч зөрчил үүсгэхгүй. Гэхдээ сайхан асуулт байна. Үүнийг асуусанд маш их баярлалаа!
Бид олон сесс, олон тооны хэрэглэгчидтэй байхад гацсан нөхцөл байдлаас зайлсхийхийн тулд юу хийх хэрэгтэй вэ?
Postgres гацсан нөхцөл байдлыг автоматаар анзаардаг. Мөн энэ нь сешнүүдийн аль нэгийг автоматаар устгах болно. Үхсэн блокоос зайлсхийх цорын ганц арга бол хүмүүсийг ижил дарааллаар хаах явдал юм. Тиймээс таны өргөдлийг харахад ихэнхдээ гацах шалтгаан... Би хоёр өөр зүйлийг хаахыг хүсч байна гэж төсөөлөөд үз дээ. Нэг аппликешн 1-р хүснэгтийг түгжиж, өөр нэг программ 2-ыг, дараа нь хүснэгт 1-ийг түгждэг. Мөн түгжрэлээс зайлсхийх хамгийн хялбар арга бол програмаа харж, түгжээ нь бүх программ дээр ижил дарааллаар явагдаж байгаа эсэхийг шалгах явдал юм. Бүх төрлийн хүмүүс эдгээр програмуудыг бичдэг тул энэ нь ихэвчлэн асуудлын 80% -ийг арилгадаг. Хэрэв та тэдгээрийг ижил дарааллаар хаах юм бол гацах нөхцөл байдал үүсэхгүй.
Таны гүйцэтгэлд маш их баярлалаа! Та вакуум дүүрсэн тухай ярьсан бөгөөд хэрэв би зөв ойлговол вакуум бүрэн тусдаа хадгалалтанд байгаа бичлэгийн дарааллыг гажуудуулж байгаа тул одоогийн бүртгэлийг өөрчлөөгүй хадгалдаг. Vacuum full нь яагаад онцгой түгжээнд нэвтрэх эрхийг авдаг бөгөөд энэ нь яагаад бичих үйлдэлтэй зөрчилддөг вэ?
Сайхан асуулт байна. Учир нь вакуум нь ширээг эзэлдэг. Мөн бид үндсэндээ хүснэгтийн шинэ хувилбарыг үүсгэж байна. Мөн ширээ шинэ байх болно. Энэ нь хүснэгтийн цоо шинэ хувилбар болох нь харагдаж байна. Асуудал нь бид үүнийг хийхдээ хүмүүст шинэ хүснэгтийг харах хэрэгтэй учраас үүнийг уншихыг хүсэхгүй байгаа юм. Энэ нь өмнөх асуулттай холбогдож байна. Хэрэв бид нэгэн зэрэг уншиж чаддаг байсан бол бид үүнийг хөдөлгөж, хүмүүсийг шинэ хүснэгт рүү чиглүүлж чадахгүй байх байсан. Хүн бүр энэ хүснэгтийг уншиж дуусгахыг хүлээх хэрэгтэй бөгөөд энэ нь үндсэндээ цоожны онцгой нөхцөл байдал юм.
Бүгдийг шинэ хуулбар руу шилжүүлэхийн тулд эцсийн эцэст онцгой түгжээ хэрэгтэй болно гэдгийг бид мэдэж байгаа учраас бид эхнээс нь түгжиж байна гэж хэлдэг. Тиймээс бид үүнийг шийдэж чадна. Мөн бид үүнийг нэгэн зэрэг индексжүүлэх замаар хийдэг. Гэхдээ үүнийг хийхэд илүү хэцүү байдаг. Энэ нь таны өмнөх түгжээний тухай асуулттай маш их холбоотой юм.
Postgres дээр түгжих хугацаа нэмэх боломжтой юу? Жишээлбэл, Oracle дээр би "шинэлэхийн тулд сонгох" гэж бичиж, шинэчлэхээсээ өмнө 50 секунд хүлээх боломжтой. Энэ нь програмын хувьд сайн байсан. Гэхдээ Postgres-д би үүнийг нэн даруй хийх хэрэгтэй бөгөөд огт хүлээхгүй байх эсвэл хэсэг хугацаанд хүлээх хэрэгтэй.
Тийм ээ, та түгжээ, түгжээн дээрээ завсарлага сонгох боломжтой. Та мөн түгжээг шууд авч чадахгүй бол... ямар ч боломжгүй гэсэн тушаал өгч болно. Тиймээс, түгжих хугацаа эсвэл үүнийг хийх боломжийг танд олгоно. Энэ нь синтаксийн түвшинд хийгддэггүй. Энэ нь сервер дээр хувьсагч байдлаар хийгддэг. Заримдаа үүнийг ашиглах боломжгүй байдаг.
Та 75-р слайдыг нээж чадах уу?
Тиймээ.
Мөн миний асуулт бол дараах байдалтай байна. Яагаад шинэчлэлтийн процесс хоёулаа 703-г хүлээж байна вэ?
Мөн энэ бол гайхалтай асуулт юм. Постгрес яагаад үүнийг хийснийг би ойлгохгүй байна. Гэвч 703-ыг бүтээхдээ 702-ыг хүлээж байсан. 704, 705 гарч ирэхэд тэд юу хүлээж байгаагаа мэдэхгүй байгаа юм шиг байна, яагаад гэвэл тэнд юу ч байхгүй. Postgres үүнийг ингэж хийдэг: та түгжээ авч чадахгүй бол "Таныг боловсруулах нь ямар хэрэг байна вэ?" гэж бичдэг, учир нь та аль хэдийн хэн нэгнийг хүлээж байна. Тиймээс бид үүнийг зүгээр л агаарт өлгөх болно, энэ нь үүнийг огт шинэчлэхгүй. Гэхдээ энд юу болсон бэ? 702 нь процессыг дуусгаж, 703 нь түгжээгээ хүлээн авмагц систем буцаж ирэв. Тэгээд тэр одоо бид хоёр хүн хүлээж байна гэж хэлсэн. Тэгээд хамтдаа шинэчилцгээе. Хоёулаа хүлээж байгаа гэдгийг хэлье.
Postgres яагаад үүнийг хийдгийг би мэдэхгүй. Гэхдээ f... гэдэг асуудал бий. Энэ бол орос хэл дээрх нэр томъёо биш юм шиг санагдаж байна. Энэ бол шилтгээнийг хүлээж байгаа 20 эрх баригч байсан ч бүгд нэг шилтгээнийг хүлээж байгаа үе юм. Тэгээд гэнэт тэд бүгд нэгэн зэрэг сэрдэг. Тэгээд бүгд хариу үйлдэл үзүүлэх гэж оролдож эхэлдэг. Гэхдээ систем нь хүн бүр 703-ыг хүлээж байхаар болгож байна. Яагаад гэвэл тэд бүгд хүлээж байгаа, бид тэр даруй бүгдийг нь жагсаах болно. Хэрэв үүний дараа үүссэн өөр шинэ хүсэлт гарч ирвэл, жишээлбэл, 707, дахин хоосон байх болно.
Энэ үе шатанд 702 нь 703-ыг хүлээж байгаа гэж хэлэхийн тулд үүнийг хийсэн юм шиг санагдаж байна, дараа нь ирсэн бүх хүмүүст энэ талбарт орохгүй байх болно. Гэхдээ эхний зөөгчийг орхингуут шинэчлэлт хийхээс өмнө хүлээж байсан бүх хүмүүс ижил жетон хүлээн авдаг. Тиймээс тэдгээрийг зохих ёсоор захиалахын тулд бид дарааллаар нь боловсруулахын тулд үүнийг хийсэн гэж би бодож байна.
Би үүнийг үргэлж хачирхалтай үзэгдэл гэж үздэг байсан. Учир нь, жишээ нь, бид тэдгээрийг огт жагсаадаггүй. Гэхдээ бид шинэ цоож өгөх болгондоо хүлээж байгаа бүх хүмүүсийг хардаг юм шиг санагддаг. Дараа нь бид бүгдийг нь жагсаана. Дараа нь дараагийн хүн боловсруулж дуусаад л дараалалд орж ирсэн аливаа шинэ хүн дараалалд ордог. Маш сайн асуулт. Асуулт тавьсанд маш их баярлалаа!
705 нь 704 гэж хүлээж байгаа нь илүү логик юм шиг надад санагдаж байна.
Гэхдээ энд асуудал дараах байдалтай байна. Техникийн хувьд та нэгийг нь эсвэл нөгөөг нь сэрээж болно. Тиймээс бид нэгийг нь эсвэл нөгөөг нь сэрээх болно. Гэхдээ системд юу тохиолддог вэ? Та хамгийн дээд талд байгаа 703 өөрийн гүйлгээний ID-г хэрхэн хаасныг харж болно. Postgres ингэж ажилладаг. Мөн 703-ыг өөрийн гүйлгээний ID-аар хаасан тул хэрэв хэн нэгэн хүлээхийг хүсвэл 703-ыг хүлээх болно. Тэгээд үндсэндээ 703-ыг дуусгана. Зөвхөн дууссаны дараа л үйл явцын аль нэг нь сэрдэг. Мөн энэ үйл явц яг юу болохыг бид мэдэхгүй. Дараа нь бид бүх зүйлийг аажмаар боловсруулдаг. Гэхдээ аль үйл явц эхлээд сэрж байгаа нь тодорхойгүй байна, учир нь энэ нь эдгээр үйл явцын аль нэг нь байж болох юм. Үндсэндээ бид эдгээр процессуудын аль нэгийг нь сэрээх боломжтой гэж хэлсэн хуваарьтай байсан. Бид санамсаргүй байдлаар нэгийг нь сонгоно. Тиймээс бид аль нэгийг нь сэрээж чадах тул хоёуланг нь тэмдэглэх хэрэгтэй.
Асуудал нь бидэнд CP-infinity байгаа явдал юм. Тиймээс бид хожимыг нь сэрээх магадлал өндөр байна. Жишээлбэл, хэрэв бид дараагийнхыг нь сэрээх юм бол бид блок хүлээн авсан нэгнийг хүлээх болно, тиймээс бид яг хэнийг түрүүлж сэрээхийг тодорхойлохгүй. Бид зүгээр л ийм нөхцөл байдлыг бий болгодог бөгөөд систем нь тэднийг санамсаргүй дарааллаар сэрээх болно.
Байдаг . Хараач, тэд бас сонирхолтой, хэрэгтэй. Мэдээжийн хэрэг сэдэв нь маш төвөгтэй юм. Маш их баярлалаа, Брюс!
Эх сурвалж: www.habr.com