#مطلب
The Part of PostgreSQL We Hate the Most
https://www.cs.cmu.edu/~pavlo/blog/2023/04/the-part-of-postgresql-we-hate-the-most.html
قسمت‌هایی از پستگرس که ازشون متنفریم! این روزا پستگرس تبدیل شده به یکی از محبوب‌ترین دیتابیس‌های رابطه‌ای و روز به روز هم داره به محبوبیتش اضافه میشه اما این بدین معنی نیست که پستگرس مشکلی نداره :)
داخل پستگرس یه مفهومی داریم به اسم MVCC که کمک میکنه تراکنش‌های مختلف به صورت همزمان داخل پایگاه داده اجرا بشن بدون اینکه روی داده‌های هم‌دیگه اثر بذارن و isolation رو نقض کنن.
این مطلب به صورت عمیق به توضیح MVCC توی دیتابیس‌ها علی‌الخصوص پستگرس می‌پردازه و مشکلات روشی که پسترگس رفته رو بیان میکنه. اینکه توی پسترگس نیاز به VACCUM دوره‌ای داریم یا مشکل Table bloatیا اینکه آپدیت کردن یک ستون از یه ردیف باعث میشه کل داده‌های ردیف کپی بشن به همین مفهوم مربوطه.
این مطلب دید خیلی خوبی به internals پستگرس میده و به کسایی که دوست دارن توی پستگرس و دیتابیس‌ها عمیق بشن توصیه میشه
✴️ @software_inside - مهندسی‌نرم‌افزار
The Part of PostgreSQL We Hate the Most
https://www.cs.cmu.edu/~pavlo/blog/2023/04/the-part-of-postgresql-we-hate-the-most.html
قسمت‌هایی از پستگرس که ازشون متنفریم! این روزا پستگرس تبدیل شده به یکی از محبوب‌ترین دیتابیس‌های رابطه‌ای و روز به روز هم داره به محبوبیتش اضافه میشه اما این بدین معنی نیست که پستگرس مشکلی نداره :)
داخل پستگرس یه مفهومی داریم به اسم MVCC که کمک میکنه تراکنش‌های مختلف به صورت همزمان داخل پایگاه داده اجرا بشن بدون اینکه روی داده‌های هم‌دیگه اثر بذارن و isolation رو نقض کنن.
این مطلب به صورت عمیق به توضیح MVCC توی دیتابیس‌ها علی‌الخصوص پستگرس می‌پردازه و مشکلات روشی که پسترگس رفته رو بیان میکنه. اینکه توی پسترگس نیاز به VACCUM دوره‌ای داریم یا مشکل Table bloatیا اینکه آپدیت کردن یک ستون از یه ردیف باعث میشه کل داده‌های ردیف کپی بشن به همین مفهوم مربوطه.
این مطلب دید خیلی خوبی به internals پستگرس میده و به کسایی که دوست دارن توی پستگرس و دیتابیس‌ها عمیق بشن توصیه میشه
✴️ @software_inside - مهندسی‌نرم‌افزار
Andy Pavlo - Carnegie Mellon University
The Part of PostgreSQL We Hate the Most
As much as Andy loves PostgreSQL, there is one part that is terrible and causes many headaches for people. Learn what it is and why it sucks.
#مطلب
Time to upgrade your monitor
https://tonsky.me/blog/monitors/
🖥 برای برنامه‌نویسی چه مانیتوری داشته باشیم خوبه؟! مطلب بالا مفصل به این قضیه می‌پردازه و یه سری پیشنهاد در این زمینه میکنه که پایین همین پست خلاصش رو نوشتم.
یکی از چیزایی که مهمه Text Clarity و کیفیت نمایش متن‌هاست. خیلیا فک میکنن resolution تنها ملاک کیفیته و اگر مثلا صفحه‌ای FullHD باشه کیفیتش خوبه. اما این همه‌ی ماجرا نیست!
1. برای اینکه کیفیت نمایش بالا بره باید چگالی پیکسل‌های صفحه یا Pixels Per Inch بیشتر باشه. مثلا یه مانیتور 24 اینچ FullHD دارای 92 پیکس در هر اینچه در صورتی که مانیتور 27 اینچ دارای 82 پیکسل در هر اینچه و کیفیتش از 24 اینچ کمتره. هرچه PPI بیشتر باشه، جزئیات بهتر نمایش داده میشه و کیفیتش بالاتر میره.
2. دومین موردی که مهمه فاصله‌ی چشم ما تا ماینتوره، هرچقدر ما صفحه رو نزدیک‌تر به چشممون بذاریم پیکسل‌هاش بیشتر توی چشم میزنه و کیفیت پایین‌تر جلوه میکنه. برای همینه که چگالی پیکسل توی گوشی‌های موبایل معمولا از مانیتورها خیلی بیشتره. چون آدما صفحه‌ی موبایل رو خیلی نزدیک به چشم میگیرن و اگر PPI پایین باشه به راحتی پیکسل‌های تصویر مشخص میشه و توی ذوق میزنه. اگر فاصلتون از صفحه به حدی باشه که چشمتون نتونه پیکسل‌ها رو از هم تشخیص بده، اصطلاحا میگن شما در فاصله Retina هستید. این کلمه توسط اپل معرفی شده. برای اینکه یه صفحه‌ی 24 اینچ FullHD به صورت رتینا به نظر برسه شما باید از فاصله 94 سانتی متری بهش نگاه کنید!
3. سومین موردی که مهمه میزان refresh rate مانیتور هست که با واحد Frame per second سنجیده میشه. هرچقدر FPS بالاتر باشه تغییرات رو نرمتر و روونتر می‌بینید. این قضیه مخصوصا برای زمانی که دارید متن‌ها رو اسکرول میکنید به چشم میاد.
حالا مطلب بالا به صورت کامل نکات مهم رو توضیح میده و درنهایت توصیه‌های زیر رو میکنه:
- مانیتور حداقل 4K باشه
- حداقل FPS برابر با 120hz باشه
- از Integer Scaling استفاده کنید(توضیح کاملش توی متن هست. من برای بزرگ نشدن پست اینجا توضیحش نمی‌دم)
پیشنهاد خودم اینه که ماینتور 27 اینچ باشه. چون نه خیلی کوچیکه نه خیلی بزرگ. همچنین برای اینکه صفحه رتینا به نظر بیاد باید فاصله 53 سانتی از مانیتور داشته باشید که فاصله نرمالیه برای یه مانیتور. توی سایت زیر توضیحات کاملی در مورد PPI و فاصله retina وجود داره. عکس جدول فواصل رو توی پست گذاشتم.
لینک
تجربه‌ی شما توی این زمینه چیه؟ چقدر موافقید با این مطلب؟
✴️ @software_inside - مهندسی‌نرم‌افزار
Time to upgrade your monitor
https://tonsky.me/blog/monitors/
یکی از چیزایی که مهمه Text Clarity و کیفیت نمایش متن‌هاست. خیلیا فک میکنن resolution تنها ملاک کیفیته و اگر مثلا صفحه‌ای FullHD باشه کیفیتش خوبه. اما این همه‌ی ماجرا نیست!
1. برای اینکه کیفیت نمایش بالا بره باید چگالی پیکسل‌های صفحه یا Pixels Per Inch بیشتر باشه. مثلا یه مانیتور 24 اینچ FullHD دارای 92 پیکس در هر اینچه در صورتی که مانیتور 27 اینچ دارای 82 پیکسل در هر اینچه و کیفیتش از 24 اینچ کمتره. هرچه PPI بیشتر باشه، جزئیات بهتر نمایش داده میشه و کیفیتش بالاتر میره.
2. دومین موردی که مهمه فاصله‌ی چشم ما تا ماینتوره، هرچقدر ما صفحه رو نزدیک‌تر به چشممون بذاریم پیکسل‌هاش بیشتر توی چشم میزنه و کیفیت پایین‌تر جلوه میکنه. برای همینه که چگالی پیکسل توی گوشی‌های موبایل معمولا از مانیتورها خیلی بیشتره. چون آدما صفحه‌ی موبایل رو خیلی نزدیک به چشم میگیرن و اگر PPI پایین باشه به راحتی پیکسل‌های تصویر مشخص میشه و توی ذوق میزنه. اگر فاصلتون از صفحه به حدی باشه که چشمتون نتونه پیکسل‌ها رو از هم تشخیص بده، اصطلاحا میگن شما در فاصله Retina هستید. این کلمه توسط اپل معرفی شده. برای اینکه یه صفحه‌ی 24 اینچ FullHD به صورت رتینا به نظر برسه شما باید از فاصله 94 سانتی متری بهش نگاه کنید!
3. سومین موردی که مهمه میزان refresh rate مانیتور هست که با واحد Frame per second سنجیده میشه. هرچقدر FPS بالاتر باشه تغییرات رو نرمتر و روونتر می‌بینید. این قضیه مخصوصا برای زمانی که دارید متن‌ها رو اسکرول میکنید به چشم میاد.
حالا مطلب بالا به صورت کامل نکات مهم رو توضیح میده و درنهایت توصیه‌های زیر رو میکنه:
- مانیتور حداقل 4K باشه
- حداقل FPS برابر با 120hz باشه
- از Integer Scaling استفاده کنید(توضیح کاملش توی متن هست. من برای بزرگ نشدن پست اینجا توضیحش نمی‌دم)
پیشنهاد خودم اینه که ماینتور 27 اینچ باشه. چون نه خیلی کوچیکه نه خیلی بزرگ. همچنین برای اینکه صفحه رتینا به نظر بیاد باید فاصله 53 سانتی از مانیتور داشته باشید که فاصله نرمالیه برای یه مانیتور. توی سایت زیر توضیحات کاملی در مورد PPI و فاصله retina وجود داره. عکس جدول فواصل رو توی پست گذاشتم.
لینک
تجربه‌ی شما توی این زمینه چیه؟ چقدر موافقید با این مطلب؟
✴️ @software_inside - مهندسی‌نرم‌افزار
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥3👌2
Forwarded from LLM Engineers
یه بحثی که همیشه داغه، این همه عنوان شغلی تو حوزه AI از کجا میاد و فرقشون چیه. خیلی از این عناوین یا توسط HRها ساخته شدن یا صرفاً برای هایپ و جذب نیرو هستن. واقعیت اینه که مرز بین این نقش‌ها خیلی باریکه و تو شرکت‌های مختلف، شرح وظایف یه AI Engineer میتونه زمین تا آسمون فرق کنه. اینجا سعی میکنم یه دسته‌بندی منطقی و به دور از هایپ از این نقش‌ها بدم.
هسته‌ی فنی و مهندسی (The Core Engineers)
اینجا با نقش‌هایی طرفیم که بیس کار AI رو تشکیل میدن و بیشترین هم‌پوشانی رو دارن.
ML Engineer:
میشه گفت این اصلی‌ترین و جاافتاده‌ترین عنوانه. کارش ساخت، آموزش و دیپلوی مدل‌های machine learning هست. از ساخت data pipeline گرفته تا training و مانیتورینگ مدل تو پروداکشن، همه با این شخصه. ابزارهاش هم Python، فریمورک‌هایی مثل PyTorch و TensorFlow و ابزارهای MLOps هست.
AI Engineer:
این عنوان یه کم کلی‌تر از ML Engineer هست. یه AI Engineer ممکنه روی سیستم‌های AI که لزوماً learning-based نیستن هم کار کنه (مثلاً سیستم‌های rule-based یا optimization). اما در عمل، ۹۰ درصد مواقع شرکت‌ها از این عنوان به جای ML Engineer استفاده میکنن و فرق خاصی بینشون نیست.
Deep Learning Engineer:
این یه تخصص از ML Engineer به حساب میاد. تمرکزش فقط روی شبکه‌های عصبی عمیق و معماری‌های پیچیده‌ست. این افراد معمولاً روی مسائل Computer Vision یا NLP کار میکنن که مدل‌های ساده جواب نمیدن. باید درک عمیقی از GPU، بهینه‌سازی و ریاضیات پشت این مدل‌ها داشته باشه.
بچه‌های پروداکت و نرم‌افزار (The Application Layer)
این گروه کارشون اینه که AI رو از فاز تئوری و مدل، بیارن تو دل یه محصول واقعی.
Applied AI Engineer:
این عنوان یعنی «بیا این مدل رو بردار و یه مشکل واقعی تو بیزینس رو باهاش حل کن». تفاوتش با ML Engineer اینه که تمرکزش روی کاربرد و بیزینسه، نه لزوماً ساخت بهترین مدل. باید دانش دامنه (مثلاً مالی یا پزشکی) داشته باشه و بتونه سریع prototype بسازه.
AI Software Engineer:
این یه مهندس نرم‌افزاره که AI هم بلده. کار اصلیش software engineering هست ولی میتونه مدل‌های آماده رو تو یه اپلیکیشن بزرگ‌تر ادغام کنه. کدنویسی تمیز، معماری نرم‌افزار و کار با APIها براش مهم‌تر از خودِ الگوریتم‌هاست.
موج جدید: متخصص‌های GenAI و LLM
اینا نقش‌هایی هستن که با ظهور Generative AI و LLMها به وجود اومدن و هنوز خیلی‌هاشون به بلوغ نرسیدن.
LLM Engineer:
کار این شخص تماماً حول Large Language Models می‌گرده. از fine-tuning کردن مدل‌ها با تکنیک‌های PEFT مثل LoRA گرفته تا بهینه‌سازی inference و کار با ابزارهای مرتبط. این نقش الان خیلی رو بورسه.
AI Agent Developer:
این نقش روی ساخت ایجنت‌های هوشمند و خودمختار تمرکز داره که میتونن با استفاده از LLM و ابزارهای دیگه، وظایف چندمرحله‌ای رو انجام بدن. کار با فریمورک‌هایی مثل LangChain یا ساخت سیستم‌های planning و reasoning جزو کارشونه.
زیرساخت و عملیات (The Infrastructure & Ops)
اینا کسایی هستن که چرخ‌دنده‌های سیستم‌های AI رو روغن‌کاری میکنن تا همه چیز روان کار کنه.
MLOps Engineer:
این شخص مسئول اتوماسیون و مدیریت چرخه حیات مدل‌های ML هست. کارش ساخت CI/CD pipeline برای مدل‌ها، مانیتورینگ، ورژن‌بندی و تضمین scalability اونهاست. با ابزارهایی مثل Kubernetes، Kubeflow و Prometheus سر و کار داره. مدل نمیسازه، ولی کمک میکنه مدل‌ها به درستی دیپلوی بشن و زنده بمونن.
LLMOps Engineer:
این همون MLOps هست ولی برای دنیای LLMها. چالش‌های LLMها مثل هزینه‌های سرسام‌آور inference، مدیریت پرامپت‌ها و مانیتورینگ hallucination باعث شده این تخصص جدید به وجود بیاد.
استراتژیست‌ها و محقق‌ها (The Big Picture & Research)
این گروه یا در لبه‌ی دانش حرکت میکنن یا تصویر بزرگ سیستم رو طراحی میکنن.
AI Researcher / Research Scientist:
کارش تحقیق و توسعه‌ی الگوریتم‌ها و روش‌های جدیده. این افراد معمولاً درگیر انتشار مقاله و کارهای آکادمیک هستن و کمتر با پروداکشن درگیرن. معمولاً مدرک دکترا دارن و ریاضیشون خیلی قویه.
Data Scientist:
این نقش بیشتر به تحلیل داده و کشف insight مرتبطه تا مهندسی. از ML استفاده میکنه تا الگوها رو پیدا کنه و به سوالات بیزینس جواب بده. خروجیش معمولاً گزارش، داشبورد و مدل‌های پیش‌بینی‌کننده‌ست، نه یه سیستم نرم‌افزاری production-grade.
در نهایت، این عناوین فقط برچسب هستن. مهم اینه که شما روی مهارت‌های اصلی مثل برنامه‌نویسی، درک عمیق الگوریتم‌ها و مهندسی نرم‌افزار تمرکز کنید. این مهارت‌ها همیشه ارزشمندن، حتی اگه فردا عنوان شغلی جدیدی مد بشه.
🛠 Join @LLMEngineers Community
هسته‌ی فنی و مهندسی (The Core Engineers)
اینجا با نقش‌هایی طرفیم که بیس کار AI رو تشکیل میدن و بیشترین هم‌پوشانی رو دارن.
ML Engineer:
میشه گفت این اصلی‌ترین و جاافتاده‌ترین عنوانه. کارش ساخت، آموزش و دیپلوی مدل‌های machine learning هست. از ساخت data pipeline گرفته تا training و مانیتورینگ مدل تو پروداکشن، همه با این شخصه. ابزارهاش هم Python، فریمورک‌هایی مثل PyTorch و TensorFlow و ابزارهای MLOps هست.
AI Engineer:
این عنوان یه کم کلی‌تر از ML Engineer هست. یه AI Engineer ممکنه روی سیستم‌های AI که لزوماً learning-based نیستن هم کار کنه (مثلاً سیستم‌های rule-based یا optimization). اما در عمل، ۹۰ درصد مواقع شرکت‌ها از این عنوان به جای ML Engineer استفاده میکنن و فرق خاصی بینشون نیست.
Deep Learning Engineer:
این یه تخصص از ML Engineer به حساب میاد. تمرکزش فقط روی شبکه‌های عصبی عمیق و معماری‌های پیچیده‌ست. این افراد معمولاً روی مسائل Computer Vision یا NLP کار میکنن که مدل‌های ساده جواب نمیدن. باید درک عمیقی از GPU، بهینه‌سازی و ریاضیات پشت این مدل‌ها داشته باشه.
بچه‌های پروداکت و نرم‌افزار (The Application Layer)
این گروه کارشون اینه که AI رو از فاز تئوری و مدل، بیارن تو دل یه محصول واقعی.
Applied AI Engineer:
این عنوان یعنی «بیا این مدل رو بردار و یه مشکل واقعی تو بیزینس رو باهاش حل کن». تفاوتش با ML Engineer اینه که تمرکزش روی کاربرد و بیزینسه، نه لزوماً ساخت بهترین مدل. باید دانش دامنه (مثلاً مالی یا پزشکی) داشته باشه و بتونه سریع prototype بسازه.
AI Software Engineer:
این یه مهندس نرم‌افزاره که AI هم بلده. کار اصلیش software engineering هست ولی میتونه مدل‌های آماده رو تو یه اپلیکیشن بزرگ‌تر ادغام کنه. کدنویسی تمیز، معماری نرم‌افزار و کار با APIها براش مهم‌تر از خودِ الگوریتم‌هاست.
موج جدید: متخصص‌های GenAI و LLM
اینا نقش‌هایی هستن که با ظهور Generative AI و LLMها به وجود اومدن و هنوز خیلی‌هاشون به بلوغ نرسیدن.
LLM Engineer:
کار این شخص تماماً حول Large Language Models می‌گرده. از fine-tuning کردن مدل‌ها با تکنیک‌های PEFT مثل LoRA گرفته تا بهینه‌سازی inference و کار با ابزارهای مرتبط. این نقش الان خیلی رو بورسه.
AI Agent Developer:
این نقش روی ساخت ایجنت‌های هوشمند و خودمختار تمرکز داره که میتونن با استفاده از LLM و ابزارهای دیگه، وظایف چندمرحله‌ای رو انجام بدن. کار با فریمورک‌هایی مثل LangChain یا ساخت سیستم‌های planning و reasoning جزو کارشونه.
زیرساخت و عملیات (The Infrastructure & Ops)
اینا کسایی هستن که چرخ‌دنده‌های سیستم‌های AI رو روغن‌کاری میکنن تا همه چیز روان کار کنه.
MLOps Engineer:
این شخص مسئول اتوماسیون و مدیریت چرخه حیات مدل‌های ML هست. کارش ساخت CI/CD pipeline برای مدل‌ها، مانیتورینگ، ورژن‌بندی و تضمین scalability اونهاست. با ابزارهایی مثل Kubernetes، Kubeflow و Prometheus سر و کار داره. مدل نمیسازه، ولی کمک میکنه مدل‌ها به درستی دیپلوی بشن و زنده بمونن.
LLMOps Engineer:
این همون MLOps هست ولی برای دنیای LLMها. چالش‌های LLMها مثل هزینه‌های سرسام‌آور inference، مدیریت پرامپت‌ها و مانیتورینگ hallucination باعث شده این تخصص جدید به وجود بیاد.
استراتژیست‌ها و محقق‌ها (The Big Picture & Research)
این گروه یا در لبه‌ی دانش حرکت میکنن یا تصویر بزرگ سیستم رو طراحی میکنن.
AI Researcher / Research Scientist:
کارش تحقیق و توسعه‌ی الگوریتم‌ها و روش‌های جدیده. این افراد معمولاً درگیر انتشار مقاله و کارهای آکادمیک هستن و کمتر با پروداکشن درگیرن. معمولاً مدرک دکترا دارن و ریاضیشون خیلی قویه.
Data Scientist:
این نقش بیشتر به تحلیل داده و کشف insight مرتبطه تا مهندسی. از ML استفاده میکنه تا الگوها رو پیدا کنه و به سوالات بیزینس جواب بده. خروجیش معمولاً گزارش، داشبورد و مدل‌های پیش‌بینی‌کننده‌ست، نه یه سیستم نرم‌افزاری production-grade.
در نهایت، این عناوین فقط برچسب هستن. مهم اینه که شما روی مهارت‌های اصلی مثل برنامه‌نویسی، درک عمیق الگوریتم‌ها و مهندسی نرم‌افزار تمرکز کنید. این مهارت‌ها همیشه ارزشمندن، حتی اگه فردا عنوان شغلی جدیدی مد بشه.
🛠 Join @LLMEngineers Community
👌1
#talk #postgres
Hands On PostgreSQL 18
هفته‌ی پیش نسخه‌ی جدید پستگرس منتشر شده و تغییرات زیادی داشته. ارائه‌ی پایین خیلی خوب این تغییرات رو توضیح میده و با نسخه‌های قبلی مقایسه میکنه و بنچ‌مارک میگیره.
دوتا از چیزایی که به نظرم جالب اومد این دوتاست:
مورد اول Async I/O: از این نسخه به بعد شما می‌تونید IO های دیتابیس رو به صورت Async انجام بدید. به صورت پیشفرض پستگرس سه تا پراسس دیگه برای هندل کردن IO میاره بالا که اینا IO رو انجام میدن؛ این روش کوئری‌ها رو بهتر میکنه اما بهترین نیست. اگر روی لینوکس باشید و نسخه‌ی کرنل +6.5 باشه می‌تونید از سیستم‌کال‌های io_uring استفاده کنید که اسکن‌ها رو خیلی خیلی سریع‌تر میکنه. توی ارائه تنظیم کردنش و بنچ‌مارک‌هاش رو نشون میده.
مورد دوم Btree skip scan هست. تا الان اگر شما روی سه تا فیلد ایندکس میذاشتید(مثلا به ترتیب روی a و b و c)، اگر کوئری میزدید که b توش بود ولی a نبود از این ایندکس استفاده نمیشد. در واقع همیشه یه prefix ایی از فیلدهایی که ایندکس کردید باید توی کوئریتون می‌بود تا این ایندکس استفاده بشه. اما توی نسخه‌ی 18 این قابلیت اضافه شده که این ایندکس‌ها توی کوئری‌هایی که prefix ندارن هم استفاده بشه. مثلا توی مثال ما اگر فقط روی b کوئری بزنید بازم از این ایندکس استفاده میشه. این قابلیت مخصوصا وقتی cardinality ستون‌های اول کمتره باعث میشه به ایندکس‌های کمتری نیاز داشته باشید.
YouTube: Hands On PostgreSQL 18
✴️ @software_inside - مهندسی‌نرم‌افزار
Hands On PostgreSQL 18
هفته‌ی پیش نسخه‌ی جدید پستگرس منتشر شده و تغییرات زیادی داشته. ارائه‌ی پایین خیلی خوب این تغییرات رو توضیح میده و با نسخه‌های قبلی مقایسه میکنه و بنچ‌مارک میگیره.
دوتا از چیزایی که به نظرم جالب اومد این دوتاست:
مورد اول Async I/O: از این نسخه به بعد شما می‌تونید IO های دیتابیس رو به صورت Async انجام بدید. به صورت پیشفرض پستگرس سه تا پراسس دیگه برای هندل کردن IO میاره بالا که اینا IO رو انجام میدن؛ این روش کوئری‌ها رو بهتر میکنه اما بهترین نیست. اگر روی لینوکس باشید و نسخه‌ی کرنل +6.5 باشه می‌تونید از سیستم‌کال‌های io_uring استفاده کنید که اسکن‌ها رو خیلی خیلی سریع‌تر میکنه. توی ارائه تنظیم کردنش و بنچ‌مارک‌هاش رو نشون میده.
مورد دوم Btree skip scan هست. تا الان اگر شما روی سه تا فیلد ایندکس میذاشتید(مثلا به ترتیب روی a و b و c)، اگر کوئری میزدید که b توش بود ولی a نبود از این ایندکس استفاده نمیشد. در واقع همیشه یه prefix ایی از فیلدهایی که ایندکس کردید باید توی کوئریتون می‌بود تا این ایندکس استفاده بشه. اما توی نسخه‌ی 18 این قابلیت اضافه شده که این ایندکس‌ها توی کوئری‌هایی که prefix ندارن هم استفاده بشه. مثلا توی مثال ما اگر فقط روی b کوئری بزنید بازم از این ایندکس استفاده میشه. این قابلیت مخصوصا وقتی cardinality ستون‌های اول کمتره باعث میشه به ایندکس‌های کمتری نیاز داشته باشید.
YouTube: Hands On PostgreSQL 18
✴️ @software_inside - مهندسی‌نرم‌افزار
Transactional Outbox Pattern
فرض کنید یه مولفه‌ای دارید که باید توی دیتابیس یه سری رکورد رو تغییر بده و بعدش نتیجه رو بفرسته داخل یه بروکری مثل کافکا یا RabbitMQ. برامون مهمه که این فرایند کلا atomic باشه و ارسال پیام و آپدیت دیتابیس یا کلا انجام بشن یا انجام نشن. چون دوتا سیستم مختلف داریم(مثلا Postgres و RabbitMQ) استفاده از قابلیت تراکنش هر کدومشون به تنهایی کافی نیست و اینا باید باهم ترکیبی کار کنن تا واقعا تراکنشی که میخوایم اتفاق بیافته. توی این شرایط چی کار میشه کرد؟
یکی از راه‌هایی که وجود داره استفاده از Outbox pattern هست. توی این روش میگه بیاین مولفه رو به دوتا پراسس بشکونید. پراسس اول کارهایی که لازمه رو انجام بده و به جای اینکه پیام رو مستقیما به بروکر بفرسته، به جاش توی یه جدولی به اسم outbox بیاد یه پیامی که باید فرستاده بشه رو insert کنید. اینطوری چون فقط یه دیتابیس دارید می‌تونید از قابلیت تراکنش اون سیستم به تنهایی استفاده کنید. پراسس دوم که ما بهش میگیم Message Relay کارش اینه که از جدول outbox پیام‌ها رو بخونه و بفرسته به بروکر و بعد پاکشون کنه. اینطوری مشکل داشتن تراکنش بین دوتا سیستم مختلف حل میشه.
مشکلش چیه؟ مشکل اینه که Message Relay ممکنه فیل بشه یا وسط کار ری‌استارت بشه و یه پیام رو دوبار بفرسته. برای همین مهمه که توی سمت گیرنده idempotent باشه و حواسش به پیام‌های duplicate باشه. البته مستقل از این پترن، توی سیستم‌های توزیع شده این idempotent بودن سمت کانسیومر رو خوبه کلا رعایت کنیم چون فرض Exactly Once معمولا خیلی سخته و بروکرها معمولا At least once delivery رو گارانتی میکنن که بازم نیاز به idempotent بودن کانسیومر داره.
به جز روش Outbox برای این مسئله روش‌های دیگه‌ای مثل پترن CDC یا two phase commit هم هست که اونا پیچیده‌تر هستن و پیاده‌سازیشون دردسر بیشتری داره.
مطلب پایین این پترن رو به خوبی باز کرده و توضیح داده:
https://microservices.io/patterns/data/transactional-outbox.html
#pattern #microservices
✴️ @software_inside - مهندسی‌نرم‌افزار
فرض کنید یه مولفه‌ای دارید که باید توی دیتابیس یه سری رکورد رو تغییر بده و بعدش نتیجه رو بفرسته داخل یه بروکری مثل کافکا یا RabbitMQ. برامون مهمه که این فرایند کلا atomic باشه و ارسال پیام و آپدیت دیتابیس یا کلا انجام بشن یا انجام نشن. چون دوتا سیستم مختلف داریم(مثلا Postgres و RabbitMQ) استفاده از قابلیت تراکنش هر کدومشون به تنهایی کافی نیست و اینا باید باهم ترکیبی کار کنن تا واقعا تراکنشی که میخوایم اتفاق بیافته. توی این شرایط چی کار میشه کرد؟
یکی از راه‌هایی که وجود داره استفاده از Outbox pattern هست. توی این روش میگه بیاین مولفه رو به دوتا پراسس بشکونید. پراسس اول کارهایی که لازمه رو انجام بده و به جای اینکه پیام رو مستقیما به بروکر بفرسته، به جاش توی یه جدولی به اسم outbox بیاد یه پیامی که باید فرستاده بشه رو insert کنید. اینطوری چون فقط یه دیتابیس دارید می‌تونید از قابلیت تراکنش اون سیستم به تنهایی استفاده کنید. پراسس دوم که ما بهش میگیم Message Relay کارش اینه که از جدول outbox پیام‌ها رو بخونه و بفرسته به بروکر و بعد پاکشون کنه. اینطوری مشکل داشتن تراکنش بین دوتا سیستم مختلف حل میشه.
مشکلش چیه؟ مشکل اینه که Message Relay ممکنه فیل بشه یا وسط کار ری‌استارت بشه و یه پیام رو دوبار بفرسته. برای همین مهمه که توی سمت گیرنده idempotent باشه و حواسش به پیام‌های duplicate باشه. البته مستقل از این پترن، توی سیستم‌های توزیع شده این idempotent بودن سمت کانسیومر رو خوبه کلا رعایت کنیم چون فرض Exactly Once معمولا خیلی سخته و بروکرها معمولا At least once delivery رو گارانتی میکنن که بازم نیاز به idempotent بودن کانسیومر داره.
به جز روش Outbox برای این مسئله روش‌های دیگه‌ای مثل پترن CDC یا two phase commit هم هست که اونا پیچیده‌تر هستن و پیاده‌سازیشون دردسر بیشتری داره.
مطلب پایین این پترن رو به خوبی باز کرده و توضیح داده:
https://microservices.io/patterns/data/transactional-outbox.html
#pattern #microservices
✴️ @software_inside - مهندسی‌نرم‌افزار
microservices.io
Microservices Pattern: Pattern: Transactional outbox
First, write the message/event to a database OUTBOX table as part of the transaction that updates business objects, and then publish it to a message broker.
Enums in Programming Languages and Exhaustiveness
اخیرا این ویدیو رو توی یوتیوب دیدم که نحوه‌ی تعریف Enum توی زبان‌های برنامه‌نویسی مختلف و امکاناتشون رو بررسی و مقایسه می‌کرد.
یکی از نکاتی که توجهم رو جلب کرد این بود که Golang تقریبا امکانات خاصی برای Enum نداره و باید مقادیر enum رو مثل constant تعریف کنی و حتی اگر دوتا اینام مقادیری با اسم یکسان داشته باشن توی یه فایل اسم‌هاشون باهم تداخل میخوره. واقعا ایده‌ای ندارم در این حد ساده بودن خوبه یا نه ولی فکر میکنم اذیت کننده باشه.
یکی از چیزایی که کلا توی Enum ها کاربردیه قابلیت Exhaustiveness هست. یعنی اگر روی یه متغیر از جنس enum سوویچ کیس یا match زدی خود کامپایلر چک کنه که همه‌ی حالت‌ها پوشش داده شده یا نه و مجبورت کنه همه‌ی حالت‌ها رو پوشش بدی یا صریحا ignore اشون کنی. خوبیش اینه که اگر چندماه بعد به این enum یه مقداری اضافه کنی توی زمان compile متوجه میشی که کجاها رو باید بری پیاده‌سازی کنی و چه مسیرهای جدیدی به کدت اضافه میشه. همچنین احتمال خطا و اینکه یه حالتی رو فراموش کنیم هم از بین میره.
راست و نسخه‌های جدید جاوا این قابلیت رو دارن. جاوا توی نسخه‌های جدید امکانات switch و enum رو خیلی بهبود داده و بهتر کرده که قابل تحسینه.
زبان Rust خیلی enum های کاربردی و قدرتمندی داره. این قابلیت‌ها رو توی بقیه زبون‌ها مثل جاوا و سی‌شارپ با ترکیب sealed interface و value class ها میشه درست کرد اما سینتکس Rust واقعا مختصر و مفیده.
#language_design #enum
✴️ @software_inside - مهندسی‌نرم‌افزار
اخیرا این ویدیو رو توی یوتیوب دیدم که نحوه‌ی تعریف Enum توی زبان‌های برنامه‌نویسی مختلف و امکاناتشون رو بررسی و مقایسه می‌کرد.
یکی از نکاتی که توجهم رو جلب کرد این بود که Golang تقریبا امکانات خاصی برای Enum نداره و باید مقادیر enum رو مثل constant تعریف کنی و حتی اگر دوتا اینام مقادیری با اسم یکسان داشته باشن توی یه فایل اسم‌هاشون باهم تداخل میخوره. واقعا ایده‌ای ندارم در این حد ساده بودن خوبه یا نه ولی فکر میکنم اذیت کننده باشه.
یکی از چیزایی که کلا توی Enum ها کاربردیه قابلیت Exhaustiveness هست. یعنی اگر روی یه متغیر از جنس enum سوویچ کیس یا match زدی خود کامپایلر چک کنه که همه‌ی حالت‌ها پوشش داده شده یا نه و مجبورت کنه همه‌ی حالت‌ها رو پوشش بدی یا صریحا ignore اشون کنی. خوبیش اینه که اگر چندماه بعد به این enum یه مقداری اضافه کنی توی زمان compile متوجه میشی که کجاها رو باید بری پیاده‌سازی کنی و چه مسیرهای جدیدی به کدت اضافه میشه. همچنین احتمال خطا و اینکه یه حالتی رو فراموش کنیم هم از بین میره.
راست و نسخه‌های جدید جاوا این قابلیت رو دارن. جاوا توی نسخه‌های جدید امکانات switch و enum رو خیلی بهبود داده و بهتر کرده که قابل تحسینه.
زبان Rust خیلی enum های کاربردی و قدرتمندی داره. این قابلیت‌ها رو توی بقیه زبون‌ها مثل جاوا و سی‌شارپ با ترکیب sealed interface و value class ها میشه درست کرد اما سینتکس Rust واقعا مختصر و مفیده.
#language_design #enum
✴️ @software_inside - مهندسی‌نرم‌افزار
YouTube
Ranking Enums in Programming Languages
We rank all the different implementations of enums in programming languages, from simple constant collections to proper algebraic datatypes.
This video was voiced using Elevenlabs for privacy reasons. If you want to try it out yourself, you can sign up using…
This video was voiced using Elevenlabs for privacy reasons. If you want to try it out yourself, you can sign up using…