Forwarded from Josh*Developer
Yangilik!
Esingizda bo'lsa TypeScript va Angular bo'yicha pullik onlayn dars o'tgan edim. Shuning yozib olingan videolarini siz azizlarga tekinga ulashishga qaror qildim.
Darslar kimlar uchun ?
1. TypeScriptni o'rganayotganlar uchun.
2. Angularni o'rganayotganlar uchun.
Ushbu link orqali darslar turgan kanalga ulanishingiz va bemalol foydalanishingiz mumkin. Marhamat.
https://t.me/+M3Dy5G9I7A5kMzQy
Alloh manfaatli qilsin.
P.s: Ba'zi hollarni inobatga olib, darslarni yuklab olish va tarqatishni o'chirib qo'ydim. Bu uchun ma'zur tutasiz.
@JoshDeveloper
Esingizda bo'lsa TypeScript va Angular bo'yicha pullik onlayn dars o'tgan edim. Shuning yozib olingan videolarini siz azizlarga tekinga ulashishga qaror qildim.
Darslar kimlar uchun ?
1. TypeScriptni o'rganayotganlar uchun.
2. Angularni o'rganayotganlar uchun.
Ushbu link orqali darslar turgan kanalga ulanishingiz va bemalol foydalanishingiz mumkin. Marhamat.
https://t.me/+M3Dy5G9I7A5kMzQy
Alloh manfaatli qilsin.
P.s: Ba'zi hollarni inobatga olib, darslarni yuklab olish va tarqatishni o'chirib qo'ydim. Bu uchun ma'zur tutasiz.
@JoshDeveloper
👍15
Forwarded from Jamolkhon Akhmedov
Good developers know how things work.
Great developers know why things work.
Steve Souders, Head Performance Engineer, Google, 2013
Great developers know why things work.
Steve Souders, Head Performance Engineer, Google, 2013
👍20
Bir haftadan beri platformamizda database bilan bog'liq jiddiy bir muammoning sababini topa olmayapman.
Hal bo'lsa interviewlar uchun yaxshi story chiqadi lekin.
P.S. Self note.
Hal bo'lsa interviewlar uchun yaxshi story chiqadi lekin.
P.S. Self note.
👍38
Forwarded from Bobosher's blog | #FreePalestine
Hozirgi kunda biz deyarli hamma ma'lumotni chiroyli va lo'nda ko'rinishda – video, grafik va h.k ko'rinishda olamiz. Bu bir tomondan yaxshi bo'lsa-da, ikkinchi tomondan miyani shunday ko'rinishdagi ma'lumot olishga o'rgatib qo'yadi. Natijada attention span kamayadi. Odam kitob yoki uzunroq maqola o'qishga qiynaladi. Aniqrog'i, sabri chidamaydi. Aslida, bizning avlodning eng katta muammolaridan biri ham shu. Biz hatto o'qishga erinadigan kitobni kimdir sabr bilan yozgan.
Bu yomonmi? Juda yomon. Cal Newport aytganidek, kelajakda yaxshi mutaxassisni yomonidan ajratadigan asosiy faktorlardan biri deep work, attention span bo'ladi.
Engineering Notesda rasm, grafiklardan minimal foydalanishim, iloji boricha hamma ma'lumotni raw text sifatida yozishimning asosiy sababi ham shu. Bir tomondan bu o'zimga attention spanni oshirishga yordam bersa, ikkinchi tomondan readerlarga ham foyda.
Lekin bu yerda yetkazib bera olish juda muhim faktor. Buni uddalayapmanmi? Menimcha unchalik emas. Lekin harakat qilayapman.
Bollar, biz yutamiz.
Bu yomonmi? Juda yomon. Cal Newport aytganidek, kelajakda yaxshi mutaxassisni yomonidan ajratadigan asosiy faktorlardan biri deep work, attention span bo'ladi.
Engineering Notesda rasm, grafiklardan minimal foydalanishim, iloji boricha hamma ma'lumotni raw text sifatida yozishimning asosiy sababi ham shu. Bir tomondan bu o'zimga attention spanni oshirishga yordam bersa, ikkinchi tomondan readerlarga ham foyda.
Lekin bu yerda yetkazib bera olish juda muhim faktor. Buni uddalayapmanmi? Menimcha unchalik emas. Lekin harakat qilayapman.
Bollar, biz yutamiz.
👍39
PHP yomon tilmi?
Yo'q, PHP yomon til emas, shunchaki 90-yillardagi internetga aynan shunday til kerak bo'lgan. U vaqtda web serverlar hozirgidek o'nlab komponentlardan tashkil topmagan. Shunchaki static content serve qilinib, bu content foydalanuvchining browserida render qilingan. PHP esa shu holatda minimal o'zgarishlar bilan server-side processing imkoniyatini yaratdi va bu internetni "next level"ga olib chiqdi.
Xo'sh, o'sha vaqtda ham static content serverdan alohida ishlaydigan til ishlab chiqsa bo'lardiku deyishingiz mumkin. Albatta bo'lardi, lekin PHP internetni o'zgartirib yuborish uchun emas, shunchaki shaxsiy websaytga qo'shimcha imkoniyat qo'shish g'oyasi bilan ishlab chiqilgan til. Rasmus aka shunchaki o'sha vaqtdagi toollardan foydalanib o'zi uchun kichkina til ishlab chiqmoqchi edi. Natija esa o'sha afsonaviy PHP bo'ldi.
P.S. Sizlarga yana bir sirni ochaman: PHPning kengaytmasi aslida Hypertext Preprocessor emas, Personal Home Page'dan kelib chiqqan.
Yo'q, PHP yomon til emas, shunchaki 90-yillardagi internetga aynan shunday til kerak bo'lgan. U vaqtda web serverlar hozirgidek o'nlab komponentlardan tashkil topmagan. Shunchaki static content serve qilinib, bu content foydalanuvchining browserida render qilingan. PHP esa shu holatda minimal o'zgarishlar bilan server-side processing imkoniyatini yaratdi va bu internetni "next level"ga olib chiqdi.
Xo'sh, o'sha vaqtda ham static content serverdan alohida ishlaydigan til ishlab chiqsa bo'lardiku deyishingiz mumkin. Albatta bo'lardi, lekin PHP internetni o'zgartirib yuborish uchun emas, shunchaki shaxsiy websaytga qo'shimcha imkoniyat qo'shish g'oyasi bilan ishlab chiqilgan til. Rasmus aka shunchaki o'sha vaqtdagi toollardan foydalanib o'zi uchun kichkina til ishlab chiqmoqchi edi. Natija esa o'sha afsonaviy PHP bo'ldi.
P.S. Sizlarga yana bir sirni ochaman: PHPning kengaytmasi aslida Hypertext Preprocessor emas, Personal Home Page'dan kelib chiqqan.
👍28😁12
Watch "Keynote: Multithreaded Python without the GIL - presented by Sam Gross" on YouTube
https://youtu.be/9OOJcTp8dqE
https://youtu.be/9OOJcTp8dqE
YouTube
Keynote: Multithreaded Python without the GIL - presented by Sam Gross
EuroPython 2022 - Keynote: Multithreaded Python without the GIL - presented by Sam Gross
[The Auditorium on 2022-07-15]
CPython’s “Global Interpreter Lock”, or “GIL”, prevents multiple threads from executing Python code in parallel. The GIL was added to…
[The Auditorium on 2022-07-15]
CPython’s “Global Interpreter Lock”, or “GIL”, prevents multiple threads from executing Python code in parallel. The GIL was added to…
👍11
Forwarded from Umar Sadullayev
Muvaffaqiyatsizligidan noliyotgan insonlarni ko'pchiligida bir xatoni ko'rdim:
Intizom yo'qligi.
Boshlagan ishini oxirigacha olib borishmaydi. Ozgina muddat qiyinchilik ko'rib, darrov sabrsizlik qilib tashlab qo'yishadi. O'z ustida ishlashni davomiy olib borishmaydi. Bir necha hafta yoki oy qilishadi, keyin yana sabrlari tugab, dangasalik qilishadi, yutqazishadi. Oxirida esa umrlarini katta qismi o'tgan bo'ladi, ular esa hech narsaga erishishmagan. Chunki hech birida oxirigacha borishmagan bo'ladi.
Shu narsa ulardagi muvaffaqiyatsizlikka sabablardan biri.
@UmarSadullayev
Intizom yo'qligi.
Boshlagan ishini oxirigacha olib borishmaydi. Ozgina muddat qiyinchilik ko'rib, darrov sabrsizlik qilib tashlab qo'yishadi. O'z ustida ishlashni davomiy olib borishmaydi. Bir necha hafta yoki oy qilishadi, keyin yana sabrlari tugab, dangasalik qilishadi, yutqazishadi. Oxirida esa umrlarini katta qismi o'tgan bo'ladi, ular esa hech narsaga erishishmagan. Chunki hech birida oxirigacha borishmagan bo'ladi.
Shu narsa ulardagi muvaffaqiyatsizlikka sabablardan biri.
@UmarSadullayev
👍29😁3😢1
Forwarded from Engineering Notes
"Sifatli softwarega kuchli toollar orqali emas, kuchli dasturchilar orqali erishiladi." – degandi David West.
Bu degani tool qanchalik zo'r bo'lmasin, u to'g'ri ishlatilmasa "bir tiyinga qimmat".
Masalan, GraphQL hozir ancha mashhur bo'lib ketdi. Xo'sh savol, uning RESTdan eng ustun tomoni nima? Flexibility!
Facebookdagilar aynan shuning uchun GraphQLni yaratgan. Clientda RESTdagiga o'xshab o'ziga kerakli 2-3 ta fieldni olish uchun butun boshli ulkan obyektni emas, faqat o'zi so'ragan, o'zi uchun yetarli minimal datani olish imkoniyati bor. Bu aslidan minglab marta sodda ko'rinishdagi tushuntirish.
Xo'sh, buni texnologiyani noto'g'ri ishlatayotganlar ham bormi?
Ochig'ini aytganda, faqat sanoqli kompaniyalargina to'g'ri ishlata olayapti. Men siz yaqinda ishlab chiqqan CRM yoki lokal bank tizimi haqida gapirmayapman. Hattoki Twitterga o'xshash kuchli mutaxassislarga ega texnogigantlar ham implementatsiyaga kelganda oqsoqlanayapti. Ishonmaysizmi? Twitterning web versiyasini inspect qilib, network panelni kuzating, o'zingiz ko'rasiz.
Qisqasi, Python PHPdan zo'r deyishdan oldin post boshidagi gapni o'qing.
P.S. "Sen kim bo'libsan Twitterning ogorodiga tosh otadigan?" deydiganlarga javob – mashinaga baho berish uchun oldin o'zingiz mashina qurishingiz shart emas (ayniqsa bizda).
Bu degani tool qanchalik zo'r bo'lmasin, u to'g'ri ishlatilmasa "bir tiyinga qimmat".
Masalan, GraphQL hozir ancha mashhur bo'lib ketdi. Xo'sh savol, uning RESTdan eng ustun tomoni nima? Flexibility!
Facebookdagilar aynan shuning uchun GraphQLni yaratgan. Clientda RESTdagiga o'xshab o'ziga kerakli 2-3 ta fieldni olish uchun butun boshli ulkan obyektni emas, faqat o'zi so'ragan, o'zi uchun yetarli minimal datani olish imkoniyati bor. Bu aslidan minglab marta sodda ko'rinishdagi tushuntirish.
Xo'sh, buni texnologiyani noto'g'ri ishlatayotganlar ham bormi?
Ochig'ini aytganda, faqat sanoqli kompaniyalargina to'g'ri ishlata olayapti. Men siz yaqinda ishlab chiqqan CRM yoki lokal bank tizimi haqida gapirmayapman. Hattoki Twitterga o'xshash kuchli mutaxassislarga ega texnogigantlar ham implementatsiyaga kelganda oqsoqlanayapti. Ishonmaysizmi? Twitterning web versiyasini inspect qilib, network panelni kuzating, o'zingiz ko'rasiz.
Qisqasi, Python PHPdan zo'r deyishdan oldin post boshidagi gapni o'qing.
P.S. "Sen kim bo'libsan Twitterning ogorodiga tosh otadigan?" deydiganlarga javob – mashinaga baho berish uchun oldin o'zingiz mashina qurishingiz shart emas (ayniqsa bizda).
👍20
1. OOPning asosiy afzalligi dasturchi dastur haqida "odamga o'xshab" o'ylashiga imkon berish. Kompyuterga o'xshab emas.
2. Shunchaki data va behaviour birlashsa bu hali object degani emas.
3. Dasturda classlardan foydalanish bu hali OOP degani emas.
2. Shunchaki data va behaviour birlashsa bu hali object degani emas.
3. Dasturda classlardan foydalanish bu hali OOP degani emas.
👍18
Engineering Notes
1. OOPning asosiy afzalligi dasturchi dastur haqida "odamga o'xshab" o'ylashiga imkon berish. Kompyuterga o'xshab emas. 2. Shunchaki data va behaviour birlashsa bu hali object degani emas. 3. Dasturda classlardan foydalanish bu hali OOP degani emas.
OOPni o'rganishda eng ko'p uchraydigan xatolardan biri OOP konseptlarini biror dasturlash tiliga bog'lab o'rganish. Bu xato, sababi OOP bu paradigm, dasturlash tillaridan ancha yuqorida turadigan konsept. Til esa OOPni kodda implementatsiyani ko'rsatib berish uchungina ishlatilishi kerak deb hisoblayman.
"Java OOP" emas, "OOPning Javadagi ko'rinishi" bo'lishi kerak aslida.
"Java OOP" emas, "OOPning Javadagi ko'rinishi" bo'lishi kerak aslida.
👍22👎1
Forwarded from Programming ∀
Aynan shu rasmni yaxshiroq izohlash payti keldi.
Getter va setterlar. Buyoqda aytilishi bo'yicha esa Encapsulated fieldlar.
Asosiy muammo shundaki OOPdagi encapsulation prinspi Object o'zini o'zi boshqara oladigan qilishga nisbatan qaratilgan yani anchagina smart bo'lishi kerak. Shu sababdan undagi qandaydur ko'rsatkich yoki parametrlar faqat object o'zigagina ma'lum bo'lishi kerak. Shu orqali biz uni hul atrovini va missiyasini belgilashimiz kerak. Ammo getter setterlar objectlar dummy bo'lishiga sabab bo'ladi va encapsulation buzuladi.
Albatta barcha objectlarni bunday prinspga asoslanib qurish imkonsiz xozirgi muhitda. Lekin falsafiy jixatdan yuqoridagi uslub encapsulationga teskari ))).
Getter va setterlar. Buyoqda aytilishi bo'yicha esa Encapsulated fieldlar.
Asosiy muammo shundaki OOPdagi encapsulation prinspi Object o'zini o'zi boshqara oladigan qilishga nisbatan qaratilgan yani anchagina smart bo'lishi kerak. Shu sababdan undagi qandaydur ko'rsatkich yoki parametrlar faqat object o'zigagina ma'lum bo'lishi kerak. Shu orqali biz uni hul atrovini va missiyasini belgilashimiz kerak. Ammo getter setterlar objectlar dummy bo'lishiga sabab bo'ladi va encapsulation buzuladi.
Albatta barcha objectlarni bunday prinspga asoslanib qurish imkonsiz xozirgi muhitda. Lekin falsafiy jixatdan yuqoridagi uslub encapsulationga teskari ))).
👍10
Programming ∀
Aynan shu rasmni yaxshiroq izohlash payti keldi. Getter va setterlar. Buyoqda aytilishi bo'yicha esa Encapsulated fieldlar. Asosiy muammo shundaki OOPdagi encapsulation prinspi Object o'zini o'zi boshqara oladigan qilishga nisbatan qaratilgan yani anchagina…
Juda ajoyib fikr bo'ldi. Getter va setterlar encapsulationga emas, aslida objectning kamroq encapsulated bo'lishiga sabab bo'ladi.
👍9
ACID haqida gaplashamiz
Ko'p hollarda foydalanuvchi uchun bir butun sifatida qaraladigan o'zgarish ma'lumotlar ba'zasida bir nechta ketma-ket o'zgarishlarni talab qiladi.
Masalan, do'stingizning kartasiga $100 yubormoqchisiz. Bu siz uchun bir butun ish. Lekin ma'lumotlar ba'zasida bu eng kamida mana bu ketma-ket qadamlardan iborat:
1) Sizning balansingizni $100 ga kamaytirish;
2) Do'stingizning hisobini $100 ga oshirish;
Xatoliklarning oldini olish uchun bunday operatsiyalarni ma'lumotlar ba'zasida ham bir butun deb qarashga imkon beruvchi yangi birlikka ehtiyoj tug'iladi. Bu birlik tranzaksiya deb ataladi. Demak, tranzaksiya ma'lumotlar bazasida mantiqiy jihatdan bir butun ish bo'lgan bir nechta query(so'rov)larni birlashtirish imkonini beradigan "quticha".
ACID esa trakzaksiyalar o'zini qanday tutishini belgilaydigan umumiy qoidalar to'plami. Bu qoidalar orqali kutilmagan vaziyatlarda (xatolik chiqqanida, server o'chib qolganida va h.k.) trakzaksiyadagi ma'lumot haqiqiyligini (data validity) saqlab qolish ta'minlanadi.
ACID so'zi 4 ta qoida: Atomicity, Consistency, Isolation va Durability so'zlarining bosh harflaridan olingan. Xo'sh, bu qoidalar nima?
Atomicity – bo'linmaslik
Bu qoidaga ko'ra tranzaksiyalar bo'linmas, bir butun bo'lishi kerak. Yo tranzaksiyadagi hamma operatsiya muvaffaqiyatli bajariladi yoki hech qaysi operatsiya bajarilmaydi. Bir qismi bajarilib, qolgan qismi bajarilmay qolishi mumkin emas. Agar qaysidir operatsiyani bajarish vaqtida xatolik chiqsa butun tranzaksiya muvaffaqiyatsiz bo'ladi va bu tranzaksiyadagi muvaffaqiyatli bajarilgan operatsiyalar ham avvalgi holiga qaytariladi (rollback). Bir kishi hamma uchun, hamma bir kishi uchun deganlaridek...
Tepadagi misolda, deylik, sizning hisobingizdan pul yechildi, lekin do'stingizning hisobini oshirish vaqtida xatolik chiqdi. Natijada siz $100 yo'qotdingiz, lekin do'stingiz qabul qilmadi. $100 "havoga uchdi".
Buning oldini olish uchun xatolik chiqqanida butun tranzaksiya bo'ylab barcha operatsiyalar avvalgi holatiga qaytariladi, ya'ni $100 sizning hisobingizga qaytariladi.
Consistency – moslik
Tranzaksiya natijasi ma'lumotlar bazasida avvaldan belgilab qo'yilgan qoidalar bilan mos bo'lishi kerak. Aks holda tranzaksiya muvaffaqiyatsiz deb belgilanadi va rollback qilinadi. Deylik, qoidaga ko'ra foydalanuvchi balansi manfiy bo'lmasligi kerak. Agar hisobingizda $60 bo'lsa, do'stingizga $100 o'tkazgandan keyin hisobingiz -$40 bo'ladi. Bu esa tepadagi qoidaga to'g'ri kelmaydi. Operatsiyalar muvaffaqiyatli bo'lsa-da natija qoidalar bilan mos bo'lmagani uchun bekor qilinadi.
Ko'p hollarda foydalanuvchi uchun bir butun sifatida qaraladigan o'zgarish ma'lumotlar ba'zasida bir nechta ketma-ket o'zgarishlarni talab qiladi.
Masalan, do'stingizning kartasiga $100 yubormoqchisiz. Bu siz uchun bir butun ish. Lekin ma'lumotlar ba'zasida bu eng kamida mana bu ketma-ket qadamlardan iborat:
1) Sizning balansingizni $100 ga kamaytirish;
2) Do'stingizning hisobini $100 ga oshirish;
Xatoliklarning oldini olish uchun bunday operatsiyalarni ma'lumotlar ba'zasida ham bir butun deb qarashga imkon beruvchi yangi birlikka ehtiyoj tug'iladi. Bu birlik tranzaksiya deb ataladi. Demak, tranzaksiya ma'lumotlar bazasida mantiqiy jihatdan bir butun ish bo'lgan bir nechta query(so'rov)larni birlashtirish imkonini beradigan "quticha".
ACID esa trakzaksiyalar o'zini qanday tutishini belgilaydigan umumiy qoidalar to'plami. Bu qoidalar orqali kutilmagan vaziyatlarda (xatolik chiqqanida, server o'chib qolganida va h.k.) trakzaksiyadagi ma'lumot haqiqiyligini (data validity) saqlab qolish ta'minlanadi.
ACID so'zi 4 ta qoida: Atomicity, Consistency, Isolation va Durability so'zlarining bosh harflaridan olingan. Xo'sh, bu qoidalar nima?
Atomicity – bo'linmaslik
Bu qoidaga ko'ra tranzaksiyalar bo'linmas, bir butun bo'lishi kerak. Yo tranzaksiyadagi hamma operatsiya muvaffaqiyatli bajariladi yoki hech qaysi operatsiya bajarilmaydi. Bir qismi bajarilib, qolgan qismi bajarilmay qolishi mumkin emas. Agar qaysidir operatsiyani bajarish vaqtida xatolik chiqsa butun tranzaksiya muvaffaqiyatsiz bo'ladi va bu tranzaksiyadagi muvaffaqiyatli bajarilgan operatsiyalar ham avvalgi holiga qaytariladi (rollback). Bir kishi hamma uchun, hamma bir kishi uchun deganlaridek...
Tepadagi misolda, deylik, sizning hisobingizdan pul yechildi, lekin do'stingizning hisobini oshirish vaqtida xatolik chiqdi. Natijada siz $100 yo'qotdingiz, lekin do'stingiz qabul qilmadi. $100 "havoga uchdi".
Buning oldini olish uchun xatolik chiqqanida butun tranzaksiya bo'ylab barcha operatsiyalar avvalgi holatiga qaytariladi, ya'ni $100 sizning hisobingizga qaytariladi.
Consistency – moslik
Tranzaksiya natijasi ma'lumotlar bazasida avvaldan belgilab qo'yilgan qoidalar bilan mos bo'lishi kerak. Aks holda tranzaksiya muvaffaqiyatsiz deb belgilanadi va rollback qilinadi. Deylik, qoidaga ko'ra foydalanuvchi balansi manfiy bo'lmasligi kerak. Agar hisobingizda $60 bo'lsa, do'stingizga $100 o'tkazgandan keyin hisobingiz -$40 bo'ladi. Bu esa tepadagi qoidaga to'g'ri kelmaydi. Operatsiyalar muvaffaqiyatli bo'lsa-da natija qoidalar bilan mos bo'lmagani uchun bekor qilinadi.
👍26
Isolation – izolyatsiya
Hali tugallanmagan trakzaksiyadagi ma'lumotlar tashqaridan (boshqa tranzaksiyalardan va tranzaksiya tashqarisidagi boshqa operatsiyalardan) izolyatsiyalanishi kerak. Ya'ni tranzaksiya tugamagunicha ichkaridagi ma'lumot tashqariga ko'rinmasligi kerak.
Masalan, tepadagi misolda hisobingizdan pul yechildi, lekin hali do'stingizga tushmadi. Shu vaziyatda, hali tranzaksiya tugamasidan balansingiz tekshirilganida kamaygan qiymat emas, tranzaksiyadan tashqaridagi, oldingi qiymat ko'rinishi kerak.
To'liq izolyatsiya ko'p resurs va vaqt talab qilgani uchun va doim ham to'liq izolyatsiya zarur bo'lmagani uchun tranzaksiya izolyatsiyasining 4 ta standart darajalari bor. Ular tezlik, resurslar sarfi va xavfsizligi jihatidan bir-biridan farq qiladi. Endi bu boshqa kun uchun boshqa mavzu.
Durability – ishonchlilik
Tranzaksiya muvaffaqiyatli yakunlangani haqida xabar berilganida tranzaksiyadagi o'zgarishlar to'liq diskda saqlangan bo'lishi va ma'lumot yo'qotilmasligi kerak.
Masalan, do'stingizga muvaffaqiyatli pul o'tkazganingiz haqidagi xabar olganingiz va shu vaqtda serverda xatolik chiqib, o'chib qoldi. Qayta yoqilgandan keyin balansingizni tekshirganingizda esa pul o'tkazishdan oldingi, eski qiymatni ko'rdingiz. Demak, tranzaksiya muvaffaqiyatli deb belgilangan bo'lsa ham natijalar o'chib ketgan. Xuddi shu holat esa durability qoidasini buzadi.
Qisqasi, mana shu 4 ta qoida ma'lumotlar buzilishi bilan bog'liq ko'p bosh og'rig'idan saqlaydi.
Maqola foydali bo'lgan bo'lsa tanishlarga yuborib qo'ying.
@boboshersnotes
Hali tugallanmagan trakzaksiyadagi ma'lumotlar tashqaridan (boshqa tranzaksiyalardan va tranzaksiya tashqarisidagi boshqa operatsiyalardan) izolyatsiyalanishi kerak. Ya'ni tranzaksiya tugamagunicha ichkaridagi ma'lumot tashqariga ko'rinmasligi kerak.
Masalan, tepadagi misolda hisobingizdan pul yechildi, lekin hali do'stingizga tushmadi. Shu vaziyatda, hali tranzaksiya tugamasidan balansingiz tekshirilganida kamaygan qiymat emas, tranzaksiyadan tashqaridagi, oldingi qiymat ko'rinishi kerak.
To'liq izolyatsiya ko'p resurs va vaqt talab qilgani uchun va doim ham to'liq izolyatsiya zarur bo'lmagani uchun tranzaksiya izolyatsiyasining 4 ta standart darajalari bor. Ular tezlik, resurslar sarfi va xavfsizligi jihatidan bir-biridan farq qiladi. Endi bu boshqa kun uchun boshqa mavzu.
Durability – ishonchlilik
Tranzaksiya muvaffaqiyatli yakunlangani haqida xabar berilganida tranzaksiyadagi o'zgarishlar to'liq diskda saqlangan bo'lishi va ma'lumot yo'qotilmasligi kerak.
Masalan, do'stingizga muvaffaqiyatli pul o'tkazganingiz haqidagi xabar olganingiz va shu vaqtda serverda xatolik chiqib, o'chib qoldi. Qayta yoqilgandan keyin balansingizni tekshirganingizda esa pul o'tkazishdan oldingi, eski qiymatni ko'rdingiz. Demak, tranzaksiya muvaffaqiyatli deb belgilangan bo'lsa ham natijalar o'chib ketgan. Xuddi shu holat esa durability qoidasini buzadi.
Qisqasi, mana shu 4 ta qoida ma'lumotlar buzilishi bilan bog'liq ko'p bosh og'rig'idan saqlaydi.
Maqola foydali bo'lgan bo'lsa tanishlarga yuborib qo'ying.
@boboshersnotes
👍32
Oramizda backend engineer (preferably, Python stack) position uchun mock technical interview qiladigan engineerlar bormi?
Ko'p skillarim "zanglab" qolayotgandek tuyulayapti.
Biror vakansiyaga topshirib ko'rsam ham bo'ladi, lekin hozircha ish joyimni o'zgartirish niyatim yo'q. Baribir ishga kirmasam, bekorga ularning resursini olish to'g'ri deb hisoblamayman.
Ko'p skillarim "zanglab" qolayotgandek tuyulayapti.
Biror vakansiyaga topshirib ko'rsam ham bo'ladi, lekin hozircha ish joyimni o'zgartirish niyatim yo'q. Baribir ishga kirmasam, bekorga ularning resursini olish to'g'ri deb hisoblamayman.
👍21😢2
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
👍11👎1
Ertaga Yangi O'zbekiston Universitetida DevFest bo'layotganidan xabaringiz bo'lsa kerak. Imkoningiz bo'lsa albatta keling, bir chashka kofe ustida suhbatlashamiz.
👍39👎6🍾4