Otabek’s I/O

Vohid aka bilan podkastda
intervyu haqida gaplashgandik va
F5
kompaniyasi intervyusidan yiqilib, Networking'ni N harfini bilmasligimni bilgandim deb aytgan edim. O'sha intervyudan juda ko'p (rostan ham ko'p) xulosa va tajriba olganman.
Express Networking
kursida bular haqida bo'lishib borayabman. Sizga yana bir ajoyib mavzuni o'rgatib va
F5
kompaniyasiga bo'lgan intervyudan yiqilganimdan olgan tajribamni bo'lishishga qaror qildim. Bu darsni ham bepul ko'rishingiz mumkin.
Bu darsda sizga
nslookup
va
dig
kabi dasturlarni RFC o'qib qurishni amaliy o'rgatib kod yozib berganman.
👉
42.uz/course/express-networking/udp-tezkor-kuryer

Internet ortidagi mo'jizani o'zingiz tushunib, va o'rgangan bilmlar asosida ularni qayta ixtiroq qilishni istaysiz. Ammo qayerdan boshlashni bilmaysizmi?
- DNS query
- HTTP protokoli
- Xavfsiz va tezkor API
- Sniffing tool (hacking uchun)
- Speedbumper
- Proxy (Nginx ga o'xshagan)
- Ngrok (Tunneling service)
- Real-time tizimlar (oz resurs, ko'p connection)
- ... va h.k.z larni 0dan quramiz (kutubxonalarsiz)
Bu yerdan boshlasangiz bo'ladi:
42.uz/course/express-networking
Hacking va Security bo'limida o'rgatilgan barcha bilm va amaliyotlarni faqat yaxshi yo'lda sarflaysiz deb umid qilaman

#event
1 Dekabr kuni Inha universitetida ma’ruza qilaman. Qiziqsangiz bu yerda ro’yhatdan o’ting, sizga batafsil telefon raqamingizga manzil va vaqtlari yuboriladi. Qiziqtirgan savollaringizga birga javob topamiz va yaqindan tanishamiz:
👉
Ro’yhatdan o’tish

Lectures
Barcha ochiq ma'ruzalarimni videolarini shu yerda kuzatsangiz bo'ladi.
Batafsil
👉
otabek.io/lectures

Concurrency Control
,
Double booking problem
uchun bir necha xil yechimlar,
Cursor
,
Security
, va boshqa chqur mavzular backend dasturchilar uchun juda muhim. Ularni bilish yaxshi, tushunib ishlata olish undanda yaxshiroq.
Deep Dive
bo'limidan yana bir darsni ochib qo'ydim. Uni
bepul
ga kursni sotib olmasdan ham ko'rishingiz va yangi bilmlar olishingiz mumkin.
Eng ko'p beriladigan savollarga javob sifatida:
Express Database
kursi bir texnologiyaga va faqat SQL tiliga bog'liqligi yo'q. Bu kursda ma'lumotlar ombori (RDBMS) bo'yicha bilmlar ko'proq. Kurs har qanday darajaga to'g'ri keladi, ha 0dan o'rgatadi. Distributed System haqida ham tushunchalar yoritilgan, sabab arxitekturik qarorlarni to'g'ri qabul qila olishga o'rgatish.
Batafsil
👉
42.uz/course/express-database/random-topics/

#shortBlog
Isolation
ma'lumotlar omborini go'zal tamoyillaridan biri deb bilaman. Bir nechta tranzaksiya bir-birini blok qilib qo'ymasligi uchun ajoyib yechimlar qilingan. Sezganingizdek
Pessimistic Locking
va
Optimistic Locking
mexanizmlari haqida gap ketayabdi.
Pessimistic Locking
Tranzaksiya A
obyektni o'qishi yoki yozishidan oldin. Unga (Lock) qulf qo'yadi. Agar
Tranzaksiya B
o'sha obyektni ustida biror ish qilmoqchi bo'lsa, uni tugashini va qulfni olib tashlashini kutishi kerak bo'ladi. Bu yechimni yomon tomoni, agar ko'p tranzaksiyalar bir-birini kutib qolsa (
Deadlock
), tizim qotib qolishi mumkin.
Optimistic Locking
Multi-Version Concurrency Control
mehanizmi yuqoridagi muammoni yanada yaxshiroq yechish uchun qilingan. Men uni
Time Travel
deb atayman. Nega unday? Chunki biz
multi dimension
olamda yashaybamiz (quantum physics aytishi bo'yicha). Bu yechimdagi go'zallik, DB barcha tranzaksiyalar qilgan o'zgarishlarni saqlab boradi. Qachonki
Tranzaksiya A
boshlansa, DB hozirgi holatidan "
Snapshot
" oladi.
Tranzaksiya B
ham boshlanib, biror qiymatni o'zgartirsa, u ham o'zidagi versiyani o'zgartirgan bo'ladi.
Tranzaksiya A
ga hech qanday zarar o'tmaydi.
Read
qilayotganlar ham,
Write
qilayotganlar ham bir-birini blok qilmaydi.
Bu ikkisi ham trade-off.
Pessimistic Locking
'da tizimni qotirib qo'yishingiz mumkin bo'lsa,
Optimistic Locking
'da juda ko'p xotira ishlatishni boshlaysiz. Undan tashqari Timestamp Ordering, 2PL, SSI, DCC, Token-Based / Lease-Based kabi yechimlar ham bor. O'rganishni maslahat beraman. System Design intervyularda o'qigan kitoblaringiz emas, texnik bilmlaringiz va ularni ishlata olishingiz ko'proq azq otadi.

Build Your First Model
O'zingizni ilk Machine Learning modelingizni yaratib ko'rishni o'ylaganmisiz? Unda ushbu blog siz uchun. Nimalarni o'rganamiz?
· Machine Learning ortidagi Matematika siz o'ylaganchalik qiyin emasligini
· Modelni 0dan, hech qanday kutubxonalarsiz qurishni (kodingizni
otabek.io
da sahifada ishlatib ko'rsangiz bo'ladi)
· Va weight ni topishni turli xil yo'llarini ko'rib o'tamiz.
Ushbu blogdan keyin biror yaxshiroq erkin loyiha qila olishingizga ishonaman. Sinab ko'ring
Batafsil:
otabek.io/blogs/build-your-first-model

Har qanday loyiha ma'lumotlar bilan ishlaydi. Va ma'lumotlar omborini tushunish tizimni eng kerakli qismini tushunishdan iborat.
Shu paytgacha topishgan ba'zi kompaniyalarimda ma'lumotlar ombori haqida qiziq muhokamalar olib borganmiz. Ba'zilarida men intervyu oluvchiga o'rgatganman. Ya'na ba'zilarida intervyu oluvchidan o'rganganman (ya'ni uni savoliga javob bera olmay, keyingi intervyuga javob topib borganman).
Ulardan ba'zilar:
- Siz biror table'ni index qildingiz, ammo undan ma'lumot olmoqchi bo'lganingizda index'dan qidirmayabdi? Bunda nima qilasiz?
- Tasavvur qiling siz ko'p tranzaksiyalar bajaruvchi tizmda ishlaysiz. Ikki va undan ko'p tranzaksiya bir vaqtda bitta row'ni yangilashga urinsa (update) nima qilasiz? Qaysi qiymatni qabul qilishni qanday qaror qilasiz?
- Trazaksiya paytida biror xodisa yuz bersa, ammo ma'lumotlar ombori COMMIT qilganizni tasdiqlasayu ammo ma'lumotlar yo'qligiga guvoh bo'lsangiz nima qilasiz?
- Primary Key va Secondary Key o'rtasida nima farq bor? Ularni qachon ishlatmagan bo'lardingiz?
- Database recover qilgan paytingiz haqida gapirib bering? Qanday backup qilgansiz? Nima uchun unday qilgansiz? Va recover process qanday bo'lgandi? Zarar nimada bo'lgandi?
- Izolyatsiya darajasi REPEATABLE READ'da bo'lsa ham, siz PHANTOM READ'dagi o'zgarishlarni ko'ra olasiz. Ammo nega ekanligni tushuntirib bering?
- Column vs Row DBlar o'rtasidagi farq nimada?
- Sizda 1 millardlik jadval bor. U tez-tez yangilanib turadi. Qatorlar sonini xisoblash uchun nima qilasiz? (Materialized View va denormalization o'rtasidagi trade-offs)
Bu savollarga javob topish uchun ba'zi ochiq va yopiq darslarni ko'rib chiqishingiz mumkin:
42.uz/course/express-database
To’liq kurs 1 Dekabr oyida chiqadi. Hozir ulgurib qoling, keyin narx o’zgaradi.

#experience
Kodingiz 1 millisecond'da 23 000 qator record (ma'lumot)larni ustida operatsiyani bajarish qanchalik zo'r? Kecha bir kodni ko'rdim va hamksablar bilan gaplashganimdan beri bu ko'rsatkich sekinga aylanib qoldi. I love Distributed Systems
😢
.
Kecha java'dagi Math.pow() funksiyasini optimizatsiya qilishganini ko'rib qoldim. Bu unchalik muhim bo'lmasa kerak deb o'ylagandim, adashibman. Hozir kod 100x tezroq ishlayabdi ekan. Ishonmay benchmark ham qilib ko'rdim (eski va yangi change'larni farqini bilishga). Awesome!!!
Okay bu haqda blog yozishga arziydi lekin kanalda 2k reader (follower) bo'lsak bu haqida albatta yozaman. Hozircha bu sizga challange sifatida qolaqolsin. Btw, bu muammoni men yechmaganman, lekin men ham shunday yechgan bo'lardim.

#experience
Bir qiziq
bug
'ni tuzadim. Bizda code base monorepo holida saqlanadi. Ya'ni hamma kodlar bitta repo'da saqlanadi. Bu holda kodlarni test qilish, build qilish, va hokazo operatsiyalarni qo'lda bajarish yoki ularga pipeline yozib ularni boshqarish qiyinlashib boradi. Bunga yechim incremental build systems ishlatish.
Incremental build system ham oddiy dasutr, faqat u kodlaringizni o'zgarishini, dependency control, qaysi qismda o'zgarish bo'lsa faqat o'sha qismni build, test qilishni belgilay oladi. Tasavvur qiling Google, Meta, Dropbox kabi tizmlarda hamma dasturlarni kodlari bitta joyda (monorepo holida) saqlanadi.
Build System alohida Linux machine'larda ishlab turadi. O'zgarishlar bo'lsa kodlar o'sha mashinaga boradi, test, build qilinadi va keyin shunga qarab natijalar bizga ko'rinadi. Bir kun build system service OOM (out of memory) bo'lib qoldi. Memory
swap
qilishni boshladi. Lekin biz u servislar uchun ajratgan resurslarimiz yetishi kerak edi. Borib tahlil qilishni boshladim. 64GM RAM umumiy xisobda. Hammasi yaxshi. 48GB ram qaysidir process tomonidan ishlatilayotganini ko'rdim. Va yana 16GB OS filesystem cache ham bor edi. OS filesystem cache ni doim tozalay oladi. Lekin bu holatda nimaga swap qilayotganini tushuna olmadim.
swappiness
degan narsa haqida google qilib o'rgandim. Agar
swappiness
qiymati baland bo'lsa swap qilishni boshlar ekan. Bizdagi config 2 ko'rsatayotgan edi va men uni
sysctl vm.swappiness=1
ga set qildim. Lekin shunda ham swap qilishda davom etaverdi. Swapni o'chirib qo'ydik, ancha ahvol yomonlashdi. Process'lar OOM berishni boshladi. OOM berganda Linux uni kill qiladi (to'xtatadi). O'zimga "why? why?" deb bir idea kelib qoldi.
Esingizda bo'lsa docker minimal versiyasini yasab ko'rganim haqida aytgandim. Ha o'sha tajriba qo'l keldi. Hamma gap
cgroup
da edi. Buni rostligini tekshirish uchun
dmesg
ni tekshirdim, voila javob topildi. Bug topildi. Aynan bizga kerakli ishlab turgan process'lar limiti past bo'lgan cgroup ga tushib qolganini ko'rib ich-ichimdan xursand bo'lib ketdim. I wanted to scream like "Technologia, I found the bug".
Ba'zan qilgan eksperimentlarim ko'p azq otadi. Peace!
Updated: Bu voqeaga ancha bo'lgan lekin hozir yozgim kelib qoldi. Balkim shu ham promoga yordam bo'lgandir, who knows