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?

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.