Docsda aytilishicha, in-memory database bilan ishlarkan. SQLite3da in-memory database bilan ishlamaganman, lekin in-memory database haqida umumiy aytaman:

Bu turdagi databaselar odatdagidek diskda(HDD, SSD) emas, to'laligicha RAMda saqlanadi. Ishlash vaqtida doimiy xotira(storage) bilan aloqa qilish va natijani kutishga hojat yo'q. Hammasi RAM va CPU o'rtasida sodir bo'ladi. Shuning hisobiga oddiy relational databasedan bir necha yuz barobar tezkor va ancha "yengil".

Odatda, SQL oilasidagi(MySQL, PostgreSQL) databaselar storageda saqlansa, NoSQL(MongoDB,...) va NewSQL(MemSQL,...) databaselar deyarli har doim memoryda saqlanadi.

Qachon ishlatiladi?

Tezligi yuqori bo'lgani uchun caching uchun keng ishlatiladi.

Real-time data bilan ishlaganda ham in-memory database yordam beradi. Masalan, hozir biz yozishib turgan telegram chat. Agar PostgreSQL ishlatilganda xabarlar bizga ancha kech yetib kelardi.

Real-time analyse uchun. Ba'zan tarmoqdagi kutilmagan holatlardan vaqtida xabar topmaslik katta muammolarni olib keladi. Masalan, DDos'ga qarshi tizim ma'lumotlarni tezkor analiz qilishi uchun oddiy MySQL juda sekin.

Kamchiliklari:

Butun ma'lumotlar bazasi RAMda saqlangani uchun oddiygina tizimning qayta yuklanishi yoki serverda elektr o'chib qolishi(😅) hamma ma'lumot yo'qotilishiga olib keladi. Buning oldini olish uchun replication qilinadi. Ya'ni in-memory databasedagi ma'lumotlar sekin-sekin storagedagi database(masalan, PostgreSQL)ga ham yozib boriladi. Agar ma'lumotlar o'chib ketsa, qattiq diskdagi nusxadan qayta tiklanadi.

Assalomu alaykum.
Do'stim, guruhda sizni anchadan beri kuzataman. Umuman olganda, to'xtab qolmayapsiz, har doim harakat qilayapsiz, bu juda yaxshi albatta.

Lekin e'tibor berdingizmi, borgan sari guruhda savollaringizga kamroq javob berishyapti. Negaligini o'ylab ko'rdingizmi?

Gap shundaki, siz faqat bitta manbaaga bog'lanib qolayapsiz. Dasturlashda har kuni o'nlab muammolarga duch kelasiz. Har bitta muammoni guruhdan so'rash esa yaramaydi. Bu birinchidan guruhdagilarga yoqmasa, ikkinchidan bitta manbaaga bog'lanib qolish kelajakda o'zingizga bir dunyo muammolar olib keladi.
Real projectdagi har bir muammoni guruhdan so'ramaysizku, axir.

Googling is a skill.
Siz googleni ishlata olmayapsiz. Siz docsni o'qimayapsiz. Siz stackoverflowdan javob izlamayapsiz. Vaholanki, bu xatoga duch kelgan faqat siz emas va bu savollarning 99% qismiga allaqachon javob topib, taxlab qo'yishgan. Sizning vazifangiz o'sha javoblarni izlab topish.

Yana bir narsa, django(va ko'pchilik boshqa texnologiyalar ham) shu darajada foydalanuvchi uchun qulay yozilganki, xatolik xabarida hammasi yozib qo'yilgan. Ozgina aqlni ishlatib, muammoning asl sababini topish kerak. Xatoliklarni tushunib, analiz qila olish juda muhim. Xatolikning sababini tushunish uning yarmini hal qilishga teng deyishadi. Siz esa hozircha bu narsalarga deyarli e'tibor bermayapsiz.

Umid qilamanki, tepadagilardan xulosa chiqarib, kamchiliklaringiz ustida ishlaysiz.
Mening sizga hech qanday xusumatim yo'q. Maqsadim, faqat yordam berish.

Djangoning o'zida ajoyib ORM borligi sabab ras query yozish yoki boshqa ORM ishlatishga hojat yo'q. Menimcha siz oldin SQLAlchemy bilan ishlagan bo'lsangiz kerak.
Django ORMda har bitta database table alohida class sifatida yoziladi va har bitta class(table) model deb ataladi(ko'pchilik boshqa ORMlardagidek).

Xuddi boshqa ORMlardagidek har bir column(field) class attribute bo'ladi.
Django ORMda ko'plab built-in field typelar bor. Xuddi databasedagi VARCHAR, INT, ... kabi.

Model classda tablening o'zi yaratiladi. Siz tepada yozgandek ma'lumot to'g'ridan to'g'ri kiritilmaydi. Masalan:

class Task(models.Model):
name = models.CharField(max_length=60)
description = models.TextField()
status = models.BooleanField(default=False)

Demak, biz Task nomli table yaratib, unga 3 ta ustun qo'shdik.

Tablega ma'lumot qo'shish esa ModelManager orqali qilinadi. Bu model classga tegishli ma'lumotlarni boshqaruvchi boshqa "nazoratchi" class.

ma'lumot olish:
task = Task.objects.get(id=2)

ma'lumot kiritish:
Task.objects.create(
name="Hello",
desc="Demo",
status=True,
)

Yoki
task = Task(
name=...
...)
task.save()


Payqagan bo'lsangiz, objects bu yerda manager. Ya'ni u class objectlarini boshqarayapti.

Ma'lumotlarni bir turdan boshqasiga o'tkazuvchi "adapter".

Masalan, django bilan ishlaganimizda biz deyarli hech qachon raw SQL query yozishimizga to'g'ri kelmaydi.
Biz model va model managerlar orqali hammasini Pythonda turib qilamiz. ORM esa bizning Pythondagi buyruqlarimizni analiz qilib, SQL queryga o'tkazib, databasega yuboradi.
Yoki ma'lumot olganda ham biz toza pythonda query yuboramiz. ORM uni raw queryga o'tkazib databasedan natijani oladi va natijani bizga yana python object ko'rinishida beradi.

Qisqasi, ORM dasturlash tilining o'zida turib database bilan ishlashni ta'minlaydi.

Asyncio texnik jihatdan single thread.
Faqat bitta event loopda bir nechta coroutinelarni yurgizadigan bitta thread ishlaydi.

I/O bound workloadda thread-based concurrency ishlatish unchalik ham yaxshi g'oya emas. Sababi, thread ko'p vaqtni APIdan response kutish bilan o'tkazadi.
Async-based concurrency esa o'sha vaqtdan unumli foydalanishga yordam beradi.

Assalomu alaykum, agar database engineeringga qiziqsangiz va bu sohada hali bilimingiz boshlang'ich bo'lsa, Udemyda Hussein Nasserning "Introduction to database engineering" kursini sotib olishni tavsiya qilaman. Husseinning shaxsiy saytiga kirsangiz kurs uchun promokodlar bor. $10-15 atrofida sotib olishingiz mumkin(original narxi $90 edi adashmasam).

Umuman olganda, bu yigitning Youtubededagi kanaliga qarab ko'rsangiz ham juda ko'p foydali content topasiz. O'zim ham har bitta uploadni kuzatib boraman.

Ha aytgancha, database engineering yoki, umuman, backend engineering bo'yicha savollaringiz bo'lsa @Bobosher_Musurmonov'ga yozavering. Qo'ldan kelgancha javob beraman.

Hamma OSni o'z qarichi bilan o'lchaydi 😁
P.S. Frontendchi backend dardin qaydan bilsin...

Bitta connectionni ma'lum sondagi transaction(yoki query)lar uchun, ma'lum vaqt uchun yoki connection ishdan chiqqunicha ham ishlatish mumkin.

Lekin har bitta transaction uchun bitta connection ochib, transaction tugagach yopish ancha xavfsiz va shu bilan birga "qimmat". Har bir connectionni ochib-yopishga vaqt ketadi. Agar qandaydir fail chiqsa keyingi transaction uchun yangi connection ishlatib ketaverasiz.

Django ORM default holda har bitta transaction uchun bitta connection ochadi.

Tutorial Hell Haqida

Dasturlashni endi boshlaganingizda, yoki boshqa tilni o'rganishni boshlaganingizda, "tutorial hell"ga tushib qolishingiz ehtimolligi katta.

"Tutorial hell" o'zi nima? "Tutorial hell"da siz tekst yoki video ko'rinishida tutorial topib, ko'r ko'rona avtor nimani qilishni aytsa o'shani qilish bilan vaqt o'tkazishingiz. Ya'ni siz uchun oldindan har qadam yozib qo'yilgan. Siz shunchaki "copy and paste" qilsangiz yetarli. Dasturingiz ishlab ketaveradi.

Natijada siz o'zingizni nimadir qilgandek his qilasiz va shunday tutoriallarni topib qilishda davom etasiz. Lekin o'zi asli ko'p narsa o'rganmagan bo'lasiz. Har bir qadamda sizga nima qilishni aytib turishlariga o'rganib qolasiz va oddiygina dastur yaratish so'ralsa qiynalib qolishingiz mumkin. Qo'pol qilib aytganda "tormoz" bo'lib qolshingiz mumkin.

Tanish holatmi?

Iloji boricha bu holatdan chiqishingiz kerak. Qanday qilib? O'zingiz qandaydir dasturcha qilishdan boshlang. Tutoriallarga qaramang. Har bir "feature"ni o'zingiz oldindan o'ylab, qurishga harakat qiling. Qo'pol qilib aytganda miyani ishlating. Shundagina sizda dasturlash skillari rivojlanadi. Ishga kirganda sizga har bir qadamni aytishga majbur bo'lishsa siz juniordan uyog'iga o'tolmaysiz.

Tajriba yo'q bo'lib qanday dasturlar qurish mumkinligi haqida oldinroq gaplashgandik.

@jakhonrakhmon

Offtopic uchun uzr.

DTM va mandat haqida o'ta shaxsiy fikrlarim:

Rahbariyat aybdormi?
— Ha, va eng ko'p. Negaki, yaxshigina infrastruktura ko'tarish uchun DTMda yetarlicha mablag' bor.
Shunchaki kattagina server va yaxshi mutaxassislar jamoasini topish yetarli. To'laqonli JAMOA. Kuchli etwork engineer, backend engineer, security engineer, database engineer, sysadmin, ...
Katta ehtimol bilan sizlarda bu narsalarning hammasi uchun alohida mutaxassis yo'q. Masalan, siz backend developers va databasega bog'liq ishlarni ham o'zingiz qilasiz.

Dasturchilar aybdormi?
— Ha. Chunki, necha yillardan beri tizim faqat update qilinadi. Buglar fix qilinib yangi featurelar qo'shiladi.
DTM kabi katta tashkilot uchun monolithic server strukturasidan voz kechib allaqachon microservicesga o'tish payti kelmadimi?

Hatto rps eng katta bo'lganda ham 5-6 K dan oshishiga ishonmayman. Va bilishimcha DTMning serveri buncha stressni ko'tara oladigan darajada kuchli. Demak optimize qilish orqali ham natijani yaxshilash mumkin. Workerlar sonini ko'paytirish, database querylarni optimallashtirish(zarur bo'lsa, ORMdan voz kechish), cachingni yaxshilash. Shu bilan hammasi yaxshi bo'lsa, bu ajoyib, lekin muammo databasega borib taqalsachi? Sharding? Menimcha foydasiz.
Yaxshisi, yangitdan microservices strukturasini qurish kerak.

IMHO

Yaxshi maslahat:
O'sha requestlar "avjiga chiqqan" vaqtda serverni kuzatib ko'ring.
Qaysi qism ko'proq zo'riqayapti?
Application server or database server?

Tushunarli, rahmat.
Shunchaki, querylarning katta qismi read ekanini hisobga olib, 2-3 ta read replica qo'shish orqali database performanceni yaxshigina oshirish mumkinligini eslatib qo'ymoqchiman.
Bu RDMSlarning "underrated" featurelaridan biri.

Others:
Babe, you're the most beautiful girl in the world.

Me, a database engineer:
Babe,
SELECT * FROM girls
ORDER_BY beautifulness DESC
LIMIT 1;
constantly returns you.

#en #db #fun

Sizni database engineeringga qiziqtirishi mumkin bo'lgan ba'zi savollar:

1. Nega primary key bitta tableda bittadan ko'p bo'lmaydi?

2. Deylik, telegram bot yasayapsiz va userlarning telegram_id va ismini saqlamoqchisiz. Odatda, tableda bu ikki columndan tashqari id primary key ham bo'ladi. Agar primary key uchun alohida id column qo'shmay, telegram_id'dan primary key sifatida foydalansak nima bo'ladi?

3. Deylik, user1 ning hisobidan user2 ning hisobiga mablag' o'tkazmoqchisiz. Bu database levelda mana bunday bo'ladi:
check: user1.hisob > summa
user1.hisob -= summa
user2 hisob += summa
Savol: Agar 2-qator bajarilgandan keyin biror sabab bilan qolgan operatsiya bajarilmay qolsa nima bo'ladi? Ajoyib-a?

4. Agar 2 ta thread bir vaqtning o'zida bitta valueni o'zgartirmoqchi bo'lsa nima bo'ladi?

5. Index search time complexityni yaxshilar ekan, nega endi hamma columnga index qo'sha olmaymiz?

5. Nega databasega faqat read replica qo'shish mumkin, write replica esa yo'q?


Bu savollar dengizdan tomchi xolos.
Aynan mana shunga o'xshash "Nega?" Va "Qanday?" savollar meni database engineeringga qiziqtirib qo'ygan.

Database deganda ko'z oldiga faqat table keladiganlar uchun maxsus :-)

Agar maqsad jihatidan to’g’ri joyda ishlatilsa, Go rostdan ham tez ishlaydi. Lekin aynan shu joyda xato qilmaslik kerak — ya’ni tilning o’rnini bilgan holatda ishlatish kerak. Go ishlatiladigan joyda Java’ga o’rin bo’lmasligi mumkin. Bundan tillarni solishtirish noto’g’ri fikrligi kelib chiqadi.

Sun’iy testlarda solishtirganda — albatta Go tez ishlaydi, o’rtada VM bo’lmagani hisobiga. Lekin bu degani Go Java’ni to’laqonli o’rnini bosa oladi degani emas.

Olma bilan bannani solishtirgandek gap. Ikkalasi ham meva, ikkalasi ham birdek shirin, lekin banan uzunchoq, olma yumaloq. Bu bilan olma qulayroq yoki banan qulayroq degan fikrga odamzod hech qachon bormaydi. O’z o’rnida ishtahasiga qarab birini yeb ketaveradi.

Let's learn Go together!
https://golangbot.com/learn-golang-series/
#en #golang #learn

database'da juda ko'p ma'lumot bor (row). Lekin ularni hammasini strukturasi bir xil. O'shalarni bitta table da saqlagan yaxshimi yoki bir nechta table da saqlagan yaxshimi? Yoki farqi yo'qmi?

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