🔵 عنوان مقاله
500 Milliseconds on Planning? How Statistics Slowed Down a Query 20 Times Over

🟢 خلاصه مقاله:
در یک سیستم پایگاه داده، ممکن است یک کوئری بسیار سریع اجرا شود، اما زمان لازم برای برنامه‌ریزی و آماده‌سازی اجرای آن بسیار طولانی‌تر باشد. در این مقاله، به یکی از این موارد جالب اشاره می‌شود که نشان می‌دهد چگونه یک عملیات برنامه‌ریزی با استفاده نادرست از بهینه‌ساز پایگاه داده PostgreSQL می‌تواند سرعت اجرای یک کوئری را تا ۲۰ برابر کاهش دهد. تصور کنید که یک کوئری تنها در عرض چند میلی‌ثانیه اجرا می‌شود، اما فرآیند برنامه‌ریزی آن بیش از نیم ثانیه زمان می‌برد. این اختلاف زمانی بسیار قابل توجه است و می‌تواند تاثیر زیادی بر عملکرد کل سیستم بگذارد.

در این وضعیت، مشکل اصلی به خطای عملیات بهینه‌ساز PostgreSQL برمی‌گردد که به دلیل انتخاب نادرست استراتژی‌های اجرایی، فرآیند برنامه‌ریزی به صورت ناپایدار و غیرمؤثر انجام می‌شود. این مسأله در سیستم‌های بزرگ و بارهای سنگین اهمیت بیشتری پیدا می‌کند، زیرا هر چه تعداد کوئری‌ها بیشتر باشد، نقش زمان صرف شده در برنامه‌ریزی در کاهش کارایی سیستم بیشتر جلوه می‌کند. خوشبختانه، راه‌حل‌هایی برای اصلاح این وضعیت وجود دارد که می‌توانند به بهبود عملکرد و کاهش زمان طراحی برنامه کمک کنند.

در نهایت، شناخت این مشکل و نحوه رفع آن اهمیت زیادی دارد تا بتوان کسب‌وکارها یا توسعه‌دهندگان سیستم‌های دیتابیس از حداکثر بهره‌وری را ببینند. با بهره‌گیری از روش‌های مناسب و تنظیمات بهینه، می‌توان کنترل بهتری بر فرآیندهای برنامه‌ریزی و اجرا داشته و تضمین کرد که نتیجه نهایی در کمترین زمان ممکن حاصل شود. این موارد، کلید بهبود کارایی و پاسخگویی سریع‌تر سیستم‌های پایگاه داده است.

#پایگاه_داده #بهینه‌سازی #PostgreSQL #کارایی

🟣لینک مقاله:
https://postgresweekly.com/link/180190/web

➖➖➖➖➖➖➖➖
👑 @Database_Academy

منم این مشکل قط شدن وای فای رو زیاد داشتم.

بهتره که داده‌هامون رو براساس نیازمندی و رفتار کاربر باهاشون تفکیک کنیم!

چند وقتی هست که توی طراحی و توسعه‌ی سیستم‌ها، در حال عمیق شدنم. یکی از منابع خیلی خوبی که پیشنهاد میکنم ببینین بلاگ دیسکورد هست.
اگر نمیدونستید، خیلی از اپ‌های بزرگ و معروف مثل Discord بلاگ فنی دارن که توش از نحوه‌ی حل چالش‌های فنی میگن. داشتم بلاگی راجع به اینکه چطوری چند میلیارد پیام رو در روز هندل میکنن میخوندم. این پست قدیمی بود و توی پستی جدیدتر داشتن راجع به اینکه چطوری چند تریلیون پیام رو روزانه هندل میکنن میگن. لینک جفت پست ها اینجاست:

https://discord.com/blog/how-discord-stores-billions-of-messages

https://discord.com/blog/how-discord-stores-trillions-of-messages

سال 2017 دیسکورد روزانه چند میلیارد پیام رو مدیریت میکرد که تا سال 2023 به چند تریلیون پیام رسیده این عدد. نکته‌ای که توجه‌ام رو جلب کرد نحوه تقسیم پیام‌ها بود. دیسکورد اومد یه سری گزارش تهیه کرد تا بتونه نحوه رفتار کاربرهاش رو بررسی کنه. از این گزارش چه جور داده‌ای درومده؟ اینکه چه کانال‌هایی (یا به زبان دیسکورد سرورهایی) چه میزان پیام بر اساس تعداد کاربر، نوع و موضوع کانال و دسته بندی‌های این شکلی وجود دارن.
بر اساس این گزارش هر دسته از کانال چالش‌های خودش رو داشته.

نکته‌ای که برام جذاب بود، جدا از نحوه‌ی حل چالش‌ها، همین تقسیم نوع کاربری و رفتار محور داده بود. یه عادتی که ما داریم معمولا اینه که به همه چی موقع طراحی سیستم خیلی کلی نگاه میکنیم. این موضوع بخصوص وقتی داریم سیستم‌مون رو گسترده‌تر میکنیم به چشم میاد.
توی کتاب Designing Data-intensive Applications هم این موضوع رو کم و بیش میبینیم. توی فصل دوم کتاب از مثال صفحه اول توییتر استفاده میکنه و میاد تخمین میزنه که اکثر کاربرها، سلبریتی یا اینفلوئنسر نیستن و مثلا حدود 200 تا حساب رو دنبال میکنن، اما افرادی هم هستن که مثلا 100 میلیون دنبال کننده دارن.
موقع طراحی سیستم باید این تقسیم بندی رو قائل بشیم. چرا؟ چون ما نمیخوایم سیستمی رو طراحی کنیم که مثلا همه‌ی کاربرهاش 100 میلیون دنبال کننده دارن. میخوایم سیستمی رو طراحی کنیم که به طور متوسط کاربرهاش مثلا 200 نفر دنبال کننده دارن، اما افرادی هم هستند که 100 میلیون نفر دنبالشون میکنن. این تفکیک میتونه روی تصمیمات اساسی که برای سیستم میگیریم اثر چشمگیری بزاره.

@ever_code

تو دوران جنگ سرور بلاگمو آوردم پایین، حالا باید رو وی پی اس خودم بیارمش بالا
تا مدتی بلاگ پایینه، اما احتمالا تو dev.to بزارم پستارو
اگر کسی تجربه سایت استاتیک روی داکر داره بگه ممنون میشم اما احتمالا باید با آپاچی چیزی بیارمش بالا

خب سرور هم اوکی شد، حالا کمی کار داره مطالب قبلی رو بزارم روش و توی گوگل ایندکس کنم و ازین کارا. متاسفانه چون سرورم خارجه ممکنه مشکل دسترسی بهش وجود داشته باشه🫤 با اینکه پینگ دارم بهش ولی بدون کانفیگ و اینا نمیاد. احتمالا بعد ازینکه راه افتاد بگردم دنبال cdn داخلی چیزی

با ghost آوردمش بالا

خب خبر خوب اینکه سایت بلاگ بالا اومد دوباره. اول با ghost راه انداختم، سرویس جذابیه، ولی تم های محدودی داره و میتونین خودتون کاستوم کنین، اما من چون روی سایت قبلیم که با استفاده از Hugo که یک Static Site Generator هست همه کارهام رو کرده بودم، راحت تر بودم و از قبل Github َAction رو آماده کرده بودم تصمیم گرفتم برگردم به سایت خودم.
یکی دیگه از دلایلش هم این بود که از اول روی سرورم Reverse proxy رو ست کرده بودم و certificate و اینا رو اوکی کرده بودم، برای سایت static هم چیز زیادی لازم نبود، خیلی سریع یه Nginx بالا اوردم که سایت رو Serve میکرد و Github Action هم که قبلا با FTP روی Direct Admin کار میکرد رو عوض کردم که رو سرور Sync کنه.
الان سایت بالاست، فقط متاسفانه شاید مجبور شین با VPN ای چیزی واردش بشین. نمیدونم چه داستانیه، با اینکه ssh و ping و اینا رو همه بدون vpn میزدم، خود سایت بالا نمیاد. شما هم اگر دوست داشتین تست کنین، شاید مشکل از جای دیگه ای باشه.
خلاصه چالش های جالبی داشتم، این وسطا امنیت سرور هم بالا بردم.

@ever_code

سی شارپ پر از فیچرهاییه که شاید بگیم خیلی تفاوت زیادی ایجاد نمیکنن، میشه گفت بیشتر Quality of Life هستن. توی C#14 کلمه کلیدی بنام field اضافه شده. کاربردش برای وقتی هست که توی Property میخوایم فقط یکی از set یا get رو تعریف کنیم. قبل از این فیچر، وقتی میخواستیم که get و set رو با بدنه تعریف کنیم باید حتما یه فیلد با دسترسی private تعریف میکردیم که به اصطلاح بهش میگفتیم Backing Field:

class Person
{
    private  string  _name; // Backing Field

    public string Name {
        get => _name;
        set => _name = value;
    }
}

کمی بعد تر در تاریخ سی شارپ، اومدن Auto Implemented Property ها رو اضافه کردن که ما خیلی ازش استفاده میکنیم:

class Person
{
    public string Name { get; set; }
}

در اصل خود کامپایلر این کد رو به کد قبلی تبدیل میکنه و برای ما get و set رو به همراه یه backing field میسازه. تا قبل از سی شارپ 14، ما دسترسی به backing field که کامپایلر بصورت اتوماتیک میساخت نداشتیم و اگر میخواستیم که فقط یکی از get یا set رو پیاده سازی کنیم مجبور بودیم تا backing field رو هم اضافه کنیم.
اما الان با استفاده از کلمه field میتونیم دقیقا همینکار رو انجام بدیم:

class Person
{
    public string Name { 
        get;
        set => field = string.IsNullOrEmpty(value) ? "Not Defined" : value;
    }
}

بنظرم ازون دسته فیچرهایی هست که خیلی زود بهش عادت میکنیم و بعدش توهم میزنیم که از روز اول توی زبان بوده 😂
این یکی از نکات جذاب سی شارپه بنظرم، خیلی از فیچرهایی که توی سال های اخیر اضافه شدن صرفا برای راحت تر کردن و خوانا تر کردن کد بودن، درحالیکه شاید تنها کاری که کردن این بوده که کد تکراری و boiler-plate رو توی کامپایلر اتوماسیون کردن.

@ever_code

هیچوقت فکر نمیکردم روزی بیاد که وبسایت داکیومنت دانلود کنم، تا الان دو سه تا دانلود کردم تا اگر نت قطع شد روی سیستمم هاست کنم و ازشون بتونم استفاده کنم.
برای مثال keycloak تو گیتهاب یه پروژه داره که فایل استاتیک بیلد شده‌ی پروژه‌ی داکیومنتش هست با حجم ۲.۵ گیگ و اگر دانلود کنین میتونین با پایتون با کامند زیر:

python -m http.server 8080

یا با npx با دستور زیر:

npx server index.html

روی لوکال هاست اجراش کنید.

@ever_code

متوجه شدم که minio به کل تعطیل شده و ایمیج های داکرش رو دیگه حتی maintain نمیکنن.
قبل از این اتفاق یکی از سرویس‌های خیلی خوب برای file storage همین minio بود که با Amazon S3 کار میکرد. بنظر میاد اخیرا از دنیای اوپن سورس فاصله گرفته، و تا مدتی میشد سورس رو گرفت و بیلد انجام داد و اورد روی داکر، اما اخیرا ریپازیتوری خودش رو هم آرشیو کرده.

در کمی گشت و گذار رسیدم به RustFS که یک جایگزین بشدت قوی هست و ۱۰۰ درصد S3 Compatible هست و توی دات نت میشه با پکیج Amazon.S3 باهاش کار کرد.
https://rustfs.com/

@ever_code

از open-spec و spec-kit خوشم نمیومد، حس میکنم توکن زیاد مصرف میکنه. اومدم مثلا ابتکار به خرج بدم خودم عملا کاراییش رو دستی تو Claude code تعریف کردم. بعد اینجوری بودم که خب همین شد که😭
حس میکنم به ورژن مدرن این برخوردم:

Take 3 days to automate a 20 mintue task

ولی در کل بد نشد تونستم روی پروژه کار کنم باهاش و rtk هم کمک کرد توکن کمتر مصرف کنه و حدودا هزار و خورده‌ای توکن کمتر مصرف کرد، اما مجبور شدم دات نت و همه چی رو روی WSL دوباره نصب کنم تا بیشترین، بهینگی رو بگیرم ازش. اما یجورایی با Spec-driven development حال میکنم.

اگر بخوام تشبیه کنم این حس رو، مثل اولین باری که از TDD واقعا استفاده کردم میشه. وقتی مجبوری واقعا به رفتار سیستم فکر کنی تا ببینی چی میخوای، که بعد برای اون رفتار اول تست بنویسی و بعد پیاده‌ش کنی. الان هم همون قاعده کار میکنه، اول باید خوب فکر کنی ببینی سیستمت چیکار میکنه، بعد بشکونیش، بعد هر قسمت رو جدا تعریف کنی و بری جلو.

@ever_code

آقا الان نگاه میکنم دو سال پیش این متن رو میذاشتن جلوم گیرپاژ میکردم مغزم اسکرین شات میگرفت، تکنولوژی واقعا عجیبه...

در راستای این پست بیاین چیزهای جذاب‌تری بهتون بگم!
این دوتا Library با زبان‌های Rust و C برای Front-end هستند:
Rust: https://github.com/dioxuslabs/dioxus
C: https://github.com/nicbarker/clay

اونی که با Rust نوشته شده، کاملا Cross-Platform  هست. اونی که با C هست یه کار جالبی که میکنه اینه که روی هر تغییر بجای اینکه مثل  React مثلا بیاد پوزیشن ها رو دستی بر اساس State تغییر بده و Component ها رو تکون بده، میاد کاملا صفحه رو از اول رندر میکنه! اول که اینو فهمیدم اینجوری بودم که خب اینکه خیلی بهینه نیست؟! اما واقعیت اینه که 1. زبانمون C هست! 2. کلی از دردسرهای State Management رو نداره. 3.کاربر واقعا متوجه نمیشه! 4.خیلی سایت‌ها با فریمورک‌های غول‌تری با JS/TS زده شدن که خیلی بدتر از این حرفان!

بنظر خودم خیلی جذابه که با این زبان‌ها وارد دنیای Front-end شد ( مشخصه خیلی با JS میانه خوبی ندارم یا بگم؟ )
شاید نوع کد زدن توشون خیلی فرق داشته باشه و خیلی‎ها نخوان که توی production ازشون استفاده کنن. اما چندتا نکته مهم هست که باید توجه بشه بهشون.
اکثر افراد دارای سوگیری تجاری زبان هستند. یعنی بطور پیش فرض وقتی میشنون دات نت ذهنشون میره سمت Back-end یا js  میشه برای Front-end یا C و Rust میشن برای کارهای Low-level. اما واقعیت اینه که با اینکه میدونیم NodeJS هست، یا مثلا دات نت MAUI داره، یا الان دیدیم که Rust فریمورک Front-end داره و C سال‌هاست که QT داره و بشدت توی صنعت ازش استفاده میشه، باز سوگیری داریم.
ما یادمون میره General Purpose Programming Language یعنی چی؟ اما چیزی که خیلی‌ها روش تاکید دارند اینه که توسعه دهنده نباید برده‌ی ابزار باشه، ابزار صرفا یک مسیر برای رسیدن به هدفه، همینطوری که Ai یک ابزاره.

@ever_code

از Microservice به Outsourced Microservice و سرویس‌های Domain-Agnostic

وسط جنگ، شروع کردم دوره‌ی Event sourcing دیدن. دید خیلی بهتری بهش پیدا کردم و یاد گرفتم که چطوری بصورت استاندارد ازش استفاده کنم و پیاده سازیش کنم.
اما چیزی که برام واضح تر بود، این نبود که خب این رو الان کجا پیاده‌سازی کنم. این بود که الان که میدونم چیه، و چقدر پیچیدگی الکی میتونه استفاده کنه، کجاها سراغش نباید برم.
هرچی بیشتر یاد میگیرم به این مفهوم نزدیک‌تر میشم که ساده نگاهش کن، مگر اینکه برخلافش نیاز باشه.
یکی از چیز‌هایی که در سال‌های اخیر خیلی سر و صدا کرد مایکروسرویس بود. مایکروسرویس واقعی، هزینه مالی و انسانی زیادی میبره. با گذشت زمان، به یک دید متفاوت رسیدم. درسته که کل سیستم رو مایکروسرویس دیدن الکی گنده هست و باید بررسی عمیقی برای انجام دادن یا ندادنش صورت بگیره. اما خیلی از سرویس‌ها رو دیگه نیاز نیست خودمون توسعه بدیم. بهش که فکر میکردم کلمه‌ی Outsourced Microservices مناسب بنظر میاد.
وقتی میتونیم سرویس احراز هویت رو با keycloak، سرویس سرچ رو با ElasticSearch، سرویس مدیریت فایل رو با Minio و نرم افزارهای مشابهش راه بندازیم، دیگه خیلی منطقی نیست که خودمون توسعه بدیم. اینجوری با یک سرویس مربوط به بیزنسمون، و چندتا سرویس آماده میتونیم به سرعت به یک سیستم شبیه مایکروسرویس برسیم.

ایده‌ی اصلی اینجا اینه که از سرویس‌های Domain-Agnostic استفاده کنیم. یعنی سرویس‌هایی که ربط مستقیمی به Domain ما ندارن. صرفا به ما کمک میکنن که تمرکزمون روی Domain باشه.

راجب این تجربه توی بلاگ بیشتر نوشتم:

https://mazdakparnian.com/blogs/2026-04/simple-choices

@ever_code

مقایسه‌ی زبان‌های برنامه‌نویسی همیشه یکی از کارهای مورد علاقه‌ی من بوده.
نه چون میفهمیم کدوم خوبه کدوم بده، چون اکثر چیز‌هایی که ما روزمره باهاش سر و کله میزنیم، قبل ازینکه در صنعت به کار گرفته بشن، در تئوری و دنیای آکادمیک مطرح شدن. برای من جذابیتش اینه که میبینم کدوم مباحث الهام بخش چه فیچرهایی در زبان‌های مطرح الان بوده‌ان.
برای مثال، مفهوم channel که در Golang, C#, Rust و زبان‌های مختلف حالت‌هایی ازش پیاده سازی شده، توسط Tony Hoare مطرح شد. ایشون مفهومی برای مدیریت پراسس‌های همزمان (Concurrent Processes) مطرح میکنن به نام زیر
Communicating sequential processes
که در زبان Go میشه گفت بعنوان First-class concept استفاده شده و بخشی از طراحی زبان هست. این دوستمون هم کمی داستان رو باز تر کرده:
https://t.me/hiradsajde/178
جالبه بدونین، همین آقای هور، کسی بوده که Null Reference رو در روزهای ابتدایی زبان‌ها در طراحی زبان تعریف کرده و کلی آدم رو بدبخت کرده.
خودش، در ارائه‌ای در سال 2009 با نام Null References: The Billion Dollar Mistake اینجوری ازش یاد میکنه:

I call it my billion-dollar mistake. At that time, I was designing the first comprehensive type system for references in an object-oriented language. My goal was to ensure that all use of references should be absolutely safe, with checking performed automatically by the compiler. But I couldn’t resist the temptation to put in a null reference, simply because it was so easy to implement. This has led to innumerable errors, vulnerabilities, and system crashes, which have probably caused a billion dollars of pain and damage in the last forty years.

در این ارائه ایشون میگه دلیلی که Null Reference ها رو داخل زبان تعریف کرده بود صرفا برای راحتی پیاده‌سازیش بود، اما این کارش میلیاردها دلار هزینه تراشیده!

برای همینه که هر از چندگاهی بنظرم بد نیست که زبان جدید یاد گرفت، برای اینکه یادمون نره که همه‌ی زبان‌ها صرفا ابزاری برای ارتباط با Cold, Hard Metal هستن!

@ever_code

امروز دسترسی به Claude بدون فیلتر برام قطع شد، برای شما هم همچین اتفاقی رخ داد؟ تا قبل از اون میتونستم بدون فیلتر بهش وصل شم.

@ever_code

حرکتی که این آقا با دامنه ویکی‌تجربه زده، تو دنیای وب بهش می‌گن Cybersquatting (غصب دامنه) و Brand Hijacking (جعل هویت برند) که این‌جا با Defamation (تخریب و افترا) هم قاطی شده. در واقع اومدن دامنه رو به هر روشی صاحب شدن تا بیانیه بنویسن و دیتابیس فیک بسازن. برای خوابوندن این مچ، بهترین کار اینه که مستندات و اسکرین‌شات‌ها رو به ایمیل ابیوزِ رجیسترار دامنه (`abuse@namesilo.com`) بفرستیم تا به جرم نقض صریح قوانینِ میزبانی (ToS)، خیلی سریع دامنه رو ساسپند یا قفل کنن.

حالا جالبیش اینجاست که اگه این حرکت رو تو یه کشور خارجی با قوانین سفت و سخت (مثل قانون ACPA آمریکا) انجام می‌دادن، کار به این راحتی‌ها تموم نمی‌شد. اون‌جا شاکی می‌تونست علاوه بر پس‌گرفتنِ فوری دامنه، یه پروندهٔ حقوقی سنگین برای آزار سایبری و ضربه به اعتبار تجاری باز کنه که جریمه‌های مالی وحشتناکی (تا ۱۰۰ هزار دلار برای هر دامنه) روی دست این هلدینگ و بنیان‌گذارش می‌ذاشت و حتی می‌تونست به قیمت سابقهٔ کیفری براشون تموم بشه.

@codehalics | کدهالیک

ویکی تجربه یکی از معدود گروه‌هایی بود که بدون هیچ وابستگی و فاند و رانتی، محیطی رو فراهم کرده بود که افراد نظر واقعیشون رو راجب شرکت‌های ایرانی بگن و نظر بدن.
سر همین خیلی از شرکت‌ها می‌گفتن که کامنت‌هایی که راجب ما گذاشتن رو پاک کن وگرنه شکایت می‌کنیم و فلانت می‌کنیم و... یا حتی می‌گفتن بهت پول میدیم، اما قبول نمی‌کرد.

و همینطور یکی از عواملی بودش که باعث شد آموزش‌های من به دست خیلیها برسن، چون همیشه مطالب رو share میکرد و با وجود هزینه‌های سرسام آور سرورهاش و شرایط سخت مالی، توی قطعی نت کنارمون بود.

و آخرین پست کانال تلگرامشون توی تاریخ ۲۷ مارچ(۹۰ روز پیش و اواسط جنگ) بود و همه نگران بودیم که نکنه اتفاقی واسه‌ی مالکش افتاده باشه یا دستگیر شده باشه.
و نتونسته دامنه https://tajrobe.wiki رو تمدید کنه. امروز دیدم که دامنه‌ی ویکی تجربه توسط ابرناک گرفته شده(احتمالا یکی از شرکت‌هایی که تهدیدش می‌کرد). و در عجبم از اینهمه بی‌شرفی، که میراث شخصی رو که مشخص نیست مرده یا زنده‌ست یا دستگیر شده یا... رو برداشته و اسم تمام اون پلتفرم رو گذاشته انتقام‌گیری.
امیدوارم که حال ویکی تجربه خوب باشه. دامنه و اینها کمترین اهمیت رو داره