Ajoyib voqealar bo'ladida😅
Yosh avlodning umidini puchga chiqarishadi

Doimiy dizayn: toʻgʻri qurilgan, toʻgʻri turibdi.

Qayta yozilgan qancha proyektlarni koʻrdik. Doimiy yechimlar qilish nasib qilsin.

@it_suhbat

4 bosqichli 500 ta 4 KB page(block) saqlay oladigan tarmoqlanish faktori(branching factory)ga ega B-tree 256 TB ma'lumotni saqlashi mumkin.

Bu degani 4 marta 500 talik page'larni o'qib chiqishning o'zi bilan tahminan 1.6 trillion kalitlar ichidan qidiruv amalga oshirish mumkin.

Mana nima uchun index tezlik beradi.

@it_suhbat

Bloom filter

Asosan LSM-tree (Log Structured Merge-tree) ga asoslangan ma'lumotlar bazasida qidirilayotgan key bor yoki yo'qligini O(1) tezlikda aniqlab beradigan kuchli va foydali qurol.

Tarkibiy tuzilishi
— n uzunlikdagi bitlar massivi
— k ta hash-funksiya

Qanday ishlaydi?
DB ga qo'shilayotgan key k marta heshlanadi va natija bilan mos bo'lgan bitlar massividagi indekslar 1 bilan to'ldiriladi.
Keyingi safar key qidirilayotganda key k marta heshlanib, mos indekslardagi qiymat tekshiriladi, agar birortasi 0 bo'lib qolsa, demak bunday key DB ga umuman qo'shilmagan.

Nima uchun ishlatiladi?
Umuman DB da yo'q bo'lgan key kelganida ortiqcha harakat qilib tekshirib chiqish o'rniga, qo'shilmagan bo'lsa qaytarib yuboradi. Ustunlik tomoni shu yerda.
Agar bor bo'lsa, keyin kirib tekshiradi.

Bilish muhim
Tekshiruv false negative, ya'ni agar yo'q bo'lsa, umuman yo'q.
False positive holati ham bor, ya'ni bor desa ham, ehtimol bor, balki qidiruv payti chiqmasligi ham mumkin.

@it_suhbat

Tasavvur qilaylik, siz ma'lumotlarni qayergadir yozib ketayapsiz. Bu — ma'lumotlar ombori. Yangi yozuvlar tushaveradi, tushaveradi va albatta, qachondir ularni o'qish ham amalga oshiriladi.

Ma'lumotlarni o'qishda ma'lum filtrlar ishlatiladi. Bu filtrdagi shartlarni tekshirib chiqish uchun har bir element ketma-ket tekshiriladi. Bunday tekshiruv uslubi esa yaxshi emas(( Ma'lumot ko'paygani sari qidiruv sekinlashib boraveradi(O(n)).

Mana shu joyda ma'lumotlar omboridan bizga kerakli yozuvlarni tez o'qib olish uchun ketma-ket qidiruv emas, boshqacha yondoshuv kerak. Buning uchun biz yozilayotgan ma'lumotlarni maxsus ma'lumot tuzilmasi — index'ga joylab ketamiz...

@it_suhbat

Kema yasashda kema okeanga chiqishga tayyorlanib yasaladi.
Mana bu yerida teshik bor, buni yaxshilab yopish kerak deyilsa, hozir quruqlikdamiz, suv kirgani yo'qku degan gap qabul qilinmaydi.
Ertaga bu kema okeanga chiqadi. Teshiklarni quruqlikda yopib olish kerak.

@it_suhbat

Oylik maosh qanday beglilanadi?

Deylik xususiy kompaniya HR menejer ishga olmoqchi. Avvalo moliyaviy holatini hisobga oladi. Yani ko'rpasiga qarab oyoq uzatadi. Ikkinchi navbatda bozordagi holatga qaraydi. Biroq barcha hisob-kitoblarni ostin-ustin qiladigan bitta omil bor, bu siz keltirayotgan qiymat. Agar siz katta qiymat keltira olsangiz, o'griqlarga yechim bo'la olsangiz siz xohlayotgan oylik maosh beriladi.

Oylik maoshni ko'tarish bo'yicha ham kirganingizda xuddi shunday vaziyat. Bu yerda savol biroz o'zgarishi mumkin. Siz yo'q bo'lsangiz kompaniyada nima o'zgaradi?

Oylik maosh belginayotganda va oshirilayotganda shaxsiy ehtiyojlar hisobga olinmaydi. Bu masalada ishlaydigan qoida bor: "Avval beriladi, keyin so'raladi".

Yuqoridagi savollarga javobingiz ijobiy bo'lsa, yaxshi oylik maosh so'rashdan uyalmang!

Java 21 + PostgreSQL 16 + Spring Boot 3.3.3
OS: Ubuntu 24.04

~700 MB RAM va 7.2 GB xotira talab qilyapti.

Mabodo minimal application ko'tarish uchun qancha joy kerak degan savol bo'p qosa))

@it_suhbat

Index bu — ma'lumot tuzilmasi. Huddi Javadagi HashMap, TreeMap kabi struktura. Ma'lumotlar(ustunlar) aynan biz tanlagan index strukturasiga o'sha index ishlash prinspi bo'yicha joylashadi va qidirayotganimizda bu struktura tezkor qidiruvni amalga oshirishga xizmat qiladi.

Keling, avval index turlari bilan tanishib olaylik, keyin ularning ba'zilari qanday ishlashini ham ko'rib chiqamiz:
— B-Tree index
— LSM-Tree index (NoSQL)
— Hash index
— Bitmap index
— GIN(Generalized Inverted Index)/GiST(Generalized Search Tree)
— Full-text search index va hokazo

Har bir indexning ishlatilish o'rni bor. Misol uchun Hash index faqatgina aniq tenglik(=) so'rovlarida ishlaydi xolos. Between, like, order by kabi buyruqlarda ishlamaydi.
Buning sababi indexning strukturasida. Ya'ni u yozuvlarni tartiblangan(sorted) holda saqlamaydi.

Vaziyat va ishlatilish o'rniga qarab o'zingizga mos index turini tanlashingiz to'g'ri yechim bo'ladi.

@it_suhbat

B-Tree indeksi qanday ishlashini tushunish uchun avval u qanday tuzilma ekanligini o'rganib chiqamiz.

Demak, shu paytgacha biz asosan Binary Tree tuzilmasi bilan ishlaganmiz, tanishmiz. Daraxt ildizi(root) va undan eng ko'pi bilan 2 ta tugun(node), huddi shuningdek, bu tugun ham eng ko'pi bilan yana 2 ta bola tugunga ega bo'lishi mumkin.

B-Tree farqli ravishda, tugunlarda bir nechta elementlar saqlaydi va bolalari ham bir nechta bo'lishi mumkin. Tugunlardagi elementlar tartiblangan holda saqlanadi. Bolalarining bog'lanishi ham tartib bilan: chap tomonga kichik elementlar, o'ng tomonga kattalari. Elementlar intervallar bo'yicha saqlanadi.

Bu qidiruv samaradorligini oshiradi. Avval tugundagi elementlar ichidan binar qidiruvni amalga oshiradi. Tugun ichida bo'lmasa, mos intervaldagi bolalariga(keyingi tugunga) o'tib qidiradi. Bargga yetgunicha shu ish amalga oshiriladi.

@it_suhbat

Index ko'rinishida esa B-Tree tugunlari(nodes) ma'lum hajmli blokka aylanadi(page ham deyiladi). Odatda, 4 KB. PostgreSQL da 8 KB.

Blok ko'rinishida ma'lumotlarni diskdan o'qib olish qulay. Bu indexni yanada tezlashtiradi.

Page o'zida qancha qiymat saqlay olishi fanout deyiladi. Fanout qancha bo'lishi kalit(key) turiga bog'liq. Agar u Integer bo'lsa, 4 bayt. Unga qo'shimcha yana tupleId — 8 bayt, tuple header ~ 8-16 bayt, umumiy bitta key uchun 20-30 bayt joy egallaydi.
Fanout esa tahminan 300 bo'ladi. Ya'ni bitta page o'ziga 300 ta keyni sig'dira oladi.

Tasavvur qilaylik, bizda 1 mlrd key bor. U holda B-Tree chuqurligi log300(10^9) bo'ladi. Bu ~ 3.634 = 4 bo'ladi.

Ya'ni eng ko'pi bilan 4 ta page o'qib 1 mlrd kalitlar ichidan qidiruvni amalga oshirish mumkin.

Bu juda tez ⚡️

@it_suhbat

Mono.zip

Bu method ikki producer(Mono)larni birlashtirib beradi. Ikkalasi ham onNext hodisasini yuborganidan keyin, natijalarni Tuple2 holatida qaytaradi.

Shu yerda muhim bir jihat bor! Agar Mono.zip(p1, p2) operatordagi p1 yoki p2 bo'sh qiymat qaytarsa(Mono.empty()), operator ham hech narsa qaytarmaydi. Ya'ni zipdan keyin siz kutayotgan tuple qaytmaydi!

Chunki tuple yasash uchun p1 va p2 ning onNext signallari kutiladi, ikkalasidan birining signali bajarilmasa, natija ham bo'lmaydi.

Bu holatga e'tibor bermasangiz, juda katta mantiqiy uzviylik yo'qotilishi va soatlab debuggingga duch kelishingiz mumkin :)

Manfaatli bo'lsa, reactive yozadigan sheriklaringizga ulashib qo'ying.

@it_suhbat

Algoritmlashni o'rganmoqchilar uchun xolis tavsiya

o'sha kun keldi)) Spring security darslarini YouTube kanalimdan topishingiz mumkin. Alohida playlist qilib joylab qo'ydim. Birinchi video ancha avval yozilgan, shunchaki spring boot haqida qisqacha ma'lumot o'rnida. Videolar o'zim tomonimdan yozilgani va montaj qilingani sababli biroz no professional ko'rinishi mumkin🫠 qo'limdan kelganicha xarakat qildim.

Ilm ulashish hech qachon to'xtab qolmaydi. Yaxshi odamlar bor ekan, u davomiy bo'laveradi.