From 3e191e3ed0536231305eef5e02e9c2997053b6fc Mon Sep 17 00:00:00 2001 From: Sokhibjon Orzikulov Date: Tue, 5 Dec 2023 12:42:09 +0500 Subject: [PATCH] fmt & lint --- data/keyboards.json | 2 +- posts/mysql-va-olib-borayotgan-mariadb.md | 6 +----- ...mysqlga-juniorcha-va-seniorcha-sorovlar.md | 6 +++--- ...tekshirish-qanday-amalga-oshirilgan-edi.md | 19 ++++++++++--------- 4 files changed, 15 insertions(+), 18 deletions(-) diff --git a/data/keyboards.json b/data/keyboards.json index f4784af..d745956 100644 --- a/data/keyboards.json +++ b/data/keyboards.json @@ -60,6 +60,6 @@ "image": "https://i.rtings.com/assets/products/MSgrVKR1/keychron-k3-version-2/design-medium.jpg", "url": "https://www.keychron.com/products/keychron-k3-wireless-mechanical-keyboard", "key": "65%" - }, + } ] } diff --git a/posts/mysql-va-olib-borayotgan-mariadb.md b/posts/mysql-va-olib-borayotgan-mariadb.md index 04a99c8..2654c58 100644 --- a/posts/mysql-va-olib-borayotgan-mariadb.md +++ b/posts/mysql-va-olib-borayotgan-mariadb.md @@ -26,13 +26,9 @@ Hamjamiyat: MySQLdan farqli o‘laroq MariaDB Oracleʼdan ko‘ra ko‘proq hamj **Texnik farqlar:** 1. Tezlik: MariaDBʼning MySQLʼga nisbatan eng muhim afzalligi uning tezligi va ishlashidir. Replikatsiya va so‘rovlarni bajarish haqida gap ketganda, MariaDB MySQLʼga qaraganda tezroq. Bundan tashqari MariaDB bir vaqtda juda ko‘plab ulanishlarni qo‘llay oladi. - 2. Xavfsizlik: MySQL parol xavfsizligini tekshirish va oshirish uchun ishlatiladigan validate_password komponenti bilan birga keladi. MariaDB, o‘z navbatida, foydalanuvchilarga maʼlumotlar bazasini boshqarishda ko‘proq xavfsizlikni taʼminlaydigan turli xil parolni tekshirish plaginlarini taklif qiladi. - 3. Shifrlash: MySQL vaqtinchalik jadvallarni va ikkilik sanoq tizimiga asoslangan loglarni shifrlamaydi. Boshqa tomondan, MariaDB ikkilik loglarni shifrlash va vaqtinchalik jadval shifrlashni qo‘llab-quvvatlaydi. - 4. Maʼlumotlarni saqlash mexanizmlari: MariaDB Blackhole, CSV, XtraDB, Aria, InnoDB, Archive, MariaDB ColumnStore, Connect, Cassandra Storage Engine va boshqalar ko‘plab mexanizmlarni qo‘llab-quvvatlaydi. MySQLʼda qo‘llab-quvvatlanadigan saqlash mexanizmlari esa MyISAM, Merge, Federated, InnoDB, Archive, Memory, CSV, Blackhole va Example hisoblanadi. - Ochiq mabalar: MariaDB to‘liq paketni taqdim etadi, MySQL esa maʼlum cheklovlar bilan birga keladi. @@ -48,4 +44,4 @@ MariaDB ayni damda o‘zgarish qila oladigan moliyaga ega emas. Ular hattoki 7 o Yo‘qotishlar: MariaDBning yo‘qotilishi kompaniya investorlari tortib olgan sarmoyadan ko‘ra kattaroq zarar keltiradi. Maʼlumotlar markazi (DC), Hostinglar, ochiq manbalar, millionlab veb saytlar va turli dasturlar uchun o‘z taʼsirni o‘tkazadi. -_Qachonlardir Apple ( 1984 - 1997 ) va Nokia ham shu tarzda kasod bo‘lgan edi…_ \ No newline at end of file +_Qachonlardir Apple ( 1984 - 1997 ) va Nokia ham shu tarzda kasod bo‘lgan edi…_ diff --git a/posts/mysqlga-juniorcha-va-seniorcha-sorovlar.md b/posts/mysqlga-juniorcha-va-seniorcha-sorovlar.md index bf4f0bc..e278c84 100644 --- a/posts/mysqlga-juniorcha-va-seniorcha-sorovlar.md +++ b/posts/mysqlga-juniorcha-va-seniorcha-sorovlar.md @@ -83,9 +83,9 @@ Tasavvurimizni yana bir ishga tushirsakda sotilgan mahsulotlarni foizlardagi nis ```sql SELECT id, COUNT(*) AS count, 100 * COUNT(*)/s.total_sum AS percentage -FROM sales +FROM sales CROSS JOIN ( - SELECT COUNT(*) AS total_sum + SELECT COUNT(*) AS total_sum FROM sales ) AS s GROUP BY id; @@ -126,4 +126,4 @@ id month date count percentage ## Xulosa -Albatta bu birgina so'rovlar orqali amalga oshirish mumkin bo'lgan ishlar uchun kichik misol xolos, ammo sizning optimizatsiya masalasidagi qarashlaringizga oz bo'lsada tasir ko'rsata oladi degan umiddaman. \ No newline at end of file +Albatta bu birgina so'rovlar orqali amalga oshirish mumkin bo'lgan ishlar uchun kichik misol xolos, ammo sizning optimizatsiya masalasidagi qarashlaringizga oz bo'lsada tasir ko'rsata oladi degan umiddaman. diff --git a/posts/nginxda-ichki-redireksiya-yoxud-katta-stream-servisda-havolalarni-tekshirish-qanday-amalga-oshirilgan-edi.md b/posts/nginxda-ichki-redireksiya-yoxud-katta-stream-servisda-havolalarni-tekshirish-qanday-amalga-oshirilgan-edi.md index 1f5e864..6da60ce 100644 --- a/posts/nginxda-ichki-redireksiya-yoxud-katta-stream-servisda-havolalarni-tekshirish-qanday-amalga-oshirilgan-edi.md +++ b/posts/nginxda-ichki-redireksiya-yoxud-katta-stream-servisda-havolalarni-tekshirish-qanday-amalga-oshirilgan-edi.md @@ -1,5 +1,5 @@ --- -title: "Nginxda ichki redireksiya yoxud katta stream servisda havolalarni tekshirish qanday amalga oshirilgan edi?" +title: 'Nginxda ichki redireksiya yoxud katta stream servisda havolalarni tekshirish qanday amalga oshirilgan edi?' description: "Odatda statik fayllarni uzatish uchun nginx server ko'targanda indeksatsiyadan himoyalash ancha muammoga aylanadi..." slug: nginxda-ichki-redireksiya-yoxud-katta-stream-servisda-havolalarni-tekshirish-qanday-amalga-oshirilgan-edi date: July 27, 2023 @@ -18,26 +18,28 @@ Aynan shu sababli nginx ham yangi versiyalardan luani qo'llab quvvatlashni to'xt Menimcha barcha dasturchilar http 301 redireksiyasidan xabardor bo'lsalar kerak. ```http -HTTP/1.1 301 Moved Permanently +HTTP/1.1 301 Moved Permanently Location: http://www.example.org/another_page ``` + Bu metod odatda foydalanuvchi brauzerini bir sahifadan boshqasiga yo'naltirish uchun ishlatiladi. Lekin biz buni tashqi redireksiya deb ataymiz. Chunki foydalanuvchi o'zgargan sahifadan xabardor bo'ladi. Xuddi shu tartibda ishlaydigan ichki redireksiya ham mavjud, unda foydalanuvchi http://www.example.org/mypage sahifasiga murojaat qilsa redireksiya backend qismni o'zida amalga oshiriladi va foydalanuvchiga u murojaat qilgan havolani o'zidayoq ma'lumotlarni olib qolish imkoni mavjud bo'ladi. Ho'sh bu qanday imkoniyatlar beradi? -Tasavvur qiling sizda ikkita server mavjud, birida sizning asosiy saytingiz, ikkinchisida esa yuklash uchun beriladigan statik fayllar joylashgan. Lekin siz static faylni yuklash ruxsatini faqatgina ro'yxatdan o'tgan foydalanuvchigagina berishingiz kerak. Yoki yana bir holatda sizda /download.php fali bor deylik unga siz ?file_id=123 so'rovini berganingizda 123 idenfikatorga asoslanib fayl joylashuvini topadi va binary faylni uzatishi kerak. +Tasavvur qiling sizda ikkita server mavjud, birida sizning asosiy saytingiz, ikkinchisida esa yuklash uchun beriladigan statik fayllar joylashgan. Lekin siz static faylni yuklash ruxsatini faqatgina ro'yxatdan o'tgan foydalanuvchigagina berishingiz kerak. Yoki yana bir holatda sizda /download.php fali bor deylik unga siz ?file_id=123 so'rovini berganingizda 123 idenfikatorga asoslanib fayl joylashuvini topadi va binary faylni uzatishi kerak. Odatda ko'pchilik o'zi foydalanadigan backend texnologiyada header orqali transfer qilish metodini qiladi. Masalan phpda: ```php $file_url = '/home/user/file.exe'; header('Content-Type: application/octet-stream'); -header("Content-Transfer-Encoding: Binary"); -header("Content-disposition: attachment; filename=\"" . basename($file_url) . "\""); -readfile($file_url); +header("Content-Transfer-Encoding: Binary"); +header("Content-disposition: attachment; filename=\"" . basename($file_url) . "\""); +readfile($file_url); ``` + Ammo bu metodda siz ishlatayotgan texnologiya reader va proxy vazifasini bajarib serverdagi butun resursni band qilishga urinadi. Ya'ni oddiyroq aytganda download.php fayli 10Mb hajmga ega faylni uzatish uchun operativ xotiradan yana 10Mb joy egallashga majbur bo'ladi. Katta fayllar haqidaku bunday metodda o'ylamagan ham maqul. Ichki redireksiyada barchasi boshqacha ishlaydi. Siz avvalo kerakli texnologiyangiz bilan (menda php) foydalanuvchi barcha shartlarni bajarayonganini tekshirasiz, keyin esa xuddi 301 kabi uni boshqa ichki locationga yo'naltirasiz. @@ -96,7 +98,7 @@ server { Yuqoridagi misoldan tushunishingiz mumkinki "X-Accel-Redirect" orqali phpdan ichki redireksiya berilmoqda, nginxda esa internel seksiyasi orqali ichki redireksiya qabul qilib olinyapti. Bu usulning yana bir yaxshi tomoni borki foydalanuvchi internal blokga (Mendagi misolda: internal_download) murojaat qilgan vaqtda server uchun 404 xatoligini qaytaraveradi, ya'ni bu blok faqatgina server ichki qismidan ishlaydi xolos. -Shuningdek php fayl o'z ishini bajarib bo'lgach nginx fpm protsesdan murojaat qilingan php faylni o'chiradi, bu esa foydalanuvchi yuklab olguncha fpm protsess kuzatib turmasligini ta'minlab beradi. +Shuningdek php fayl o'z ishini bajarib bo'lgach nginx fpm protsesdan murojaat qilingan php faylni o'chiradi, bu esa foydalanuvchi yuklab olguncha fpm protsess kuzatib turmasligini ta'minlab beradi. Nginx orqali katta hajmdagi fayllarni uzatishni ko'zda tutganlar uchun qo'shimcha bonus ham qilishni maqul ko'rdim va quyidagi konfiguratsiyalarni /etc/nginx/nginx.conf fayliga qo'shishni yoki ularni quyidagicha o'zgartirishni unutmang. @@ -112,7 +114,6 @@ Agarda sizda fayllar hajmi 100Mbdan oshsa: - tcp_nopush uzatilgan ma'lumotlar miqdorini optimallashtiradi - keepalive_timeout bo'sh qolgan aloqa yopilish vaqti, ya'ni foydalanuvchi o'z ishini bajarib bo'lsa uni odatdagidek 75 soniya kutilmaydi. Balkim aloqa o'z o'rnida uziladi. - ``` worker_rlimit_nofile 65535; events { @@ -124,4 +125,4 @@ http{ tcp_nodelay on; keepalive_timeout 0; } -``` \ No newline at end of file +```