Title: String interning
To alleviate memory that can be quickly consumed by strings, Python implements string interning
— A string will be interned if it is a compile-time constant, is not the production of constant folding or is not longer than 20 characters, and consists exclusively of ASCII letters, digits, or underscores.
—Empty strings are interned.
Source

#savol

Ko'pchilik vakansiyalarda Django va birorta SQL yozilgan bo'ladi.

Django ORM turganda SQL o'rganishim kerakmi?

Misol uchun Postgresql ni o'rgansam uning men uchun pro taraflari nima buladi.

Yoki SQL ni shunchaki ORM qanday ishlayotganligi haqida tasavvurga ega bo'lish uchun o'rganishim kerakmi?

Yaxshi savol. Avvalroq meni ham o'ylantirgan. Shaxsiy tajribamdan kelib chiqib ba'zi narsalarni aytaman:

1. ORM database emas. U bizga ma'lumotlarni qanday bersa, biz shunday qabul qilamiz. Kimdir Django ORMni yaxshi tushunishi va shu bilan birga RDBMS haqida hech narsa bilmasligi mumkin. Ma'lumotlar aslida qanday saqlanishi va uni qanday ishlatishni bilmaslik db haqida noto'g'ri tasavvurlarga, demakki notog'ri yoki o'ta foydasiz usullardan foydalanishga olib keladi.

2. Django ORM ancha kuchli bo'lsa-da albatta chegaralangan. Shunday vaziyatlar bo'ladi-ki, ORM ish bermaydi. O'sha vaziyatlarda raw query yozishga to'g'ri keladi.

3. ORMga bog'lanib qolish djangodan boshqa texnologiyalar bilan ishlaganda katta qiyinchiliklarga olib keladi. Dasturchi sifatida faqat django bilan cheklanish yaxshi emas.

4. DB engineering bu shunchaki table va data emas. Bu butun boshli soha. Uning ham ichida bir dunyo usullari, sir-sinoatlari bor(indexes, replication, sharding, CC, ...). Ma'lumotlar bilan to'g'ri ishlay olish loyihangiz bilan qulayroq ishlash va eng yaxshi optimizatsiyalarni qilishga imkon beradi.

5. "Qanday ishlatish"dan ko'ra "qanday ishlashi"ni tushuna olish ko'p imkoniyatlar beradi.

Assalomu alaykum, e'tibor uchun rahmat.

Gap shundaki, multithreading aslida I/O uchun ishlab chiqilgan. CPU-bound uchun esa multiprocessing. Maqolada multithreading CPU-bound uchun deganimning sababi, agar multiprocessing deganimda unda process nima, threaddan qanday farq qiladi va h.k.larni tushuntirish kerak bo'lardi. Xullas, out of topic. Shuning uchun tinchgina multithreading degandim(sababi, tepada threat tushuntirilgan).

Endi savolingizga qaytsak. Multithreading aslida async chiqishidan oldin IO-bound workload uchun ishlab chiqilgan. Async chiqishi bilan uning qadri ancha pasaydi. Sababi, CPU-bound uchun deyarli foydasiz(pythonda GIL "o'lganning ustiga tepgan qiladi"), IO-bound uchun esa async effectiveroq. Xullas, deyarli keraksiz bo'lib qoldi. Har holda, end-user developerlar uchun. Framework developerlar esa ko'p ishlatishadi. Asinxron ishlash noqulay va multiprocessing keraksiz joyda.


Demak siz va biz uchun:
- CPU-bound workloadda multiprocessing;
- IO-bound workloadda async.
RIP multithreading :-)

Asyncioning kamchiliklaridan biri, task tayyor bo'lsa ham "navbat"i kelgunicha bajarilmay turadi.
Restoran misolida, ofitsant boshqa ishlarni bitirib kelgunicha ovqat tagiga olib ketishi mumkin.

Mana shunday kechikishi kerak bo'lmagan joylarda thread ishlatish mumkin.
Masalan, ko'p frameworklarda requestlarni kutib turish uchun alohida thread ochilib turadi. Request kelishi bilan "ichkariga" uzatadi.
Agar asinxron ishatilsa, boshqa tasklar bajarib bo'lingunicha requestlar kutib qolishi mumkin. Multiprocessing esa "ortiqcha harajat". Yaxshisi, thread ishlatamiz.

Savol:
man bir joyiga unchalik tushunmayman, qilayotgan projectimizda aynan qaysi paytda async dan foydalanishimiz kerakligini qanday aniqlab olishni va async ni ishlatish kerakmi yo multithreading ishlatish kerak, asinhirinni ishlatishni ham o'zini qonin qoidasi bo'lsa kerak, shulani yaxshilab o'rganib olishim kerak

Buyog'iga savol egasi ko'rsatilmaydi :-)

Keyingi maqola qaysi mavzuda bo'lishini xohlardingiz?

#savol
Assalomu alaykum database transaction haqida tushunarliroq ma'lumot kerak edi.

Deylik, siz do'stingizning hisobiga $100 o'tkazmoqchisiz. Database levelda bu taxminan mana bunday bo'ladi:
1. Hisobingizda $100 dan ko'p mablag' borligini tekshirish.
2. Sizning hisobingizdan $100 kamaytirish.
3. Do'stingizning hisobiga $100 qo'shish.

Deylik, 1 va 2-bosqichlar bajarilgandan keyin hali 3-bosqich tugatilmasdan biror sababga ko'ra xatolik chiqdi yoki server vaqtincha o'chib qoldi. Bunda nima bo'ladi?
Siz $100 yo'qotdingiz, lekin do'stingiz qabul qilmadi.

Mana shunday holatlarning oldini olish uchun database transaction o'ylab topilgan. Bu xuddi qutiga o'xshaydi. Ichiga querylar solasiz va execute qilasiz. Agar hammasi yaxshi bo'lsa unda commit qilinadi, ya'ni natijalar actual tablega o'tkaziladi. Agar bitta transactiondagi birorta queryda xatolik chiqsa qolgan querylarning ham natijalari bekor qilinadi(rollback).

Bir kishi hamma uchun, hamma bir kishi uchun deganlaridek ...

#savol
topSkills = profile.skill_set.exclude(descriptionexact="") shu kodda "exact" ni vazifasi nima ?

exact lookup oddiy tenglik bilan bir xil vazifani bajaradi.
Siz User.objects.get(id=10) deb yozsangiz bu User.objects.get(id__exact=10) bilan bir xil bo'ladi.

Unda exact nega kerak degan savol tug'ilishi mumkin. Gap shundaki, django ORM SQL query tayyorlayotganda SELECT statement uchun mana shu lookuplardan WHERE clauseda foydalanadi.

Batafsil:
https://docs.djangoproject.com/en/3.2/ref/models/querysets/#field-lookups

#savol GIL O'zi nima kim qanday malumotga ega tushuncha berib yuboringlar menda internet tezligi 13 B/s Google ning ochaolmayabman iltimos😢🧐😊

#javob

GIL nima va nega kerakligini tushunish uchun concurrency nima, lock nima, nega kerak, dead lock nima, qanday oldini olish mumkin va h.k. lar haqida ozgina ma'lumot olish kerak.

Concurrency bu bir nechta thread(oqim)larning bitta processorda ishlashi. Umuman olganda, threadlar processorda juda kichik instructionlarga ajratilib(Assemblyga o'xshash), navbatma-navbat bajariladi. Bu instruksiyalar juda kichkina bo'lgani va processor bir soniyada bunaqa instruksiyalardan milliardlab bajargani uchun bizga xuddi bir vaqtda ishlayotgandek taassurot qoldiradi.

Concurrency paytida ba'zi o'zgaruvchilarni ikkita thread bir vaqtda o'zgartirishi, buning orqasidan noto'g'ri natijalar kelib chiqishi mumkin(masalan, a=0 o'zgaruvchiga 2 marta 1 qo'shib, natija 1 chiqishi mumkin). Mana bu race condition deyiladi.

Race conditionning oldini olishning bir usuli sifatida lock o'ylab topilgan. Lockning ishlashi quyidagicha: biror thread biror o'zgaruvchining qiymatini o'zgartirmoqchi bo'lgan paytda uni "qulflab" qo'yadi. Shunda o'zgaruvchini bir vaqtda faqat bitta thread o'zgartira oladi. Bu qiymatni olmoqchi bo'lgan boshqa thread qulf ochilishini kutib, ochilgandan keyin yangi qiymatni olib ishlataveradi.

Lock juda yaxshi yechim, lekin bitta jiddiy muammosi bor. Deylik, bitta thread a o'zgaruvchini "lock" qilgan va b ning qiymatini olmoqchi. Ikkinchi thread b ni "lock" qilgan va a ning qiymatini olmoqchi. Shunda ikkita thread yopiq sikl hosil qilib bir-birini qulflab qo'yadi. Bu esa dastur o'sha joyda "tiqilib qolishi"ga olib keladi. Mana bu holat "dead lock" deyiladi.

Pythonda xotira boshqaruvi avtomatik bajariladi. Ya'ni qaysidir qiymat ishlatilmasa, python uni avtomatik aniqlab, xotiradan bo'shatadi. Buni amalga oshirish uchun python reference count degan narsadan foydalanadi. Sodda qilib aytganda, o'sha qiymatdan necha kishi foydalanayotganini sanab turadi. O'sha raqam 0 ga tushganda(demak, hech kim ishlatmayapti) garbage collector o'sha qiymatni xotiradan o'chiradi.

Race condition hamma joyda sodir bo'lishi mumkin. Shu jumladan reference countda ham. Lekin bu yerda sodir bo'lsa kerakli ma'lumotlar o'chib ketishi yoki keraksiz ma'lumot xotirada qolib ketishi kabi muammolar kelib chiqadi. Buning oldini olish uchun Python reference count uchun ham lock ishlatadi. Lekin yuqorida aytilganidek, dead lock muammosini ham hisobga olish kerak. Shuning uchun Python hamma uchun bitta GIL(Global Interpreter Lock) ishlatadi. Bu ham oddiy lock kabi ishlaydi, lekin u interpreterda saqlanadi. Qaysidir thread biror o'zgaruvchini o'zgartirmoqchi bo'lsa interpreter GILni o'sha threadga vaqtinchalik berib turadi. Thread esa undan o'zgaruvchini emas, uning qiymatidagi reference countni qulflashda foydalanadi. Ishini tugatib bo'lgach, u GILni yana interpreterga qaytaradi va interpreter GILni boshqa threadga beradi...
Butun interpreterda bitta GIL bo'lgani uchun dead lock sodir bo'lmaydi. Sababi, qulf bitta, hech kim bir-birini qulflab qo'ymaydi.

Demak, GIL bizning dasturimizdagi o'zgaruvchilar bilan bo'ladigan race conditionning oldini olish uchun emas, Pythonning ichki, xotira boshqaruv tizimi to'g'ri ishlashi uchun xizmat qiladi.

Nima topib olganimni ko'ring 🙂
https://www.cs.usfca.edu/~galles/visualization/Algorithms.html

#savol
Assalomu alaykum, hammaga!

Postgresqlda replikatsiya bo'yicha savol:

replikatsiyani maqsadi performance'ni oshirish ya'ni yagona serverga yuklama ortib ketib, uni ishlashi sekinlashmasligi uchun ishlab chiqilgan desak, master-slave o'rtasida sinxronizatsiya paytidagi jarayon(masterdan slave'ga yozuv yozish) performance'ga qanchalik ta'sir qiladi?

Assalomu alaykum, database replicationdan asosiy maqsad read(SELECT)larni tezlashtirish. Masalan, 1 ta slave 10 k QPSga (faqat read) aktiv javob bera olsa, 3 ta follower slave qo'shish orqali bu tezlikni 3 marta tezlashtirish mumkin.
Xuddi API leveldagi load balancerga o'xshab.

Replication write(INSERT, UPDATE, DELETE)larni yaxshilamaydi. Shu bilan birga deyarli sekinlashtirmaydi ham. Sababi, master slavega yangi record yozilganda boshqa slavelar ham copy qilishini kutib(sinxronlash), master slavedagi asosiy threadni block qilmasdan, bu haqida qolganlarga xabar berib, ishini davom etadi. Follower slavelar esa bu recorddan xabar topib, o'zlariga yozib qo'yadi.
Bu qaysidir taraflama EDAga o'xshab ketadi.

Database replication aslida real-time emas. Sababi, record master slavega yozilgandan keyin hamma followerlar sinxronlangunicha millisekundlar vaqt ketadi. Shuning hisobiga data inconsistency kelib chiqishi ehtimoli yo'q emas(o'sha millisekundda follower slaveda read query execute bo'lsa). Lekin buning ehtimoli juda kam.

Bu yerda bir narsani aytish esimdan chiqibdi.
Master nodega yangi record yozilganda followes nodelarni kutib o'tirmasdan, ishida davom etishini yozdim. Bu asinxron yozish usuli. Lekin bundan boshqa usullari ham bor.

Sinxron usulda yozilganda client follower slavelar yozib bo'lgunicha bloklanib turadi. Bu asosan, data consistencyni ta'minlash uchun. Yana boshqa sabablar ham bor.
Sinxron yozishni ham turlicha configure qilsa bo'ladi.
Masalan, ixtiyoriy 1 ta, 2 ta n ta replica yozib bo'lishi bilan blokni ochish, aynan a, b replicalar yozib bo'lgandan keyin bo'shatish va h.k.

Writelarni scale qilish uchun multi-master replication bor. Lekin rostini aytsam, bu implement qilish uchun biroz qiyin va conflictlar kelib chiqishi ehtimoli ancha yuqori.

#savol
Webhook nima va qanday qulayliklar yaratib beradi?