#savol
Why HTTP/3 uses UDP instead of TCP?
#javob
I think the main reason why HTTP/3 (which uses QUIC) is built on top of UDP instead of TCP is to solve the problem with lost packets in HTTP/2.
One of the biggest problems with h2 is that streams (a logical communication for a single request) are not fully independent from each other. Since the TCP retransmission works on layer 4 of the OSI model but h2 itself is implemented on layer 7, the TCP connection has no knowledge of h2 streams. So if a single TCP packet is missing in one of the streams, TCP blocks the entire connection (thus, all the streams on it) till the missing packet is retransmitted successfully.
That means, if I try to send 10 request at the same time over h2 and if any of them fails to reach, all 10 requests are blocked. This is called HOL blocking, but on the transport layer.
HTTP/3 solves this problem by using QUIC, which is built on top of UDP. Since UDP does not guarantee delivery of data, it has no retransmission mechanism. QUIC has its own recovery mechanism that guarantees delivery. Unlike TCP, this recovery mechanism works on the same layer as the QUIC streams and knows which packet belongs to which stream. That's why if any packet is lost, the recovery mechanism blocks only the stream that packet belongs to. It does not affect other streams.
Why HTTP/3 uses UDP instead of TCP?
#javob
I think the main reason why HTTP/3 (which uses QUIC) is built on top of UDP instead of TCP is to solve the problem with lost packets in HTTP/2.
One of the biggest problems with h2 is that streams (a logical communication for a single request) are not fully independent from each other. Since the TCP retransmission works on layer 4 of the OSI model but h2 itself is implemented on layer 7, the TCP connection has no knowledge of h2 streams. So if a single TCP packet is missing in one of the streams, TCP blocks the entire connection (thus, all the streams on it) till the missing packet is retransmitted successfully.
That means, if I try to send 10 request at the same time over h2 and if any of them fails to reach, all 10 requests are blocked. This is called HOL blocking, but on the transport layer.
HTTP/3 solves this problem by using QUIC, which is built on top of UDP. Since UDP does not guarantee delivery of data, it has no retransmission mechanism. QUIC has its own recovery mechanism that guarantees delivery. Unlike TCP, this recovery mechanism works on the same layer as the QUIC streams and knows which packet belongs to which stream. That's why if any packet is lost, the recovery mechanism blocks only the stream that packet belongs to. It does not affect other streams.
👍5
Forwarded from Nuruddin Blogs
Hamma narsani o’rganish uchun retsept - qiziquvchanlik.
Kung fu pandada lag’monni sehrli siri ham shu bo’lgan menimcha )
@nuruddinblogs
Kung fu pandada lag’monni sehrli siri ham shu bo’lgan menimcha )
@nuruddinblogs
👍7
Bruce akadan PostgreSQL indexlar haqida ajoyib talk. Oxirigacha ko'rishni tavsiya qilaman.
https://youtu.be/QQ1eyBcphEs
https://youtu.be/QQ1eyBcphEs
YouTube
Flexible Indexing With Postgres - Bruce Momjian - EDB - Percona Community Live - PostgreSQL tutorial
When considering database indexing, many people are confused by the many #Postgres indexing structures available, and the many data-type-specific index lookup methods. This talk explores the various #indexing features of Postgres and when to use them.
Like👍…
Like👍…
👍1
Forwarded from Sardor Dushamov | PHP - tengi yo'q til!
Inkapsulyatsiya
Inkapsulyatsiyaga misol:
- Shashlik yemoqchisiz, shashlikchini oldiga bordingiz
- Mana 2 kg go'sht,1kg qiyma,1kg jaz shashlik bo'lsin
- Go'shtni berasiz, u sizga tayyor shashlik qilib beradi
Nimasi inkapsulyatsiya?
- Shashlikchi - Class
- Unga go'sht berasiz - constructor
- Shashlikka qo'shiladigan ziravorlar - property
- Shashlik qilish uchun myasarovkadan chiqaradi, marinovka qilish, muzlatadi - bular methodlar
- Shashlikga qo'shadigan ziravori bor, uni faqat shashlikchi biladi - private property
- Shashlik sixdan oqib tushmaslik uchun xxx ishni qiladi, bu ham uni siri - private method
- Shashlikchi shu sirlarini faqat farzandlariga o'rgatgan, ular ham bu shashlik qilish usulidan foydalanishadi - protected method
Siz shashlikchini qanday tayyorlaganiyu nimalar qo'shganini, hammasini bilolmaysiz, lekin shashlik tayyor.
U shu private va protected sirlarini tashqariga chiqarishni xohlamaydi - manashu inkapsulyatsiya, ya'ni sirlarini himoyalaydi.
Xato misol bo'lsa iltimos to'g'rilang.
Inkapsulyatsiyaga misol:
- Shashlik yemoqchisiz, shashlikchini oldiga bordingiz
- Mana 2 kg go'sht,1kg qiyma,1kg jaz shashlik bo'lsin
- Go'shtni berasiz, u sizga tayyor shashlik qilib beradi
Nimasi inkapsulyatsiya?
- Shashlikchi - Class
- Unga go'sht berasiz - constructor
- Shashlikka qo'shiladigan ziravorlar - property
- Shashlik qilish uchun myasarovkadan chiqaradi, marinovka qilish, muzlatadi - bular methodlar
- Shashlikga qo'shadigan ziravori bor, uni faqat shashlikchi biladi - private property
- Shashlik sixdan oqib tushmaslik uchun xxx ishni qiladi, bu ham uni siri - private method
- Shashlikchi shu sirlarini faqat farzandlariga o'rgatgan, ular ham bu shashlik qilish usulidan foydalanishadi - protected method
Siz shashlikchini qanday tayyorlaganiyu nimalar qo'shganini, hammasini bilolmaysiz, lekin shashlik tayyor.
U shu private va protected sirlarini tashqariga chiqarishni xohlamaydi - manashu inkapsulyatsiya, ya'ni sirlarini himoyalaydi.
Xato misol bo'lsa iltimos to'g'rilang.
👍23
Forwarded from Programming ∀
Frameworklar ko'p holatlarda biror ishni osonlashtirish uchun ishlab chiqilgan yoki ishlab chiqiladi. Lekin juda ko'p frameworklar antipatterlar asosiga qurilgan. To'g'ri u nimadurni yaxshilaydi nimaduni osonlashtiradi samaradorlikni oshiradi deyiladi. Lekin ko'p holatlada qo'pol ravishta patternlar va prinsplarga zid ishlar qilinadi. Notogri ideologyni imrove qiladi. Masalan ko'p frameworklada controller tushunchasi mavjud. Bu narsa handler vazifasini bajaradi. OOP tomonlama qarasa bu holatda class qandaydur protseduralar yegindisi bo'lib qoladi )) Yoki boshqacharoq misol:
DTO tushunchasi. Getter va setterlar yegindisi. Bu component yoki layer ko'p holatlarda shunchaki protseduralar yegindisiga aylanadi. Object o'z hususiyatlarini yoqotadi.
DTO tushunchasi. Getter va setterlar yegindisi. Bu component yoki layer ko'p holatlarda shunchaki protseduralar yegindisiga aylanadi. Object o'z hususiyatlarini yoqotadi.
👍2
Programming ∀
Frameworklar ko'p holatlarda biror ishni osonlashtirish uchun ishlab chiqilgan yoki ishlab chiqiladi. Lekin juda ko'p frameworklar antipatterlar asosiga qurilgan. To'g'ri u nimadurni yaxshilaydi nimaduni osonlashtiradi samaradorlikni oshiradi deyiladi. Lekin…
Shaxsiy fikrim:
Ha, ko'pchilik frameworklar antipatternlar asosiga qurilgan va bu ma'lum darajada asosli.
Agar frameworklar to'liq biz bilgan toza konseptlar asosida yozilganida ular orqali minimal "ishlaydigan" kod yozish hozirgidan ko'ra ancha qiyin bo'lgan bo'lardi.
$20 ga bozordan sifati meni qoniqtiradigan krossovka sotib olsam, Nike meni ularning san'at asari darajasida ishlab chiqilgan $200 turadigan krossovkasini sotib olmaganim uchun ayblay olmaydi. Sababi, menda o'sha mahsulotga ehtiyoj va yetarli mablag' yo'q. O'zim olgan mahsulot sifat va narx jihatidan meni qoniqtiradi.
Xuddi shunday, ko'pchilik kichik va o'rta kompaniyalar va ularning tepasida o'tirgan biznesmenlar uchun siz va men qurishni xohlaydigan ideal (yoki shunga yaqin) dastur kerak emas. Buning uchun ehtiyoj va yetarlicha resurs yo'q ularda.
Siz va men ular aytgan resurslar evaziga software ishlab chiqishga rozi bo'lmasak ham, buni qiladiganlar albatta topiladi va bu tabiiy. Keyin sifat ham shunga yarasha bo'ladi.
Ko'pchilik frameworklar esa o'sha "qoniqarli sifatli" software ishlab chiqish uchun arzon yarimtayyor mahsulot. Agar o'sha frameworklardan foydalanib, yuqori sifatli dastur ishlab chiqmoqchi bo'lsangiz, frameworkni anchagina customize qilishingiz kerak va FAANGda ham shunday qilishadi.
Ha, ko'pchilik frameworklar antipatternlar asosiga qurilgan va bu ma'lum darajada asosli.
Agar frameworklar to'liq biz bilgan toza konseptlar asosida yozilganida ular orqali minimal "ishlaydigan" kod yozish hozirgidan ko'ra ancha qiyin bo'lgan bo'lardi.
$20 ga bozordan sifati meni qoniqtiradigan krossovka sotib olsam, Nike meni ularning san'at asari darajasida ishlab chiqilgan $200 turadigan krossovkasini sotib olmaganim uchun ayblay olmaydi. Sababi, menda o'sha mahsulotga ehtiyoj va yetarli mablag' yo'q. O'zim olgan mahsulot sifat va narx jihatidan meni qoniqtiradi.
Xuddi shunday, ko'pchilik kichik va o'rta kompaniyalar va ularning tepasida o'tirgan biznesmenlar uchun siz va men qurishni xohlaydigan ideal (yoki shunga yaqin) dastur kerak emas. Buning uchun ehtiyoj va yetarlicha resurs yo'q ularda.
Siz va men ular aytgan resurslar evaziga software ishlab chiqishga rozi bo'lmasak ham, buni qiladiganlar albatta topiladi va bu tabiiy. Keyin sifat ham shunga yarasha bo'ladi.
Ko'pchilik frameworklar esa o'sha "qoniqarli sifatli" software ishlab chiqish uchun arzon yarimtayyor mahsulot. Agar o'sha frameworklardan foydalanib, yuqori sifatli dastur ishlab chiqmoqchi bo'lsangiz, frameworkni anchagina customize qilishingiz kerak va FAANGda ham shunday qilishadi.
👍12
Forwarded from Programming ∀
#paradigms
Biror dasturiy ta'minotni tuzish uchun xozirgi kunda ko'p holatda juda yuqoridan qaraymiz. Frameworklar tayyor solutionlar pattenlar. Albatta bular muhim ammo juda ko'p xamkasblarda asosiy muammo paradigmalar. Ko'plab dasturchilar uslub, yondoshuvni dasturlash tillaridan olishadi (Shaxsan o'zim ham shu kungacha). Lekin ushbu xolatda bizda bir tomonlama fikrlash juda o'sib ketishi mumkin. Bu esa albatta birkun zararga ishlashi mumkin.
Nega ? Bazi tillarda faqat bir paradigmani tadbiq qilingan. Bu esa umumiy dasturlashni shu doirada ko'rishga o'rgatadi Masalan C. Bazilarida esa multi paradigm lekin juda tartibsiz va sifatiz code yozish extimoli yuqori. Masalan JS. Bazi tillarda til implement qilgan paradimgdan boshqasini tadbiq qila olmaysiz bu bir tomondan juda zo'r boshqa tomondan unchalik emas. Agar shunday bo'lsa JS kabi bo'lish extimoli yurqori.
Yuqorida aytganimday biror muammoga nisbatan berilgan yechim turli yo'llar orqali qilingan bo'lishi mumkin.
Anchadan buyon faqat JS/TS stackda ishlab shu paradigmlar masalasida ko'p chalkashaman. Endi yaxshi expirement boshladim. Paradigmlarni boshqa tillarda o'rganishni boshladim bu narsa ushbu falsafalarni yaxshiroq tushunish va tadbiq qilishga yaxshigina yordam beryabti. Masalan ruby va Java Rubydagi OOP manga ancha yoqdi Javaga qaraganda. Syntax yondoshuv va implementation ancha sugar. Paralell programming uchun esa Go birmuncha yoqdi. Functional programmingni Elixirda sinab ko'rvoman. Bu tajribalar manimcha yillar davomida bo'ladi chunki aniq biror muammoga ushbu bilimlarni tadbiq qilib ko'rish kerak. Lekin bir narsani tushundimki Universal Dasturlash tilining yo'qligiga asosiy sabablardan biri bu paradigmlar ko'pligi. Bu tajribani boshlaganimdan keyin ancha yegilib qolgan savollarga javob topishni boshladim. Lekin xozircha JS/TS dan boshqasida erkin emasman. Manimcha dasturlashni o'rganishda eski classic progamming yoki old school unchalik mos emas xozirgi kunda.
Misol uchun JS bilan OOP o'zini o'rganish birmuncha qiyin yoki design patternlani. Yoki C++ bilan FP ni o'rgana olishiz qiyin. Undan ko'ra aynan OOP yoki FP yaxshiroq tadbiq qilingan tilda o'rgangan yaxshiroq deb o'ylayman. System engineering uchun C ancha qiziq edi manga. Ammo fikrim o'zgardi Rust.
Sizda ham shunday bo'shliqlar bo'lsa qanday to'ldirasiz yoki hali bo'lmagan bo'lsangiz sabringiz yetsa yuqorida yozganimday uslubni tavsiya qilaman.
PS: Ushbu postdan maqsad tillarni yaxshi yomon deb solishtirish emas. Dasturlashni yaxshioq o'rganish va chuquroq tushunish uchun bir uslubni yoritishdan iborat.
PS++: Postda qaysidur tilni yaxshi bilish yoki bilmaslikga davo qilinmagan !!!
Biror dasturiy ta'minotni tuzish uchun xozirgi kunda ko'p holatda juda yuqoridan qaraymiz. Frameworklar tayyor solutionlar pattenlar. Albatta bular muhim ammo juda ko'p xamkasblarda asosiy muammo paradigmalar. Ko'plab dasturchilar uslub, yondoshuvni dasturlash tillaridan olishadi (Shaxsan o'zim ham shu kungacha). Lekin ushbu xolatda bizda bir tomonlama fikrlash juda o'sib ketishi mumkin. Bu esa albatta birkun zararga ishlashi mumkin.
Nega ? Bazi tillarda faqat bir paradigmani tadbiq qilingan. Bu esa umumiy dasturlashni shu doirada ko'rishga o'rgatadi Masalan C. Bazilarida esa multi paradigm lekin juda tartibsiz va sifatiz code yozish extimoli yuqori. Masalan JS. Bazi tillarda til implement qilgan paradimgdan boshqasini tadbiq qila olmaysiz bu bir tomondan juda zo'r boshqa tomondan unchalik emas. Agar shunday bo'lsa JS kabi bo'lish extimoli yurqori.
Yuqorida aytganimday biror muammoga nisbatan berilgan yechim turli yo'llar orqali qilingan bo'lishi mumkin.
Anchadan buyon faqat JS/TS stackda ishlab shu paradigmlar masalasida ko'p chalkashaman. Endi yaxshi expirement boshladim. Paradigmlarni boshqa tillarda o'rganishni boshladim bu narsa ushbu falsafalarni yaxshiroq tushunish va tadbiq qilishga yaxshigina yordam beryabti. Masalan ruby va Java Rubydagi OOP manga ancha yoqdi Javaga qaraganda. Syntax yondoshuv va implementation ancha sugar. Paralell programming uchun esa Go birmuncha yoqdi. Functional programmingni Elixirda sinab ko'rvoman. Bu tajribalar manimcha yillar davomida bo'ladi chunki aniq biror muammoga ushbu bilimlarni tadbiq qilib ko'rish kerak. Lekin bir narsani tushundimki Universal Dasturlash tilining yo'qligiga asosiy sabablardan biri bu paradigmlar ko'pligi. Bu tajribani boshlaganimdan keyin ancha yegilib qolgan savollarga javob topishni boshladim. Lekin xozircha JS/TS dan boshqasida erkin emasman. Manimcha dasturlashni o'rganishda eski classic progamming yoki old school unchalik mos emas xozirgi kunda.
Misol uchun JS bilan OOP o'zini o'rganish birmuncha qiyin yoki design patternlani. Yoki C++ bilan FP ni o'rgana olishiz qiyin. Undan ko'ra aynan OOP yoki FP yaxshiroq tadbiq qilingan tilda o'rgangan yaxshiroq deb o'ylayman. System engineering uchun C ancha qiziq edi manga. Ammo fikrim o'zgardi Rust.
Sizda ham shunday bo'shliqlar bo'lsa qanday to'ldirasiz yoki hali bo'lmagan bo'lsangiz sabringiz yetsa yuqorida yozganimday uslubni tavsiya qilaman.
PS: Ushbu postdan maqsad tillarni yaxshi yomon deb solishtirish emas. Dasturlashni yaxshioq o'rganish va chuquroq tushunish uchun bir uslubni yoritishdan iborat.
PS++: Postda qaysidur tilni yaxshi bilish yoki bilmaslikga davo qilinmagan !!!
👍18👎3
PostgreSQLda index create qilayotganda fillfactor nomli parameter bor. Qisqasi, b-tree page(node)ning qancha qismi to'lganidan keyin bu index pageni to'lgan deb hisoblanib, keyingi pagega yozishni boshlashni bildiradi. Nega 100% to'ldirib, keyin keyingi pagega o'ta olmaymiz? Sababi pageda valuelar tartiblangan bo'ladi, agar tartib bo'yicha shu to'lgan pagega to'g'ri keladigan yangi qiymat kiritilsa, uni shu yerga sig'dirish uchun pageni split qilib, qayta organize qilishga to'g'ri keladi. Bu xuddi arrayning o'rtasiga element qo'shish uchun undan keyingi qismini orqaroqqa surishga o'xshaydi, lekin storege levelda bu yanayam "painful" bo'ladi. Buning oldini ma'lum darajada olish uchun pagening bir qismini oldindan bo'sh qoldirib qo'yish mumkin. Shu pageda turishi kerak bo'lgan yangi qiymat kelganida qolgan valuelarni bezovta qilmasdan, shu yerning o'ziga sig'dirish mumkin bo'ladi.
Index fillfactor index pagening necha foizi to'lganidan keyin yangi pagega o'tishni ko'rsatadi. Default holatda 90%, ya'ni 10% qismi bo'sh turadi. PostgreSQL dokumentatsiyasi bu qiymatni 50-90 foiz oralig'ida ushlashni tavsiya qiladi.
Kamroq fillfactor write operationlar kutilmaganda sekinlashib qolishini kamaytiradi, lekin searchni biroz sekinlashtiradi (fillfactor past bo'lsa, index pagelar soni ko'payadi, ko'proq page ko'proq vaqt degani) va ko'proq joy oladi.
Qachon fillfactorni yuqori qilish tavsiya qilinadi:
1. Tableda write operations juda kam bo'lsa yoki umuman bo'lmasa. Deyarli yoki to'liq static table 100% index fillfactordan kamroq zarar ko'radi.
2. Read performance write performancedan ko'ra muhimroq bo'lsa.
3. Qiymatlar aynan tartib bilan kiritilsa va updatelar juda kam bo'lsa.
Qachon fillfactorni pastroq qilib belgilash tavsiya qilinadi:
1. Write operationlar juda ko'p va tartibsiz bo'lsa.
2. Write performance read performancedan ko'ra muhimroq bo'lsa.
3. UUID yoki GUID bilan ishlaganda.
Index fillfactor index pagening necha foizi to'lganidan keyin yangi pagega o'tishni ko'rsatadi. Default holatda 90%, ya'ni 10% qismi bo'sh turadi. PostgreSQL dokumentatsiyasi bu qiymatni 50-90 foiz oralig'ida ushlashni tavsiya qiladi.
Kamroq fillfactor write operationlar kutilmaganda sekinlashib qolishini kamaytiradi, lekin searchni biroz sekinlashtiradi (fillfactor past bo'lsa, index pagelar soni ko'payadi, ko'proq page ko'proq vaqt degani) va ko'proq joy oladi.
Qachon fillfactorni yuqori qilish tavsiya qilinadi:
1. Tableda write operations juda kam bo'lsa yoki umuman bo'lmasa. Deyarli yoki to'liq static table 100% index fillfactordan kamroq zarar ko'radi.
2. Read performance write performancedan ko'ra muhimroq bo'lsa.
3. Qiymatlar aynan tartib bilan kiritilsa va updatelar juda kam bo'lsa.
Qachon fillfactorni pastroq qilib belgilash tavsiya qilinadi:
1. Write operationlar juda ko'p va tartibsiz bo'lsa.
2. Write performance read performancedan ko'ra muhimroq bo'lsa.
3. UUID yoki GUID bilan ishlaganda.
PostgreSQL Documentation
CREATE INDEX
CREATE INDEX CREATE INDEX — define a new index Synopsis CREATE [ UNIQUE ] INDEX [ CONCURRENTLY ] [ [ …
👍14
Algoritmlar bilan ishlashni endi boshlaganlarida tug'iladigan klassik savol:
Sort qilinmagan arrayda biror elementni izlash O(n) vaqt talab qiladi.
Sort qilingan arrayda esa qidiruv O(log n), lekin sort qilishning o'zi O(n * log n) vaqt oladi. Demak, arrayni sort qilib, elementni izlash sort qilinmagan arraydagi qidiruvdan ko'ra ko'p vaqt oladi. Unda sort qilishning nima keragi bor?
Javob: Sort qilinmagan arrayda har bir search uchun O(n) sarflanadi. Sort qilingan arrayda esa sort qilish uchun esa O(n * log n), keyingi har bir search uchun O(log n) vaqt sarflanadi. Bir martalik operatsiya uchun sort qilmasdan qidirish tezroq bo'lsa-da, umumiy m ta (m >> n) qidiruv uchun sort qilmasdan qidirish O(m * n), sort qilib, keyin qidirish esa O(m * log n) vaqt talab qiladi.
Xulosa qilganda, kelajakdagi qidiruvlarni ham hisobga olganda, arrayni tartiblash foydali.
P.S. Bu savolni yaqinda bir guruhda ko'rgandim, bugun bir kishi shaxsiyda shu savolni so'rabdi. Kimgadir foydali bo'lsa, xursand bo'laman.
Sort qilinmagan arrayda biror elementni izlash O(n) vaqt talab qiladi.
Sort qilingan arrayda esa qidiruv O(log n), lekin sort qilishning o'zi O(n * log n) vaqt oladi. Demak, arrayni sort qilib, elementni izlash sort qilinmagan arraydagi qidiruvdan ko'ra ko'p vaqt oladi. Unda sort qilishning nima keragi bor?
Javob: Sort qilinmagan arrayda har bir search uchun O(n) sarflanadi. Sort qilingan arrayda esa sort qilish uchun esa O(n * log n), keyingi har bir search uchun O(log n) vaqt sarflanadi. Bir martalik operatsiya uchun sort qilmasdan qidirish tezroq bo'lsa-da, umumiy m ta (m >> n) qidiruv uchun sort qilmasdan qidirish O(m * n), sort qilib, keyin qidirish esa O(m * log n) vaqt talab qiladi.
Xulosa qilganda, kelajakdagi qidiruvlarni ham hisobga olganda, arrayni tartiblash foydali.
P.S. Bu savolni yaqinda bir guruhda ko'rgandim, bugun bir kishi shaxsiyda shu savolni so'rabdi. Kimgadir foydali bo'lsa, xursand bo'laman.
👍31
Celeryning arxitekturasida, ayniqsa networking qismida yetarlicha muammolar borligi haqida avvalroq yozgandim.
2019-yil Doordash asinxron tasklar uchun RabbitMQ + Celery stackdan Kafka + custom workerlarga o'tishiga asosiy sabablardan biri ham aynan Celeryning networking muammolari bilan bog'liq bo'lgan ekan.
Doordash Engineering blogida bu jarayon qanday o'tgani haqida batafsil maqola bor ekan. Asosiy va ikkinchi darajali muammolarni analiz qilishdan boshlab potensial yechimlarni ko'rib chiqish, yangi arxitekturaga qanday muammosiz o'tish/moslashish va yangi arxitekturadagi muammolar qanday tuzatilganigacha yozilgan (batafsil bo'lmasa ham, yetarlicha).
Erinmasdan oxirigacha o'qib chiqishni tavsiya qilaman:
https://doordash.engineering/2020/09/03/eliminating-task-processing-outages-with-kafka/
2019-yil Doordash asinxron tasklar uchun RabbitMQ + Celery stackdan Kafka + custom workerlarga o'tishiga asosiy sabablardan biri ham aynan Celeryning networking muammolari bilan bog'liq bo'lgan ekan.
Doordash Engineering blogida bu jarayon qanday o'tgani haqida batafsil maqola bor ekan. Asosiy va ikkinchi darajali muammolarni analiz qilishdan boshlab potensial yechimlarni ko'rib chiqish, yangi arxitekturaga qanday muammosiz o'tish/moslashish va yangi arxitekturadagi muammolar qanday tuzatilganigacha yozilgan (batafsil bo'lmasa ham, yetarlicha).
Erinmasdan oxirigacha o'qib chiqishni tavsiya qilaman:
https://doordash.engineering/2020/09/03/eliminating-task-processing-outages-with-kafka/
👍15
Hali ko'rmaganlar uchun:
https://youtu.be/wlRbDg8-QH0
P.S. Xato va kamchiliklarini commentda yozsangiz xursand bo'lardim.
Bu keyingi talklar yaxshiroq bo'lishiga xizmat qiladi.
https://youtu.be/wlRbDg8-QH0
P.S. Xato va kamchiliklarini commentda yozsangiz xursand bo'lardim.
Bu keyingi talklar yaxshiroq bo'lishiga xizmat qiladi.
YouTube
Bobosher Musurmonov - Pythonda GIL va konkurensiya
👍5
Microservices are evil.
Yes, now I totally agree with JR ))
P.S. And I'm realizing this in a painful way.
Yes, now I totally agree with JR ))
P.S. And I'm realizing this in a painful way.
👍10
Bugun bo'sh vaqtim ko'proq bo'lgani sabab o'zimni anchadan beri qiziqtirayotgan savollarga javob izlash va yana yangi kitob o'qishni boshlashga imkon bo'ldi.
Anchadan beri LinkedIn ishlatadigan Galene search engine (well, architecture) qanday ishlashiga qiziqayotgandim, bugun shu haqida ozroq ma'lumot topib (o'zi unchalik batafsil ma'lumot topa olmadim), o'qib ko'rdim. Xuddi kutganimdek, ancha murakkab tizim ekan.
Ko'pchilik backend engineerlar uchun database "shunchaki" ma'lumot saqlaydigan servis va bu qisman to'g'ri. Lekin tizimdan foydalanuvchilar minglab emas millionlab bo'lganida, ma'lumot hajmi gigabaytlar emas, petabaytlar bo'lganida hammasi o'zgaradi. Klassik qarashlar ortidan kelgan yechimlar ish bermay qoladi (xuddi kvant olamida klassik mexanika qoidalari ishlamaganidek). Yangicha yechim topish uchun muammoga boshqa tomonlardan qarab ko'rish kerak bo'ladi.
Nega LinkedIn faqatgina search (klassik CRUDning 1 ta elementi) qilishning o'zi uchun alohida engine ishlab chiqdi? Shunchaki bitta PostgreSQL instance yurgizib qo'yib, LIKE orqali search qilsa bo'lmasmidi?
Yo'q do'stim, hammasi bunchalik oddiy emas. Buning uchun biznes talablarini qondiradigan (har xil modellar ustida bitta query, natijalarni hudud, qiziqishlar, tanishlar kabi bir qancha metadata bo'yicha rank qilish, logik va grammatik alternativlar bo'yicha izlash, ...) va texnik jihatdan batafsil o'ylangan (latency, CPU va RAM limitlarini hisobga olish, ma'lumotlarni saqlash usulining storage va OS leveldagi muammolarini hisobga olish, optimizatsiya qilish, failurelar va attacklarga qarshi mexanizmlar bilan jihozlangan) tizim ishlab chiqish kerak bo'ladi. Va bu overengineering emas. Mana shu yerda esa "Database shunchaki ma'lumot saqlaydigan servis" degan gap o'zini oqlamaydi.
Anchadan beri LinkedIn ishlatadigan Galene search engine (well, architecture) qanday ishlashiga qiziqayotgandim, bugun shu haqida ozroq ma'lumot topib (o'zi unchalik batafsil ma'lumot topa olmadim), o'qib ko'rdim. Xuddi kutganimdek, ancha murakkab tizim ekan.
Ko'pchilik backend engineerlar uchun database "shunchaki" ma'lumot saqlaydigan servis va bu qisman to'g'ri. Lekin tizimdan foydalanuvchilar minglab emas millionlab bo'lganida, ma'lumot hajmi gigabaytlar emas, petabaytlar bo'lganida hammasi o'zgaradi. Klassik qarashlar ortidan kelgan yechimlar ish bermay qoladi (xuddi kvant olamida klassik mexanika qoidalari ishlamaganidek). Yangicha yechim topish uchun muammoga boshqa tomonlardan qarab ko'rish kerak bo'ladi.
Nega LinkedIn faqatgina search (klassik CRUDning 1 ta elementi) qilishning o'zi uchun alohida engine ishlab chiqdi? Shunchaki bitta PostgreSQL instance yurgizib qo'yib, LIKE orqali search qilsa bo'lmasmidi?
Yo'q do'stim, hammasi bunchalik oddiy emas. Buning uchun biznes talablarini qondiradigan (har xil modellar ustida bitta query, natijalarni hudud, qiziqishlar, tanishlar kabi bir qancha metadata bo'yicha rank qilish, logik va grammatik alternativlar bo'yicha izlash, ...) va texnik jihatdan batafsil o'ylangan (latency, CPU va RAM limitlarini hisobga olish, ma'lumotlarni saqlash usulining storage va OS leveldagi muammolarini hisobga olish, optimizatsiya qilish, failurelar va attacklarga qarshi mexanizmlar bilan jihozlangan) tizim ishlab chiqish kerak bo'ladi. Va bu overengineering emas. Mana shu yerda esa "Database shunchaki ma'lumot saqlaydigan servis" degan gap o'zini oqlamaydi.
Linkedin
Did you mean "Galene"?
Introducing LinkedIn’s new search architecture Authors: Sriram Sankar, Asif Makhani Search is one of the most intensely studied problems in software engineering. It brings together information retrieval, machine learning, distributed systems, and other…
👍14
Ba'zan klassik muammolar oddiy, nozik yechim talab qiladi.
Masalan, MQ va Pub/Sub tizimlari duch keladigan klassik muammolardan biri latency va data persistency orasidagi "oldin nuqta"ni topish. Messagelarni memoryga yozish va o'qish tez, lekin persistencyni ta'minlash qiyin masala. Storagaga yozish ancha mustahkam yechim, lekin shu bilan birga ancha sekin.
Ko'pchilik MQlar (masalan, RabbitMQ) yuqoridagi ikkita yechimni ma'lum darajada birlashtirib, o'zlari uchun to'g'ri keladigan yechim ishlab chiqqan. Menga esa Kafka qo'llagan usul yoqadi. Xo'sh bu qanday yechim?
Shoshmang, yechimdan oldin muammoni yaxshilab tushunib olaylik.
Nega storagaga yozish/o'qish sekin?
Birinchidan, bu I/O operation, ikkinchidan storageda random access yo'q. Hajmi juda kichkina bo'lgan 100 ta message har xil joydagi 100 ta blokka yozilgan bo'lsa, ularni olish uchun 100 ta blokni to'liq yuklab olish, ya'ni 100 ta I/O kerak bo'ladi. Ya'ni bu usulning effektivligi past va sekin. Lekin agar o'sha 100 ta messageni ketma-ket turgan 2-3 ta bloklarga yozsakchi? Unda 100 ta message uchun 2/3 ta blokni o'qish yetarli bo'ladi. Va undan ham yaxshi tomoni, ketma-ket turgan bloklarni o'qish storagening narigi burchagida turgan blokni borib o'qishdan ko'ra tezroq bo'ladi. Kafka xuddi shunday qiladi. Ya'ni messagelarni storageda yonma-yon yozib, shu ketma-ketlikda o'qiydi.
Ko'rayapsizmi, yechimlar har doim ham murakkab bo'lishi shart emas. Shunchaki asl muammoni chuqurroq o'rganish va ozgina kreativ fikrlash chiroyli yechimlarga olib keladi (afsuski, har doim ham emas).
Masalan, MQ va Pub/Sub tizimlari duch keladigan klassik muammolardan biri latency va data persistency orasidagi "oldin nuqta"ni topish. Messagelarni memoryga yozish va o'qish tez, lekin persistencyni ta'minlash qiyin masala. Storagaga yozish ancha mustahkam yechim, lekin shu bilan birga ancha sekin.
Ko'pchilik MQlar (masalan, RabbitMQ) yuqoridagi ikkita yechimni ma'lum darajada birlashtirib, o'zlari uchun to'g'ri keladigan yechim ishlab chiqqan. Menga esa Kafka qo'llagan usul yoqadi. Xo'sh bu qanday yechim?
Shoshmang, yechimdan oldin muammoni yaxshilab tushunib olaylik.
Nega storagaga yozish/o'qish sekin?
Birinchidan, bu I/O operation, ikkinchidan storageda random access yo'q. Hajmi juda kichkina bo'lgan 100 ta message har xil joydagi 100 ta blokka yozilgan bo'lsa, ularni olish uchun 100 ta blokni to'liq yuklab olish, ya'ni 100 ta I/O kerak bo'ladi. Ya'ni bu usulning effektivligi past va sekin. Lekin agar o'sha 100 ta messageni ketma-ket turgan 2-3 ta bloklarga yozsakchi? Unda 100 ta message uchun 2/3 ta blokni o'qish yetarli bo'ladi. Va undan ham yaxshi tomoni, ketma-ket turgan bloklarni o'qish storagening narigi burchagida turgan blokni borib o'qishdan ko'ra tezroq bo'ladi. Kafka xuddi shunday qiladi. Ya'ni messagelarni storageda yonma-yon yozib, shu ketma-ketlikda o'qiydi.
Ko'rayapsizmi, yechimlar har doim ham murakkab bo'lishi shart emas. Shunchaki asl muammoni chuqurroq o'rganish va ozgina kreativ fikrlash chiroyli yechimlarga olib keladi (afsuski, har doim ham emas).
👍24
Ko'pchilik DBMSlar client-server (server bu yerda database) communication uchun alohida protocollar ishlab chiqqan.
Ya'ni networking uchun ularning alohida protocoli bor.
E'tiborli jihati, ko'p DBMSlarda bu communication davomida va ayniqsa connection ochish vaqtida juda ko'p metadata almashiladi (o'zim PostgreSQL va MongoDBda kuzatdim).
Bu databaselar bilan ishlayotganda connection ochish ancha "qimmat"ga tushadi degani. Bitta connectionni uzoqroq ishlating (albatta, butunligiga ishonch hosil qilib) yoki connection pool ishlating.
P.S. Har bitta query uchun alohida connection ochadigan tanishlarga yuboramiz ))
P.S.2. PHPchilarga yuboramiz ))
Ya'ni networking uchun ularning alohida protocoli bor.
E'tiborli jihati, ko'p DBMSlarda bu communication davomida va ayniqsa connection ochish vaqtida juda ko'p metadata almashiladi (o'zim PostgreSQL va MongoDBda kuzatdim).
Bu databaselar bilan ishlayotganda connection ochish ancha "qimmat"ga tushadi degani. Bitta connectionni uzoqroq ishlating (albatta, butunligiga ishonch hosil qilib) yoki connection pool ishlating.
P.S. Har bitta query uchun alohida connection ochadigan tanishlarga yuboramiz ))
P.S.2. PHPchilarga yuboramiz ))
👍13😁10
"Sifatli softwarega kuchli toollar orqali emas, kuchli dasturchilar orqali erishiladi." – degandi David West.
Bu degani tool qanchalik zo'r bo'lmasin, u to'g'ri ishlatilmasa "bir tiyinga qimmat".
Masalan, GraphQL hozir ancha mashhur bo'lib ketdi. Xo'sh savol, uning RESTdan eng ustun tomoni nima? Flexibility!
Facebookdagilar aynan shuning uchun GraphQLni yaratgan. Clientda RESTdagiga o'xshab o'ziga kerakli 2-3 ta fieldni olish uchun butun boshli ulkan obyektni emas, faqat o'zi so'ragan, o'zi uchun yetarli minimal datani olish imkoniyati bor. Bu aslidan minglab marta sodda ko'rinishdagi tushuntirish.
Xo'sh, buni texnologiyani noto'g'ri ishlatayotganlar ham bormi?
Ochig'ini aytganda, faqat sanoqli kompaniyalargina to'g'ri ishlata olayapti. Men siz yaqinda ishlab chiqqan CRM yoki lokal bank tizimi haqida gapirmayapman. Hattoki Twitterga o'xshash kuchli mutaxassislarga ega texnogigantlar ham implementatsiyaga kelganda oqsoqlanayapti. Ishonmaysizmi? Twitterning web versiyasini inspect qilib, network panelni kuzating, o'zingiz ko'rasiz.
Qisqasi, Python PHPdan zo'r deyishdan oldin post boshidagi gapni o'qing.
P.S. "Sen kim bo'libsan Twitterning ogorodiga tosh otadigan?" deydiganlarga javob – mashinaga baho berish uchun oldin o'zingiz mashina qurishingiz shart emas (ayniqsa bizda).
Bu degani tool qanchalik zo'r bo'lmasin, u to'g'ri ishlatilmasa "bir tiyinga qimmat".
Masalan, GraphQL hozir ancha mashhur bo'lib ketdi. Xo'sh savol, uning RESTdan eng ustun tomoni nima? Flexibility!
Facebookdagilar aynan shuning uchun GraphQLni yaratgan. Clientda RESTdagiga o'xshab o'ziga kerakli 2-3 ta fieldni olish uchun butun boshli ulkan obyektni emas, faqat o'zi so'ragan, o'zi uchun yetarli minimal datani olish imkoniyati bor. Bu aslidan minglab marta sodda ko'rinishdagi tushuntirish.
Xo'sh, buni texnologiyani noto'g'ri ishlatayotganlar ham bormi?
Ochig'ini aytganda, faqat sanoqli kompaniyalargina to'g'ri ishlata olayapti. Men siz yaqinda ishlab chiqqan CRM yoki lokal bank tizimi haqida gapirmayapman. Hattoki Twitterga o'xshash kuchli mutaxassislarga ega texnogigantlar ham implementatsiyaga kelganda oqsoqlanayapti. Ishonmaysizmi? Twitterning web versiyasini inspect qilib, network panelni kuzating, o'zingiz ko'rasiz.
Qisqasi, Python PHPdan zo'r deyishdan oldin post boshidagi gapni o'qing.
P.S. "Sen kim bo'libsan Twitterning ogorodiga tosh otadigan?" deydiganlarga javob – mashinaga baho berish uchun oldin o'zingiz mashina qurishingiz shart emas (ayniqsa bizda).
👍25
"Hozircha ishlaydigan" yechim qilmang.
Sizdan keyin ishlaydiganlarga rahmingiz kelsin...
Sizdan keyin ishlaydiganlarga rahmingiz kelsin...
👍30😁11