Forwarded from Engineering Notes
Concurrency Control
Zamonaviy ma'lumotlar bazalarida bir vaqtda bir nechta foydalanuvchi tomonidan parallel operatsiyalarni amalga oshirish imkonini beradi. Agar bu operatsiyalar aynan bitta resurs ustida bo'lsa (masalan, 2 ta process bir vaqtda bitta ma'lumotni o'zgartirishga harakat qilsa) ular bir-biriga konkurrent bo'ladi va bu ma'lumot yo'qotilishi bilan bogʻliq bir qancha muammolarga olib keladi.
Konkurrent operatsiyalarni xavfsiz boshqarish uchun Concurrency Control (Konkurrensiya Nazorati) mexanizmlari mavjud bo'lib, ularning asosiy vazifasi konkurrent operatsiyalar natijasida ma'lumot buzilishining oldini olish.
CC mexanizmlari konkurrensiyaga bo'lgan munosabatiga qarab 2 ta kategoriyaga bo'linadi: Optimistic CC va Pessimistic CC.
1) Optimistic CC. Bu yondoshuvga ko'ra konkurrensiya holatlari kamdan-kam sodir bo'ladi va doim alohida tayyorgarlik ko'rishga arzimaydi. Bu usul xuddi bahorda ko'chaga soyabonsiz chiqishga o'xshaydi. Yomg'ir yog'masligiga umid qilasiz, lekin yog'sa jiqqa ho'l bo'lasiz.
Kam resurs talab qiladi, lekin operatsiya muvaffaqiyatsiz tugashi mumkin.
Bu usulda ishlaydigan usullardan eng keng tarqalganlari Timestamp-Based Concurrency Control (TBCC) va Multi-Version Concurrency Control (MVCC) mexanizmlari.
TBCC har bir tranzaksiyaga unikal timestamp berish orqali tranzaksiyalarning qat'iy ketma-ketligini ishlab chiqadi va har bir obyektga uni oxirgi marta o'qigan/o'zgartirgan tranzaksiyaning timestampini yozib boradi.
Tranzaksiyadagi har bir operatsiyani bajarishdan oldin o'qilayotgan/o'zgartirilayotgan obyektda ko'rsatilgan timestampga qarab 3 ta variantdan birini tanlaydi: bajarish, kutish yoki bekor qilish. Agar birorta operatsiya muvaffaqiyatsizlikka uchrasa (bekor qilinsa) butun tranzaksiya bekor qilinadi (yomg'ir yog'ib ho'l qiladi).
Ma'lumotlarni yagona versiyada saqlaydigan tezkor, yengil lekin ishonchsiz CC mexanizmi.
MVCC ham xuddi TBCCga o'xshab har bir tranzaksiyaga unikal ID berish orqali ularning tartibini aniqlaydi. Lekin uning ustun jihati bir vaqtning o'zida aynan bitta ma'lumotning asosiy (ishonchli) versiyadan tashqari har bir tranzaksiya uchun alohida versiyalarini saqlay oladi. Natijada muvaffaqiyatsizlikka uchraydigan operatsiyalar nisbati va kutish vaqti kamayadi.
Har bir ma'lumot bir nechta versiyaga ega va uning biror versiyasi hammaga emas, faqat ma'lum tranzaksiyalargagina ko'rinadi. Buni aniqlash uchun tranzaksiya IDlari va izolyatsiya darajalaridan foydalangan holda bir qancha murakkab qoidalardan iborat visibility check (ko'rinish tekshiruvi) o'tkaziladi. Ma'lumot yozish esa TBCCdagiga o'xshashroq. Umuman olganda, MVCC TBCCning ancha murakkab ko'rinishi.
2) Pessimistic CC. Bu yondoshuvga ko'ra konkurrensiya tez-tez sodir bo'ladigan jarayon va har doim unga tayyor bo'lishi kerak. Ya'ni har ehtimolga qarshi har doim soyabon olib yurish kerak. Biroz og'irroq, lekin sodda va ishonchli usul.
Bu usulning eng keng tarqalgan ko'rinishi Two-Phase-Locking (2PL) bo'lib, ishlashi juda oddiy. Tranzaksiya biror ma'lumotni o'zgartirishidan oldin uni lock(qulf) qiladi va tranzaksiya oxirigacha saqlab turadi. Bu vaqt davomida o'sha ma'lumotdan foydalanmoqchi bo'lgan boshqa tranzaksiyalar lock ochilishini kutib turadi. Natijada bazada yagona versiyali, ishonchli ma'lumot saqlanadi.
Bu CCning turlari haqida qisqacha ma'lumot edi. Aslida bu usullarning har biri haqida diplom ishi yozish mumkin.
@boboshersnotes
Zamonaviy ma'lumotlar bazalarida bir vaqtda bir nechta foydalanuvchi tomonidan parallel operatsiyalarni amalga oshirish imkonini beradi. Agar bu operatsiyalar aynan bitta resurs ustida bo'lsa (masalan, 2 ta process bir vaqtda bitta ma'lumotni o'zgartirishga harakat qilsa) ular bir-biriga konkurrent bo'ladi va bu ma'lumot yo'qotilishi bilan bogʻliq bir qancha muammolarga olib keladi.
Konkurrent operatsiyalarni xavfsiz boshqarish uchun Concurrency Control (Konkurrensiya Nazorati) mexanizmlari mavjud bo'lib, ularning asosiy vazifasi konkurrent operatsiyalar natijasida ma'lumot buzilishining oldini olish.
CC mexanizmlari konkurrensiyaga bo'lgan munosabatiga qarab 2 ta kategoriyaga bo'linadi: Optimistic CC va Pessimistic CC.
1) Optimistic CC. Bu yondoshuvga ko'ra konkurrensiya holatlari kamdan-kam sodir bo'ladi va doim alohida tayyorgarlik ko'rishga arzimaydi. Bu usul xuddi bahorda ko'chaga soyabonsiz chiqishga o'xshaydi. Yomg'ir yog'masligiga umid qilasiz, lekin yog'sa jiqqa ho'l bo'lasiz.
Kam resurs talab qiladi, lekin operatsiya muvaffaqiyatsiz tugashi mumkin.
Bu usulda ishlaydigan usullardan eng keng tarqalganlari Timestamp-Based Concurrency Control (TBCC) va Multi-Version Concurrency Control (MVCC) mexanizmlari.
TBCC har bir tranzaksiyaga unikal timestamp berish orqali tranzaksiyalarning qat'iy ketma-ketligini ishlab chiqadi va har bir obyektga uni oxirgi marta o'qigan/o'zgartirgan tranzaksiyaning timestampini yozib boradi.
Tranzaksiyadagi har bir operatsiyani bajarishdan oldin o'qilayotgan/o'zgartirilayotgan obyektda ko'rsatilgan timestampga qarab 3 ta variantdan birini tanlaydi: bajarish, kutish yoki bekor qilish. Agar birorta operatsiya muvaffaqiyatsizlikka uchrasa (bekor qilinsa) butun tranzaksiya bekor qilinadi (yomg'ir yog'ib ho'l qiladi).
Ma'lumotlarni yagona versiyada saqlaydigan tezkor, yengil lekin ishonchsiz CC mexanizmi.
MVCC ham xuddi TBCCga o'xshab har bir tranzaksiyaga unikal ID berish orqali ularning tartibini aniqlaydi. Lekin uning ustun jihati bir vaqtning o'zida aynan bitta ma'lumotning asosiy (ishonchli) versiyadan tashqari har bir tranzaksiya uchun alohida versiyalarini saqlay oladi. Natijada muvaffaqiyatsizlikka uchraydigan operatsiyalar nisbati va kutish vaqti kamayadi.
Har bir ma'lumot bir nechta versiyaga ega va uning biror versiyasi hammaga emas, faqat ma'lum tranzaksiyalargagina ko'rinadi. Buni aniqlash uchun tranzaksiya IDlari va izolyatsiya darajalaridan foydalangan holda bir qancha murakkab qoidalardan iborat visibility check (ko'rinish tekshiruvi) o'tkaziladi. Ma'lumot yozish esa TBCCdagiga o'xshashroq. Umuman olganda, MVCC TBCCning ancha murakkab ko'rinishi.
2) Pessimistic CC. Bu yondoshuvga ko'ra konkurrensiya tez-tez sodir bo'ladigan jarayon va har doim unga tayyor bo'lishi kerak. Ya'ni har ehtimolga qarshi har doim soyabon olib yurish kerak. Biroz og'irroq, lekin sodda va ishonchli usul.
Bu usulning eng keng tarqalgan ko'rinishi Two-Phase-Locking (2PL) bo'lib, ishlashi juda oddiy. Tranzaksiya biror ma'lumotni o'zgartirishidan oldin uni lock(qulf) qiladi va tranzaksiya oxirigacha saqlab turadi. Bu vaqt davomida o'sha ma'lumotdan foydalanmoqchi bo'lgan boshqa tranzaksiyalar lock ochilishini kutib turadi. Natijada bazada yagona versiyali, ishonchli ma'lumot saqlanadi.
Bu CCning turlari haqida qisqacha ma'lumot edi. Aslida bu usullarning har biri haqida diplom ishi yozish mumkin.
@boboshersnotes
Wikipedia
Concurrency control
measures to ensure concurrent computing operations generate correct results
👍13
Fakt: Pythonda classlarning o'zi ham aslida boshqa classdan olingan object.
Kuningiz yaxshi o'tsin ))
Kuningiz yaxshi o'tsin ))
😁14👍1👎1😢1
Forwarded from Otabek’s I/O
Best practices
Shaxsiy fikrim inson nimanidir qilishga boshidan odatlanishi juda yomon agar u haqiqatdan yomon narsa bo'lsa.
Yomon kod yozishga boshidan o'rgansa keyin yaxshilashi uchun juda ko'p vaqt ketadi.
Boshlagan ishini oxiriga yetkazmasa, keyin to'g'irlash juda qiyin bo'ladi.
Shuni inobatga olib boshidan o'zini shu narsaga o'rgata olsa bu uning eng katta yutug'i bo'ladi deb o'ylayman.
Daraxt o'sib bo'lgandan keyin uni to'g'irlash juda katta muammolar keltirishi, sinishlar yuzaga kelishi mumkin.
Ammo nixol paytida qiyshiqlikni to'g'irlash hech qanday zarar yetkazmaydi.
Chiroyli va tushunarli kod yozishga odatlaning. Bilmasngiz o'rganing.
Mana bu sizga oz-moz yordam berishi mumkin.
@unotech_log
Shaxsiy fikrim inson nimanidir qilishga boshidan odatlanishi juda yomon agar u haqiqatdan yomon narsa bo'lsa.
Yomon kod yozishga boshidan o'rgansa keyin yaxshilashi uchun juda ko'p vaqt ketadi.
Boshlagan ishini oxiriga yetkazmasa, keyin to'g'irlash juda qiyin bo'ladi.
Shuni inobatga olib boshidan o'zini shu narsaga o'rgata olsa bu uning eng katta yutug'i bo'ladi deb o'ylayman.
Daraxt o'sib bo'lgandan keyin uni to'g'irlash juda katta muammolar keltirishi, sinishlar yuzaga kelishi mumkin.
Ammo nixol paytida qiyshiqlikni to'g'irlash hech qanday zarar yetkazmaydi.
Chiroyli va tushunarli kod yozishga odatlaning. Bilmasngiz o'rganing.
Mana bu sizga oz-moz yordam berishi mumkin.
@unotech_log
👍17
Forwarded from samdark blog ☕️ (Alexander Makarov)
🔗 Philosophies that Shaped Successful Frameworks
The writing by Qiang Xue, original creator of Yii framework. It is from 2016 but didn't lose its actuality.
https://medium.com/capital-one-tech/philosophies-that-shaped-successful-frameworks-f976781e9bd4
The writing by Qiang Xue, original creator of Yii framework. It is from 2016 but didn't lose its actuality.
https://medium.com/capital-one-tech/philosophies-that-shaped-successful-frameworks-f976781e9bd4
Medium
Philosophies that Shaped Successful Frameworks
During the past decade we’ve seen many software frameworks pop up. Frameworks such as Spring and Ruby on Rails have become so successful…
👍4
Which properties of mutable Python objects are modifiable?
Anonymous Quiz
27%
Identity, Value
47%
Type, Value
26%
Value
👍9👎1
Systems engineering (asosan database/storage systems) uchun asosiy til sifatida qaysi tilga ko'proq fokus qilishni tavsiya qilasizlar?
C/C++, Rust yoki Go?
C/C++, Rust yoki Go?
👍1👎1
Ba'zi ustozlar yoniga 1 ta savol bilan borib, yangi 2 ta savol bilan qaytasiz. Ular sizga shunchaki javobni emas, balki javobga yo'nalishni ko'rsatadi. Bu yo'lda esa yangi savollarga duch kelasiz. Bu esa original savolga javob topgandan keyin ham yana ko'proq o'rganishga undaydi.
Shunday ustozlar mening qahramonim.
Shunday ustozlar mening qahramonim.
👍77👎1
When parallelism is serialized into a single CPU core, it's called multiprocessing.
When parallelism is serialized into a single process, it's called multithreading.
When parallelism is serialized into a single thread, it's called asynchronous execution.
When parallelism is serialized into a single process, it's called multithreading.
When parallelism is serialized into a single thread, it's called asynchronous execution.
👍44🍾2
Muammolar takrorlanadi
Avvallari 1 ta komputerda 1 ta processgina run bo'la olgan. Keyinroq 1 ta CPU coreda bir nechta "virtual process"(bizga tanish software process)larni qisqa interval bilan navbatma-navbat run qilish orqali CPU coredan effektivroq foydalanish imkoniyati paydo bo'ldi va multiprocessing deb nomlandi.
Ba'zida qisqa vaqt ichida tez-tez yangi process ochib-yopish, bir processdan boshqasiga ma'lumot yuborish kerak bo'ladi. Processlar og'irligi va o'zaro ma'lumot almashish qiyinligi sabab bitta processning o'zida ham bir nechta "tipa process" – thread yaratishga ehtiyoj tug'ildi.
Dizayn jihatdan hammasi yaxshi edi, lekin implementatsiyaga kelganda boshqa bir qancha jiddiy savollar (process forking, signal handling, ...) bilan birga yana bir qiziq savol paydo bo'ldi: threadlarni kernel levelda implement qilish kerakmi yoki user leveldami?
Kernel levelda implement qilish threadga qo'yilgan asosiy talab – yengillik va tezlikni ta'minlab bera olmaydi. User levelda implement qilishda esa scheduling bilan jiddiy muammo chiqadi: agar biror thread I/O call qilsa OS faqat o'sha threadning o'zini emas, butun processni (ya'ni o'sha processdagi hamma threadlarni) bloklaydi. Sababi, kernelda joylashgan scheduler user spacedagi thread nimaligini ham bilmaydi.
Muammoni hal qilish uchun esa user spaceda ishlaydigan va muhimi har bitta threadni alohida schedule qilish imkonini beradigan yechim kerak bo'ldi va qaysidir darajada topildi ham.
***
Qizig'i, xuddi shunga o'xshash jarayon dasturlashning umuman boshqa bir yo'nalishi – network engineeringda ham sodir bo'lgan.
HTTP 1.0 protocolida bir vaqtda faqatgina bitta connection ochish mumkin edi. Bir vaqtda bir nechta resurslarni olishga ehtiyoj tug'ilgani sabab HTTP 1.1 versiyasida bir vaqtda 6 tagacha har biri alohida TCP connection ustiga qurilgan HTTP connection ochish mumkin bo'ldi. Bu yechim ancha omadli chiqqan bo'lsa-da bir qancha sabablar (connectionlarni ochish/yopish og'irligi, asinxron ishlashning imkoni yo'qligi) tufayli yana yangi nimadir o'ylab topish kerak bo'ldi.
HTTP 2.0 bitta TCP connection ustiga ko'plab yengil HTTP connectionlar ochish imkoniyatini taqdim etdi. Endi connectionlar sonini dinamik qilish va asinxron ishlash mumkin bo'ldi. Lekin kutilmaganda bir muammo chiqdi: birorta HTTP connection tarkibidagi birorta paket yetib kelmasa retransmission uchun butun TCP connection (demakki qolgan HTTP connectionlar ham) bloklanadi. Sababi, TCP transport layerda joylashgan va application layerdagi connection nimaligini bilmaydi. Bu muammo HOL Blocking deyiladi.
Bu muammoni hal qilish uchun application leyer va transport layerdagi connectionlar bir-birini "taniydigan" yangi mexanizm – QUIC va HTTP 3 ishlab chiqildi.
@boboshersnotes
Avvallari 1 ta komputerda 1 ta processgina run bo'la olgan. Keyinroq 1 ta CPU coreda bir nechta "virtual process"(bizga tanish software process)larni qisqa interval bilan navbatma-navbat run qilish orqali CPU coredan effektivroq foydalanish imkoniyati paydo bo'ldi va multiprocessing deb nomlandi.
Ba'zida qisqa vaqt ichida tez-tez yangi process ochib-yopish, bir processdan boshqasiga ma'lumot yuborish kerak bo'ladi. Processlar og'irligi va o'zaro ma'lumot almashish qiyinligi sabab bitta processning o'zida ham bir nechta "tipa process" – thread yaratishga ehtiyoj tug'ildi.
Dizayn jihatdan hammasi yaxshi edi, lekin implementatsiyaga kelganda boshqa bir qancha jiddiy savollar (process forking, signal handling, ...) bilan birga yana bir qiziq savol paydo bo'ldi: threadlarni kernel levelda implement qilish kerakmi yoki user leveldami?
Kernel levelda implement qilish threadga qo'yilgan asosiy talab – yengillik va tezlikni ta'minlab bera olmaydi. User levelda implement qilishda esa scheduling bilan jiddiy muammo chiqadi: agar biror thread I/O call qilsa OS faqat o'sha threadning o'zini emas, butun processni (ya'ni o'sha processdagi hamma threadlarni) bloklaydi. Sababi, kernelda joylashgan scheduler user spacedagi thread nimaligini ham bilmaydi.
Muammoni hal qilish uchun esa user spaceda ishlaydigan va muhimi har bitta threadni alohida schedule qilish imkonini beradigan yechim kerak bo'ldi va qaysidir darajada topildi ham.
***
Qizig'i, xuddi shunga o'xshash jarayon dasturlashning umuman boshqa bir yo'nalishi – network engineeringda ham sodir bo'lgan.
HTTP 1.0 protocolida bir vaqtda faqatgina bitta connection ochish mumkin edi. Bir vaqtda bir nechta resurslarni olishga ehtiyoj tug'ilgani sabab HTTP 1.1 versiyasida bir vaqtda 6 tagacha har biri alohida TCP connection ustiga qurilgan HTTP connection ochish mumkin bo'ldi. Bu yechim ancha omadli chiqqan bo'lsa-da bir qancha sabablar (connectionlarni ochish/yopish og'irligi, asinxron ishlashning imkoni yo'qligi) tufayli yana yangi nimadir o'ylab topish kerak bo'ldi.
HTTP 2.0 bitta TCP connection ustiga ko'plab yengil HTTP connectionlar ochish imkoniyatini taqdim etdi. Endi connectionlar sonini dinamik qilish va asinxron ishlash mumkin bo'ldi. Lekin kutilmaganda bir muammo chiqdi: birorta HTTP connection tarkibidagi birorta paket yetib kelmasa retransmission uchun butun TCP connection (demakki qolgan HTTP connectionlar ham) bloklanadi. Sababi, TCP transport layerda joylashgan va application layerdagi connection nimaligini bilmaydi. Bu muammo HOL Blocking deyiladi.
Bu muammoni hal qilish uchun application leyer va transport layerdagi connectionlar bir-birini "taniydigan" yangi mexanizm – QUIC va HTTP 3 ishlab chiqildi.
@boboshersnotes
👍28