buni tuzdim. Wu usul eng optimalimi?🙂

id larni yig'masdan Category objectlarni o'zi bilan ishlasangiz ham bo'ladi.

Balki, sizning queryingiz more effectivedir.

Birinchidan, katta ehtimol bilan objectlar bilan ishlaganda hamma columnlar fetch qilinadi. Bizga esa faqat id kerak. Demak, biz olgan dataning katta qismi keraksiz.

Ikkinchidan, objectlar bilan in ishlatilganda sql queryda albatta, id ishlatiladi. Lekin iterabledagi objectlardan id aynan qanday ajratib olinishidan xabarim yo'q. Balki ORM levelda iteration bo'lar, balki boshqacha. Anig'ini bilmayman.

#javob
MemoryError dasturingiz ishlashi uchun RAM yetmay qolganda sodir bo'ladi. Hozir siz katta ehtimol bilan katta hajmdagi ma'lumotlarni to'g'ri pythonga chiqarib(bunda ma'lumot to'liq RAMda saqlanib turadi) ishlashga harakat qilayapsiz. Bu biror fayl yoki database bo'lishi mumkin.
Yaxshisi, hamma ma'lumotni bittada olmasdan, bir qismini olib, u bilan ishlab bo'lgach, xotirani bo'shatib keyingi qismga o'tib va h.k. ishlang.

Databasedan fetch qilayotgan bo'lsangiz limit va offsetdan foydalanib paginationga o'xshash narsa qilib ko'ring.

Loop ishlatib foydalanuvchilarga bo'lib-bo'lib jo'nating.

Fetch qilingan ma'lumotlar RAMda saqlanadi.
SELECT * FROM users;
query resultlarini fetch qilsangiz users tabledagi hamma ma'lumot RAMga ham copy qilinadi.

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.