hammasini bitta table da saqlasak, har safar fetch qilganda ularni hammasini emas, filter qilib ma'lum bir qismini olsak tezlikda o'zgarish bo'lmaydimi?

Yaxshi savol.

Querylarning "kayfiyat"iga qarab ba'zi yechimlarni sinab ko'rish mumkin:

1. Indexing. Querylarni analiz qilib ko'ring. Shunga qarab kerakli columnlarga indexlar qo'shing. Agar zarur bo'lsa non-key value attach qiling.

2. Pagination(PostgreSQL)

3. Agar indexing yetarlicha natija bermasa sal murakkabroq usulni sinab ko'ring: Horizontal partitioning.
Bu usul katta tableni bir nechta kichik tablelarga bo'lishdan iborat.

4. Partial indexing. Google qilib ko'ring. Lekin bu usul implement qilishga qiyinroq va ehtiyot bo'lib ishlatmasangiz teskari natija berishi mumkin.
Upd: Partial indexing orqali siz kutgan natijani olish qiyinroq.
Bo'pti, bu variantni chiqarib tashlang.

P.S. Yuqoridagilarning har birida pros&cons bor.

yangi yangilik qo'shilganini qanday bilib olaman?

Databasega event trigger qo'shing.
Shunda har safar databasega bog'liq biror oparation bajarilganda(CREATE, UPDATE, ...) trigger o'zidan "signal" chiqaradi. O'sha signalni tutib olib, xohlagan ishingizni qilishingiz mumkin.

Boshqacha, soddaroq yo'llari ham bor. Masalan, har safar saytdagi har bir post databaseda bor-yo'qligini tekshirish. Lekin bu yaxshi fikr emas, ayniqsa databaseda minglab postlar bo'lsa.

Django bilan ishlab ko'rganlar django signalsdan xabardor bo'lsa kerak. Bu ham event trigger bilan bir xil vazifa bajaradi. Faqat django signals ORM levelda implement qilingan.

databasega bog'liq tablega bog'liq

#savol#savol djangoda qilingsan web saytlar bor 50 60ta ularni hammasiga bir xil ma'lumot qoshiladi. shu saytlarga bitta bitta yangilik qoshmasdan birdaniga hammasiga qoshiladigan qilsa boladimi

Message queue ishlating.

bazalari bir bolishi kerakmi shunda aytilgandaqa

Yo'q, shart emas.
Pub/sub pattern ishlatasiz.
Ya'ni bitta service o'ziga yangilik qo'shilganda buni queuega e'lon qiladi(publish). Queuega "obuna"(subscribe) qilgan boshqa servicelar bundan xabar topadi va ular ham newsni o'zidagi databasega qo'shib qo'yadi.

Bu xuddi telegramdagi kanallarga o'xshash. Kanal admini yangi post qo'shsa kanaldagi obunachilar bundan xabar topadi va shunga qarab ish qiladi.

@all_about_django_uz
Bu yerda django bo'yicha yaxshi ma'lumotlar topishingiz mumkin.

Savol ozgina noto'g'ri bo'ldi.
Umumiy javob:
GET va POST requestda ham serverga ma'lumot yuborish mumkin.

Farqi:
POST requestda yuborilganda data requestning body qismida, zarur bo'lsa, shifrlangan holda yuboriladi.
Shuning uchun sensitive data, ya'ni shaxsiy ma'lumotlar, parollar,... POST request tarkibida yuboriladi. Requestni kimdir yo'lda tutib olsa ham, ma'lumotni qo'lga kiritish uchun deshifr qilish kerak bo'ladi.

GET requestda esa umuman, body qismining o'zi yo'q. Shuning uchun ma'lumot urlning tarkibida, parameter sifatida o'tadi.
Bu usul bilan asosan, muhim bo'lmagan, elementar ma'lumotlarni serverga uzatishda foydalaniladi.
Masalan, pagination yoki search queryda.
Data URL tarkibida shunchaki ochiq turgani uchun sensitive datani yuborsangiz, requestni tutib olgan kishi ochiq ma'lumotni qo'lga kirita oladi.

#py
a = [1, 2, 3]
b = a
c = a.copy()
a[2] = 4
print(a, b, c)

Subscriberlar orasida ozgina skill share qilamiz.
Yuqoridagi kod(va natija)ni explain qilmoqchi bo'lganlar, marhamat, commentda fikr qoldiring.

Celery bu task queue.
Ma'lum tasklarni aytilgan vaqtda bajarib turadi.
Deylik, sizda bir qancha user bor va har kuni soat 8:-00 da har bir userga email jo'natishingiz kerak.
Agar buni asosiy threadga yuklab qo'ysangiz, u boshqa ishlarn qila olmaydi. Har kuni aytilgan vaqtda aytilgan ishni qiladi va qolgan vaqt faqat kutadi. Dasturingizning qolgan qismi ishlamaydi(sababi, u faqat kutayapti), ya'ni thread blokanadi.

Celery esa mana shunday vaziyatlarda yordamga keladi. Bajarishi kerak bo'lgan taskni alohida yozib, uni celeryga schedule qilib qo'ysangiz bo'ldi. Dasturning boshqa qismlariga halaqit bermasdan aytilgan tartibda ishlayveradi.


Redis bu in-memory database. Ya'ni ma'lumot saqlaydi, faqat, odatiy DBMS(masalan, PostgreSQL)larga o'xshab disk, ya'ni doimiy xotirada emas, memory, ya'ni RAMda saqlaydi.
In-memory database haqida bu yerda qisqacha aytganman.
RAM bilan ishlash diskka nisbatan ancha tez bo'lgani uchun tezlik muhim joylarda ishlatiladi. Masalan, caching yoki real-time chat.

Hozir RedisLabs Redisni faqat in-memory database sifatida emas, boshqa maqsadlarda ishlatishni ham taklif qilayapti. Ko'p yangi imkoniyatlar qo'shilayapti. Saytidan batafsil ko'rishingiz mumkin.

SOLID tamoyillari

SOLID - bu dasturiy ta'minotni ishlab chiqish uchun 5 ta muhim tamoyil hisoblanadi.

S — Single Responsibility

Misol uchun bizda User classi mavjud. Agarda User classi ko'p vazifalarga ega bo'lsa, u xatolar ehtimolini oshiradi. Sababi User classining biror bir qismi o'zgarsa, boshqa qismlarining o'zgarishiga olib kelishi mumkin. Single Responsibility tamoyilining asosiy maqsadi alohida qismlarga ajratib ishlashga qaratilgan. Misol uchun User classining ikkinchi darajali metodlari alohida yangi classga o‘tkaziladi.

O — Open Closed

Bu tamoyilda class kengaytirishlarga ochiq, o'zgarishlarga esa yopiq bo'lish kerak. Misol uchun bizda qandaydir class mavjud bo'lsa va u classning biror bir metodiga yangi imkoniyat qo'shilsa, o'sha classning metodiga shartlar qo'yib yana uni test qilish uchun hamma qismini test qilishga to'g'ri keladi. Open Closed tamoyilining asosiy maqsadi shu holatni oldini olish. Yani class biror metod bo'lsa va yangi imkoniyat qo'shilganda yangi class yaratilib u asosiy classning metodidan foydalaniladi. Shunda biz faqatgina oxirgi qo'shgan imkoniyatimizni test qilishga erishamiz.

L — Liskov Substitution

Bu tamoyilga binoan ota class bajara oladigan amallarni bola class ham bajara olish kerak. Agar bola class ota class bajara oladigan amallarni bajara olmasa xatolik yuzaga kelishi mumkin. Tasavvur qiling, Vehicle degan ota class bo'lsa, Car va Bus class'lari bola class hisoblanadi. Endi Liskov Substitution tamoyiliga binoan Car va Bus ham Vehicle bajara olgan amallarni bajara olishi kerak yoki bir xil turdagi natijani berishi kerak.

I — Interface Segregation

Foydalanuvchi o'ziga kerak bo'lmagan interface'dan foydalanishga majbur bo'lmasligi kerak. Bu tamoyilga binoan umumiy interface'lardan ko'ra bir qancha kichik interface'lar afzalroq. Tasavvur qiling, dasturdan foydalanuvchilarning ba'zilari uchun qandaydir metod kerak bo'lib qoldi. Ammo biz asosiy interface'ni o'zgartirsak qolgan foydalanuvchilar uchun bu metod mavjud bo'lib qoladi, zero ular foydalanishni hohlamasalar ham. Bunday holatda Interface Segregation'ga amal qilgan holda asosiy interface'dan meros olib yangi metodni qo'shib kerak bo'lgan foydalanuvchilarga taqdim etamiz. Shunda har bir foydalanuvchi o'ziga kerak bo'lgan interface'dan foydalanadi. Va xatoliklar chiqishi ehtimoli kamayadi.

D — Dependency Inversion

High-level level'dagi modullar low-level modullarga qaram bo'lib qolishi kerak emas. Misol uchun Notification class'i mavjud bo'lsa send message va send email metodlari notification'ga emas balki biror bir abstraction'ga tegishli bo'lishi kerak. Yani send message hamda send send email metodlari Messaging class'iga tegishli bo'lishi kerak va Messanging class'i esa Notification class'iga bog'langan bo'lishi kerak.

Maqola foydali bo'lgan bo'lsa do'stlaringizga ulashing!

@usmon_masudjonov

Ma'lumotlar bazasi (database) nima va u nima uchun kerak?

Deyarli barcha turdagi dasturlar ma'lumotlar bilan ishlaydi. Ma'lumotlarni saqlaydi, o'zgartiradi, o'chiradi va hokazo.

Database (DB) bu shu ishlarni tartibli va samarali usulda qiladigan tizim/dastur.

"Lekin, ma'lumotlarni o'zgaruvchilarda, hashmaplarda, arraylarda ham saqlash mumkinku" deyishingiz mumkin. To'ppa to'g'ri. Ularda ham saqlash mumkin.

Muammo shundaki, ular ma'lumotlarni RAMda saqlaydi va dasturingiz/programmangiz to'xtatilishiga u ma'lumotlar yo'qoladi.

"Agar to'xtatmasakchi? Buni ilojisi borku". To'g'ri. AWS, GCPlarning serverlariga qo'yilsa, shunday qilsa bo'ladi. Ularda svet o'chmaydi. Har qalay serverlari bizda Andijonning Shaxrihon qishlog'ida joylashmagan. Lekin, Amerikalarda ham to'fonlar bo'lib turadi ;) To'xtamagan taqdirda ham RAM odatda chegaralangan bo'ladi.

Demak bizga boshqa bir ma'lumotlarni saqlash usuli kerak.

"Ha, text fayllarda saqlasak bo'ladi" deysizmi? To'ppa to'gri! Kundalikni olib keling.

Muammo shundaki text fayllar yetarlicha murakkab dasturlar uchun to'g'ri kelmaydi. Chunki fayllarda muammolar (synchronization, security va hokazo) ko'p. Hullas ular ma'lumotlar bazasi sifatida ishlatishga mo'ljallanmagan.

Shuning uchun ham mahsus ma'lumotlar bazasi o'ylab topilgan.

Ular fayl shaklida bo'lishi mumkin. Masalan SQLite. Shunda sizning dasturingiz to'g'ridan to'g'ri shu fayl shaklidagi database bilan muloqot qiladi.

Bunday databaselar kichik dasturlar uchun yaxshi qo'l kelishi mumkin. Lekin murakkab dasturlar uchun bunday ma'lumotlar bazasi to'g'ri kelmaydi.

Unday dasturlar uchun boshqa bir dastur ko'rinishidagi databaselar kerak. Bunday databaselarga PostgreSQL, MySQL va SQL Serverlarni misol qilib aytishimiz mumkin. Shunday sizning dasturingiz shu database dasturlar bilan muloqot qiladi. Bu databaselar esa o'zlarining ichida bir nechta fayllarni optimal tarzda boshqaraveradi.

Sizning dasturingiz fayllar bilan gaplashmaydi.

Ana endi savol tug'iladi. SQLite, PostgreSQL va boshqalar bilan dasturlar qanday gaplashadi? Buning uchun computer scientistlar mahsus til o'ylab topgan: SQL. Bu haqida endi boshqa postda bo'ladi.

@JakhonRakhmonBot