در ادامه یک خلاصه‌ی کاربردی و دقیق از مقاله‌ی Gunnar Morling با عنوان «Postgres Replication Slots: Confirmed Flush LSN vs. Restart LSN»:
---
موضوع مقاله
در PostgreSQL، replication slots نقش حیاتی در نگهداری و مدیریت WAL (Write-Ahead Log) دارند تا مصرف‌کنندگان (مانند replicas یا ابزارهای CDC مثل Debezium) بتوانند بعد از قطع ارتباط، با اطمینان ادامه دهند. برای این منظور، دو شاخص LSN مهم وجود دارد:
---
اهمیت درک تفاوت آنها
* اگر
* تعداد WALی که باید نگه‌داشته شوند برابر است با فاصله‌ی بین این دو LSN — این فاصلۀ WAL مصرفی در سیستم را تعیین می‌کند.
* اگر این فاصله بسیار بزرگ شود، ممکن است disk overflow (WAL bloat) رخ دهد و یا replication slot منسوخ شود.
---
نکته کلیدی از جامعه PostgreSQL
یکی از کاربران در StackOverflow توضیح داده:
ا>
---
جمع‌بندی مفید
ا* `confirmed_flush_lsn`: نشان‌دهنده پیشرفت واقعی مصرف‌کننده (چه را دریافت کرده‌ایم).
ا* `restart_lsn`: نشان‌دهنده حداقل WALی که برای ادامه decoding نیاز داریم.
ا* فاصله بین این دو LSN نشانگر حجم WAL مورد نیاز است که باید حفظ شود تا سیستم replication به درستی کار کند.
ا* در تولید، مانیتور کردن این شاخص‌ها و تنظیماتی مثل
---
موضوع مقاله
در PostgreSQL، replication slots نقش حیاتی در نگهداری و مدیریت WAL (Write-Ahead Log) دارند تا مصرف‌کنندگان (مانند replicas یا ابزارهای CDC مثل Debezium) بتوانند بعد از قطع ارتباط، با اطمینان ادامه دهند. برای این منظور، دو شاخص LSN مهم وجود دارد:
confirmed_flush_lsn و restart_lsn. دانستن تفاوت این دو برای عیب‌یابی replication و بهینه‌سازی نگهداری WAL ضروری است ---
اهمیت درک تفاوت آنها
* اگر
confirmed_flush_lsn پیشرفت کرده اما restart_lsn همچنان ایستا باشد، به این معنی است که هنوز WAL قدیمی برای complete decoding مورد نیاز است.* تعداد WALی که باید نگه‌داشته شوند برابر است با فاصله‌ی بین این دو LSN — این فاصلۀ WAL مصرفی در سیستم را تعیین می‌کند.
* اگر این فاصله بسیار بزرگ شود، ممکن است disk overflow (WAL bloat) رخ دهد و یا replication slot منسوخ شود.
---
نکته کلیدی از جامعه PostgreSQL
یکی از کاربران در StackOverflow توضیح داده:
ا>
restart_lsn نمی‌تواند پیش رود تا تراکنش‌های باز که از آن شروع شده‌اند، کامل شوند؛ در حالی که confirmed_flush_lsn با هر تراکنش commitشده پیش می‌رود. ([Database Administrators Stack Exchange][3])---
جمع‌بندی مفید
ا* `confirmed_flush_lsn`: نشان‌دهنده پیشرفت واقعی مصرف‌کننده (چه را دریافت کرده‌ایم).
ا* `restart_lsn`: نشان‌دهنده حداقل WALی که برای ادامه decoding نیاز داریم.
ا* فاصله بین این دو LSN نشانگر حجم WAL مورد نیاز است که باید حفظ شود تا سیستم replication به درستی کار کند.
ا* در تولید، مانیتور کردن این شاخص‌ها و تنظیماتی مثل
max_slot_wal_keep_size به جلوگیری از بروز مشکلات ناشی از نگهداری بیش از حد WAL کمک می‌کند.❤1
درود! مقاله‌ای تحت عنوان «Postgres HA Full-Sync» در سایت Multigres پیدا نکردم، اما در معرفی پروژه Multigres بخش‌های مرتبط با High Availability (HA) و سینک کامل (full sync) به‌وضوح وجود داشت. در ادامه خلاصه‌ای کاربردی و جامع در اختیار داری:
---
## معرفی Multigres
Multigres یک پروژه‌ای‌ست به‌منظور ساخت نسخه‌ای مشابه با Vitess برای PostgreSQL، اما کاملاً سازگار با اکوسیستم Postgres. این معماری با هدف افزایش مقیاس‌پذیری، HA و توزیع جهانی طراحی شده است و همچنان به عملکرد استاندارد PostgreSQL وفادار است.([Supabase][1], [multigres.com][2])
---
ویژگی‌های برجسته مرتبط با HA و Full Sync
* High Availability (اHA):
* پشتیبانی از failover خودکار و ترفیع خودکار replica در صورت خرابی، بنابراین سیستم همیشه آنلاین باقی می‌ماند
* اHorizontal Sharding:
* امکان تقسیم دیتابیس به بخش‌های جداگانه روی سرورهای مختلف با مدیریت خودکار—این قابلیت به افزایش مقیاس‌پذیری کمک می‌کند.([multigres.com][2])
* اConnection Pooling و Query Routing:
* لایه‌های اتصال و هدایت پرس‌و‌جوها به سمت shardها یا replicaهای مناسب، بهینه‌سازی عملکرد و کارایی را در پی دارد.([multigres.com][2])
* اCloud-Native Architecture:
* طراحی شده برای اجرا در محیط‌های Kubernetes با قابلیت‌هایی مانند backup خودکار و مدیریت کلاستر در مناطق جغرافیایی مختلف.([multigres.com][2])
---
در مورد "Full Sync"
در محتوای فراخوان‌شده اشاره مستقیمی به مفهوم full-sync replication نشده است. اما با توجه به اطلاعات اشاره شده، Multigres احتمالاً از تکنیک‌هایی مانند:
* اFailover خودکار و مراکز هماهنگ شده
* سینک دوباره دادهها بین replica و shards پس از قطعی
* رفتار مبتنی بر مدل‌های مشابه دو فازی (Two-Phase Synchronization) مانند آنچه در پادکست پروژه ذکر شد([Postgres FM][3])
برای حفظ هماهنگی و جلوگیری از دادههای ناپایدار یا از دست رفته استفاده می‌کند.
---
## معرفی Multigres
Multigres یک پروژه‌ای‌ست به‌منظور ساخت نسخه‌ای مشابه با Vitess برای PostgreSQL، اما کاملاً سازگار با اکوسیستم Postgres. این معماری با هدف افزایش مقیاس‌پذیری، HA و توزیع جهانی طراحی شده است و همچنان به عملکرد استاندارد PostgreSQL وفادار است.([Supabase][1], [multigres.com][2])
---
ویژگی‌های برجسته مرتبط با HA و Full Sync
* High Availability (اHA):
* پشتیبانی از failover خودکار و ترفیع خودکار replica در صورت خرابی، بنابراین سیستم همیشه آنلاین باقی می‌ماند
* اHorizontal Sharding:
* امکان تقسیم دیتابیس به بخش‌های جداگانه روی سرورهای مختلف با مدیریت خودکار—این قابلیت به افزایش مقیاس‌پذیری کمک می‌کند.([multigres.com][2])
* اConnection Pooling و Query Routing:
* لایه‌های اتصال و هدایت پرس‌و‌جوها به سمت shardها یا replicaهای مناسب، بهینه‌سازی عملکرد و کارایی را در پی دارد.([multigres.com][2])
* اCloud-Native Architecture:
* طراحی شده برای اجرا در محیط‌های Kubernetes با قابلیت‌هایی مانند backup خودکار و مدیریت کلاستر در مناطق جغرافیایی مختلف.([multigres.com][2])
---
در مورد "Full Sync"
در محتوای فراخوان‌شده اشاره مستقیمی به مفهوم full-sync replication نشده است. اما با توجه به اطلاعات اشاره شده، Multigres احتمالاً از تکنیک‌هایی مانند:
* اFailover خودکار و مراکز هماهنگ شده
* سینک دوباره دادهها بین replica و shards پس از قطعی
* رفتار مبتنی بر مدل‌های مشابه دو فازی (Two-Phase Synchronization) مانند آنچه در پادکست پروژه ذکر شد([Postgres FM][3])
برای حفظ هماهنگی و جلوگیری از دادههای ناپایدار یا از دست رفته استفاده می‌کند.
❤2
Forwarded from Bardia & Erfan
🎯 آمادگی کامل IELTS با تدریس خصوصی و آنلاین
👑به دنبال نمره بالا در آیلتس هستی؟
🟢با استاد Mansourian، مدرس با تجربه مهارت‌های
🩵Speaking
🩵Writing
🩵Reading
🩵Listening
رو به بهترین شکل تقویت کن.
📌 کلاس‌ها به صورت آنلاین، خصوصی و روزانه برگزار میشه.
📈 پیشرفت سریع + برنامهریزی دقیق برای رسیدن به هدفت.
💬 همین الان فالو کن و مسیر موفقیتت رو شروع کن!
👇پیج استاد توی انستاگرام 👇
https://www.instagram.com/english_razi_ielts
👑به دنبال نمره بالا در آیلتس هستی؟
🟢با استاد Mansourian، مدرس با تجربه مهارت‌های
🩵Speaking
🩵Writing
🩵Reading
🩵Listening
رو به بهترین شکل تقویت کن.
📌 کلاس‌ها به صورت آنلاین، خصوصی و روزانه برگزار میشه.
📈 پیشرفت سریع + برنامهریزی دقیق برای رسیدن به هدفت.
💬 همین الان فالو کن و مسیر موفقیتت رو شروع کن!
👇پیج استاد توی انستاگرام 👇
https://www.instagram.com/english_razi_ielts
👌🏾Soheib Kiani
۲۰ تکنیک پیشرفته برنامهریزی منابع و مدیریت Performance در دیتابیسهای توزیعشده
Backend High Load
هر یک از این موارد، دانشی عمیق و عملی برای مهندس backend پیشرفته محسوب میشه:
Dynamic Partitioning
ایجاد پارتیشنهای پویا بر اساس زمان یا متریک خاص برای مدیریت حجم اطلاعات (مثلاً زمانبندی حذف خودکار دیتاهای منقضی)
Directory-based Sharding
استفاده از دیتابیس lookup برای نگاشت داده به shardهای مختلف، مناسب برای کنترل رشد داده به تفکیک ویژگی خاص
Range-based Sharding
تقسیم دادهها بر اساس بازه (مثلاً تاریخ یا ID)، به ویژه برای دیتاهای زمانمحور و تحلیلی
Hash-based Sharding
توزیع داده بر اساس هش یک کلید (key)، مناسب جهت پخش یکنواخت بار
Vertical Partitioning
تقسیم جداول بر اساس ستونهای پرمصرف یا کمتر مصرفشده و ذخیره هر بخش روی سرورهای مجزا برای افزایش بهرهوری
Replication (Master-Slave, Multi-Master)
تکثیر دادهها روی چندین node برای دسترسی بالا، redundancy و عملکرد بهتر خواندن؛ شامل Replication همزمان/غیرهمزمان
Change Data Capture (CDC) Replication
ایجاد همگامسازی بلادرنگ دادههای تغییر یافته، برای replication و ETLهای مقیاسپذیر
Data Consistency Models
انتخاب بین eventual consistency، strong consistency برای trade-off سرعت و دقت در سیستمهای توزیعشده
Multi-level Caching
بهرهگیری همزمان از cacheهای local (مثلاً memory app)، shared (مثلاً Redis/Memcached) و edge (CDN) برای حداکثر سرعت و کاهش بار دیتابیس
Cache Invalidation Strategies
استفاده از مکانیزمهایی مثل TTL، event-based، یا manual invalidation برای جلوگیری از stale data و اختلاف دیتا
Consistent Hashing for Distributed Cache
برای جلوگیری از hotspot و توزیع منصفانه کلیدها در cacheهای توزیعشده
Cache Replication
راهاندازی cache master-slave یا cluster برای افزایش دسترسی، توازن بار، و تحمل خرابی (Redis Sentinel, Cluster Mode)
Sharded Cache Architectures
تفکیک و توزیع کلیدهای cache روی چند سرور به شکلی که قابلیت گسترش و توازن بار داشته باشد
Cache Stampede Protection
پیادهسازی سیاستهایی مثل lock یا request coalescing برای جلوگیری از هجوم همزمان درخواستها هنگام miss شدن cache
Read/Write Splitting
هدایت درخواستهای خواندن به replicaها و نوشتن به master (در replication)، برای بهرهوری بیشتر از منابع
Vertical & Horizontal Scalability
استفاده درست از scale-up (افزایش منابع سرور) و scale-out (افزودن node جدید و sharding) وابسته به نیاز پروژه
Automated Partition Rebalancing
جابجایی یا تقسیم خودکار دادهها بین shardها با تغییر توزیع بار، کاهش hotspot و جلوگیری از ترافیک غیرمتعادل
Dynamic Resource Allocation
اختصاص خودکار منابع (مثل CPU, Memory) به shardها و cacheها مبتنی بر مانیتورینگ و نیاز لحظهای
Hybrid Partitioning Strategies
ترکیب partitioning افقی و عمودی برای استفاده بهینه و شخصیسازی تقسیم دیتا در سناریوهای خاص
Advanced Monitoring & Performance Tuning
رهگیری دقیق متریکهایی مثل hit ratio, latency, eviction rate و تنظیمات fine-tune (مثلاً policyهای eviction cache یا تنظیمات replication lag)
۲۰ تکنیک پیشرفته برنامهریزی منابع و مدیریت Performance در دیتابیسهای توزیعشده
Backend High Load
هر یک از این موارد، دانشی عمیق و عملی برای مهندس backend پیشرفته محسوب میشه:
Dynamic Partitioning
ایجاد پارتیشنهای پویا بر اساس زمان یا متریک خاص برای مدیریت حجم اطلاعات (مثلاً زمانبندی حذف خودکار دیتاهای منقضی)
Directory-based Sharding
استفاده از دیتابیس lookup برای نگاشت داده به shardهای مختلف، مناسب برای کنترل رشد داده به تفکیک ویژگی خاص
Range-based Sharding
تقسیم دادهها بر اساس بازه (مثلاً تاریخ یا ID)، به ویژه برای دیتاهای زمانمحور و تحلیلی
Hash-based Sharding
توزیع داده بر اساس هش یک کلید (key)، مناسب جهت پخش یکنواخت بار
Vertical Partitioning
تقسیم جداول بر اساس ستونهای پرمصرف یا کمتر مصرفشده و ذخیره هر بخش روی سرورهای مجزا برای افزایش بهرهوری
Replication (Master-Slave, Multi-Master)
تکثیر دادهها روی چندین node برای دسترسی بالا، redundancy و عملکرد بهتر خواندن؛ شامل Replication همزمان/غیرهمزمان
Change Data Capture (CDC) Replication
ایجاد همگامسازی بلادرنگ دادههای تغییر یافته، برای replication و ETLهای مقیاسپذیر
Data Consistency Models
انتخاب بین eventual consistency، strong consistency برای trade-off سرعت و دقت در سیستمهای توزیعشده
Multi-level Caching
بهرهگیری همزمان از cacheهای local (مثلاً memory app)، shared (مثلاً Redis/Memcached) و edge (CDN) برای حداکثر سرعت و کاهش بار دیتابیس
Cache Invalidation Strategies
استفاده از مکانیزمهایی مثل TTL، event-based، یا manual invalidation برای جلوگیری از stale data و اختلاف دیتا
Consistent Hashing for Distributed Cache
برای جلوگیری از hotspot و توزیع منصفانه کلیدها در cacheهای توزیعشده
Cache Replication
راهاندازی cache master-slave یا cluster برای افزایش دسترسی، توازن بار، و تحمل خرابی (Redis Sentinel, Cluster Mode)
Sharded Cache Architectures
تفکیک و توزیع کلیدهای cache روی چند سرور به شکلی که قابلیت گسترش و توازن بار داشته باشد
Cache Stampede Protection
پیادهسازی سیاستهایی مثل lock یا request coalescing برای جلوگیری از هجوم همزمان درخواستها هنگام miss شدن cache
Read/Write Splitting
هدایت درخواستهای خواندن به replicaها و نوشتن به master (در replication)، برای بهرهوری بیشتر از منابع
Vertical & Horizontal Scalability
استفاده درست از scale-up (افزایش منابع سرور) و scale-out (افزودن node جدید و sharding) وابسته به نیاز پروژه
Automated Partition Rebalancing
جابجایی یا تقسیم خودکار دادهها بین shardها با تغییر توزیع بار، کاهش hotspot و جلوگیری از ترافیک غیرمتعادل
Dynamic Resource Allocation
اختصاص خودکار منابع (مثل CPU, Memory) به shardها و cacheها مبتنی بر مانیتورینگ و نیاز لحظهای
Hybrid Partitioning Strategies
ترکیب partitioning افقی و عمودی برای استفاده بهینه و شخصیسازی تقسیم دیتا در سناریوهای خاص
Advanced Monitoring & Performance Tuning
رهگیری دقیق متریکهایی مثل hit ratio, latency, eviction rate و تنظیمات fine-tune (مثلاً policyهای eviction cache یا تنظیمات replication lag)
❤2
Forwarded from Bardia & Erfan
🤨 دارک مود؛ ناجی چشم‌ها یا یه توهم مدرن...؟!
خیلیا فکر می‌کنن دارک مود برای چشم سالم‌تره، اما تحقیقات علمی چی میگن؟ بررسی مطالعات جدید نشون میده که دارک مود هم مزایا داره، هم معایب!
مزایای علمی دارک مود :
▪️کاهش نور آبی : نور آبی زیاد، ریتم خواب رو مختل می‌کنه، و دارک مود می‌تونه به خواب بهتر کمک کنه.
▪️کاهش مصرف باتری : روی نمایشگرهای OLED، رنگ‌های تیره مصرف انرژی کمتری دارن.
▪️کاهش خیرگی در محیط‌های کم‌نور : وقتی نور اطراف کم باشه، دارک مود فشار کمتری به چشم وارد می‌کنه.
معایب علمی دارک مود :
▪️کاهش خوانایی متن در روز: چشم انسان به خوندن متن تیره روی پس‌زمینه روشن عادت داره، و دارک مود توی نور زیاد باعث خستگی چشم میشه.
▪️برخی تحقیقات نشون میدن که چشم توی حالت دارک مود بیشتر مجبور به تطبیق و تمرکز میشه، که می‌تونه خستگی ایجاد کنه.
▪️برخلاف تصور عموم، تغییر تم به تنهایی تأثیر زیادی روی کاهش خشکی و خستگی چشم نداره، بلکه میزان پلک زدن و استراحت دادن به چشم مهم‌تره.
خیلیا فکر می‌کنن دارک مود برای چشم سالم‌تره، اما تحقیقات علمی چی میگن؟ بررسی مطالعات جدید نشون میده که دارک مود هم مزایا داره، هم معایب!
مزایای علمی دارک مود :
▪️کاهش نور آبی : نور آبی زیاد، ریتم خواب رو مختل می‌کنه، و دارک مود می‌تونه به خواب بهتر کمک کنه.
▪️کاهش مصرف باتری : روی نمایشگرهای OLED، رنگ‌های تیره مصرف انرژی کمتری دارن.
▪️کاهش خیرگی در محیط‌های کم‌نور : وقتی نور اطراف کم باشه، دارک مود فشار کمتری به چشم وارد می‌کنه.
معایب علمی دارک مود :
▪️کاهش خوانایی متن در روز: چشم انسان به خوندن متن تیره روی پس‌زمینه روشن عادت داره، و دارک مود توی نور زیاد باعث خستگی چشم میشه.
▪️برخی تحقیقات نشون میدن که چشم توی حالت دارک مود بیشتر مجبور به تطبیق و تمرکز میشه، که می‌تونه خستگی ایجاد کنه.
▪️برخلاف تصور عموم، تغییر تم به تنهایی تأثیر زیادی روی کاهش خشکی و خستگی چشم نداره، بلکه میزان پلک زدن و استراحت دادن به چشم مهم‌تره.
❤2
Forwarded from Gopher Academy
کدوم هوش مصنوعی رو انتخاب می کنید واسه کارهای برنامه نویسی؟
Anonymous Poll
48%
GPT
12%
Grok
42%
Claude
17%
other
چرا بسیاری از تیم‌ها ORM را کنار می‌گذارند و سراغ SQL خام می‌روند؟
اخیرا در مدیوم با تعداد زیادی از مقاله‌ها مواجه می‌شوم که یک پیام مشترک دارند:
«ما ORM را کنار گذاشتیم و به SQL خام مهاجرت کردیم — و دیگر برنمی‌گردیم.»
نکته جالب اینجاست که این تصمیم‌ها معمولاً از سر عشق به SQL گرفته نشده‌اند، بلکه از دل دردسرهای ORM زاده شده‌اند.
در چند مقاله‌ی اخیر که مطالعه کردم، تیم‌های مختلفی با تکنولوژی‌های مختلف (از Java + Postgres گرفته تا Go + SQLAlchemy) تجربه‌ی مهاجرت از ORM را به اشتراک گذاشته‌اند — نه فقط برای بهبود سرعت، بلکه برای بازگشت به شفافیت، کنترل و عقلانیت.
مشکل کجا بود؟ چرا ORM جوابگو نبود؟
اگرچه ORM در شروع پروژه‌ها خیلی مفید است (خصوصاً برای CRUDهای سریع و MVPها)، اما با رشد سیستم، مشکلاتی کم‌کم خود را نشان می‌دهند:
* معضل N+1 Query
کوئری‌هایی که ساده به نظر می‌رسند، در باطن ده‌ها یا صدها درخواست اضافه تولید می‌کنند.
* کدهای پیچیده اما غیرشفاف
برای کوئری‌های پیچیده‌تر مثل Window Function، CTE یا Join چندجدولی، باید به انواع annotationها، chainهای مبهم، یا زبان‌های خاص ORM (مثل JPQL) متوسل شد — که در نهایت باز هم می‌رسیم به نوشتن SQL، فقط با دردسر بیشتر.
* ضعف در دیباگ و پروفایلینگ
در ORM، به‌سختی می‌شود فهمید دقیقاً چه کوئری‌ای به دیتابیس رفته. این یعنی دیباگِ کندی‌ها تقریباً کورکورانه است.
* ناسازگاری با مدل واقعی دادهها
دیتابیس با row و index و join کار می‌کند؛ ORM با کلاس و رابطه شی‌گرایانه. این تطبیق، به‌ویژه در سیستمهای پیچیده، منجر به کدهایی می‌شود که بیشتر شبیه «جنگیدن با ORM» هستند.
چرا SQL خام یک تفاوت واقعی ایجاد کرد؟
بعد از مهاجرت، همه تیم‌ها روی این دستاوردها تأکید داشتند:
* کنترل کامل
می‌دانیم چه کوئری نوشته‌ایم، چه زمانی اجرا می‌شود، و چگونه می‌توان آن را بهینه کرد.
* شفافیت
کوئری واضح است، بدون «جادوی مخفی». این یعنی همه تیم — از جونیور تا لید — متوجه می‌شود چه اتفاقی می‌افتد.
* هماهنگی بیشتر با منطق دامنه
به‌جای تعریف business logic در repository و annotation، همه‌چیز در لایه‌های مشخص خدماتی و use-case محور قرار می‌گیرد.
* استفاده کامل از قدرت دیتابیس
ویژگی‌هایی مثل Window Function، CTE، JSONB و Partial Index که در ORM اغلب یا پشتیبانی نمی‌شوند یا با پیچیدگی زیاد ممکن‌اند، در SQL خام به‌راحتی قابل استفاده‌اند.
نگهداری و مقیاس‌پذیری چطور مدیریت شد؟
برای جلوگیری از بی‌نظمی، تیم‌ها:
* کوئری‌ها را در فایل‌های جدا و نسخه‌دار نگه داشتند
* از template و query loaderهای سبک استفاده کردند
* روی هر کوئری تست (یا حداقل EXPLAIN) نوشتند
* قواعد ساده ولی سخت‌گیرانه‌ای برای امنیت (مثل پارامترگذاری) اعمال کردند
در نتیجه، برخلاف تصور اولیه، نگهداشت SQL خام هم قابل مدیریت و حتی لذت‌بخش شد.
کی باید ORM را کنار گذاشت؟
تجربه‌ی مشترک تیم‌ها نشان می‌دهد:
* برای پروژه‌های کوچک، MVPها یا پنل‌های ادمین، ORM عالی است.
* اما در پروژه‌های داده‌محور، با ترافیک بالا، کوئری‌های پیچیده و نیاز به کنترل عملکرد، ORM به‌جای کمک، تبدیل به مانع می‌شود.
جمع‌بندی
بسیاری از ما با ORMها بزرگ شده‌ایم اما آیا هنوز ORM بهترین ابزار ماست؟ یا فقط آسان‌ترین است؟
در دنیایی که عملکرد، شفافیت و کنترل ارزش بیشتری از سرعت اولیه دارند، شاید وقت آن است که دوباره به SQL خام یا ترکیب آن با ORm فکر کنیم — این بار با بلوغ بیشتر و ابزارهای بهتر.
<Mojtaba Banaie/>
اخیرا در مدیوم با تعداد زیادی از مقاله‌ها مواجه می‌شوم که یک پیام مشترک دارند:
«ما ORM را کنار گذاشتیم و به SQL خام مهاجرت کردیم — و دیگر برنمی‌گردیم.»
نکته جالب اینجاست که این تصمیم‌ها معمولاً از سر عشق به SQL گرفته نشده‌اند، بلکه از دل دردسرهای ORM زاده شده‌اند.
در چند مقاله‌ی اخیر که مطالعه کردم، تیم‌های مختلفی با تکنولوژی‌های مختلف (از Java + Postgres گرفته تا Go + SQLAlchemy) تجربه‌ی مهاجرت از ORM را به اشتراک گذاشته‌اند — نه فقط برای بهبود سرعت، بلکه برای بازگشت به شفافیت، کنترل و عقلانیت.
مشکل کجا بود؟ چرا ORM جوابگو نبود؟
اگرچه ORM در شروع پروژه‌ها خیلی مفید است (خصوصاً برای CRUDهای سریع و MVPها)، اما با رشد سیستم، مشکلاتی کم‌کم خود را نشان می‌دهند:
* معضل N+1 Query
کوئری‌هایی که ساده به نظر می‌رسند، در باطن ده‌ها یا صدها درخواست اضافه تولید می‌کنند.
* کدهای پیچیده اما غیرشفاف
برای کوئری‌های پیچیده‌تر مثل Window Function، CTE یا Join چندجدولی، باید به انواع annotationها، chainهای مبهم، یا زبان‌های خاص ORM (مثل JPQL) متوسل شد — که در نهایت باز هم می‌رسیم به نوشتن SQL، فقط با دردسر بیشتر.
* ضعف در دیباگ و پروفایلینگ
در ORM، به‌سختی می‌شود فهمید دقیقاً چه کوئری‌ای به دیتابیس رفته. این یعنی دیباگِ کندی‌ها تقریباً کورکورانه است.
* ناسازگاری با مدل واقعی دادهها
دیتابیس با row و index و join کار می‌کند؛ ORM با کلاس و رابطه شی‌گرایانه. این تطبیق، به‌ویژه در سیستمهای پیچیده، منجر به کدهایی می‌شود که بیشتر شبیه «جنگیدن با ORM» هستند.
چرا SQL خام یک تفاوت واقعی ایجاد کرد؟
بعد از مهاجرت، همه تیم‌ها روی این دستاوردها تأکید داشتند:
* کنترل کامل
می‌دانیم چه کوئری نوشته‌ایم، چه زمانی اجرا می‌شود، و چگونه می‌توان آن را بهینه کرد.
* شفافیت
کوئری واضح است، بدون «جادوی مخفی». این یعنی همه تیم — از جونیور تا لید — متوجه می‌شود چه اتفاقی می‌افتد.
* هماهنگی بیشتر با منطق دامنه
به‌جای تعریف business logic در repository و annotation، همه‌چیز در لایه‌های مشخص خدماتی و use-case محور قرار می‌گیرد.
* استفاده کامل از قدرت دیتابیس
ویژگی‌هایی مثل Window Function، CTE، JSONB و Partial Index که در ORM اغلب یا پشتیبانی نمی‌شوند یا با پیچیدگی زیاد ممکن‌اند، در SQL خام به‌راحتی قابل استفاده‌اند.
نگهداری و مقیاس‌پذیری چطور مدیریت شد؟
برای جلوگیری از بی‌نظمی، تیم‌ها:
* کوئری‌ها را در فایل‌های جدا و نسخه‌دار نگه داشتند
* از template و query loaderهای سبک استفاده کردند
* روی هر کوئری تست (یا حداقل EXPLAIN) نوشتند
* قواعد ساده ولی سخت‌گیرانه‌ای برای امنیت (مثل پارامترگذاری) اعمال کردند
در نتیجه، برخلاف تصور اولیه، نگهداشت SQL خام هم قابل مدیریت و حتی لذت‌بخش شد.
کی باید ORM را کنار گذاشت؟
تجربه‌ی مشترک تیم‌ها نشان می‌دهد:
* برای پروژه‌های کوچک، MVPها یا پنل‌های ادمین، ORM عالی است.
* اما در پروژه‌های داده‌محور، با ترافیک بالا، کوئری‌های پیچیده و نیاز به کنترل عملکرد، ORM به‌جای کمک، تبدیل به مانع می‌شود.
جمع‌بندی
بسیاری از ما با ORMها بزرگ شده‌ایم اما آیا هنوز ORM بهترین ابزار ماست؟ یا فقط آسان‌ترین است؟
در دنیایی که عملکرد، شفافیت و کنترل ارزش بیشتری از سرعت اولیه دارند، شاید وقت آن است که دوباره به SQL خام یا ترکیب آن با ORm فکر کنیم — این بار با بلوغ بیشتر و ابزارهای بهتر.
<Mojtaba Banaie/>
💔1
Forwarded from AI Labdon
🤖 علاقه‌مند به دنیای هوش مصنوعی هستی؟
🏖 دنبال می‌کنی که چطور AI داره دنیا رو متحول می‌کنه؟
🍻پس جای درستی اومدی!
🎯 در کانال ما هر روز:
🔍 جدیدترین اخبار و دستاوردهای دنیای AI
🧠 تحلیل تخصصی در حوزه یادگیری ماشین، دیپ لرنینگ و مدل‌های زبانی
💼 بررسی کاربردهای هوش مصنوعی در پزشکی، صنعت، آموزش، امنیت و اقتصاد
🛠 معرفی ابزارها، دوره‌ها و منابع یادگیری
📈 بررسی ترندها و آینده فناوری‌های مرتبط با هوش مصنوعی
🍄همه‌ی این‌ها به زبان ساده، خلاصه و قابل فهم برای همه علاقه‌مندان — از مبتدی تا حرفه‌ای!
👇👇👇👇👇👇
https://t.iss.one/ai_labdon
🏖 دنبال می‌کنی که چطور AI داره دنیا رو متحول می‌کنه؟
🍻پس جای درستی اومدی!
🎯 در کانال ما هر روز:
🔍 جدیدترین اخبار و دستاوردهای دنیای AI
🧠 تحلیل تخصصی در حوزه یادگیری ماشین، دیپ لرنینگ و مدل‌های زبانی
💼 بررسی کاربردهای هوش مصنوعی در پزشکی، صنعت، آموزش، امنیت و اقتصاد
🛠 معرفی ابزارها، دوره‌ها و منابع یادگیری
📈 بررسی ترندها و آینده فناوری‌های مرتبط با هوش مصنوعی
🍄همه‌ی این‌ها به زبان ساده، خلاصه و قابل فهم برای همه علاقه‌مندان — از مبتدی تا حرفه‌ای!
👇👇👇👇👇👇
https://t.iss.one/ai_labdon
Forwarded from Notification
🔵 عنوان مقاله
VectorChord 0.5: Scalable, Fast, and Disk-Friendly Vector Search
🟢 خلاصه مقاله:
این پروژه یک افزونه متن‌باز جست‌وجوی برداری برای PostgreSQL است که با مجوزهای AGPLv3 یا ELv2 عرضه می‌شود. مهم‌ترین ویژگی آن سازگاری با انواع داده و نحو پرس‌وجوی pgvector است، بنابراین می‌تواند در بسیاری از سامانه‌های موجود به‌صورت جایگزین کم‌دردسر (drop-in) به کار رود. سازندگان وعده افزایش قابل‌توجه کارایی نسبت به pgvector داده‌اند؛ بدین معنا که اجرای پرس‌وجوهای شباهت برداری با تأخیر کمتر و توان عملیاتی بالاتر ممکن می‌شود، هرچند میزان بهبود به سناریو و بار کاری وابسته است. تکیه بر PostgreSQL مزیت استقرار ساده در زیرساخت فعلی و حذف نیاز به سرویس جداگانه را حفظ می‌کند. دوگانه‌مجوز بودن نیز انعطاف برای استفاده متن‌باز و مسیرهای استفاده تجاری را فراهم می‌سازد. این دست ابزار معمولاً برای جست‌وجوی معنایی، RAG، سامانه‌های توصیه‌گر و پردازش چندرسانه‌ای کاربرد دارد. کد منبع و اطلاعات بیشتر از طریق مخزن GitHub در دسترس است.
🟣لینک مقاله:
https://postgresweekly.com/link/173145/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
VectorChord 0.5: Scalable, Fast, and Disk-Friendly Vector Search
🟢 خلاصه مقاله:
این پروژه یک افزونه متن‌باز جست‌وجوی برداری برای PostgreSQL است که با مجوزهای AGPLv3 یا ELv2 عرضه می‌شود. مهم‌ترین ویژگی آن سازگاری با انواع داده و نحو پرس‌وجوی pgvector است، بنابراین می‌تواند در بسیاری از سامانه‌های موجود به‌صورت جایگزین کم‌دردسر (drop-in) به کار رود. سازندگان وعده افزایش قابل‌توجه کارایی نسبت به pgvector داده‌اند؛ بدین معنا که اجرای پرس‌وجوهای شباهت برداری با تأخیر کمتر و توان عملیاتی بالاتر ممکن می‌شود، هرچند میزان بهبود به سناریو و بار کاری وابسته است. تکیه بر PostgreSQL مزیت استقرار ساده در زیرساخت فعلی و حذف نیاز به سرویس جداگانه را حفظ می‌کند. دوگانه‌مجوز بودن نیز انعطاف برای استفاده متن‌باز و مسیرهای استفاده تجاری را فراهم می‌سازد. این دست ابزار معمولاً برای جست‌وجوی معنایی، RAG، سامانه‌های توصیه‌گر و پردازش چندرسانه‌ای کاربرد دارد. کد منبع و اطلاعات بیشتر از طریق مخزن GitHub در دسترس است.
🟣لینک مقاله:
https://postgresweekly.com/link/173145/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
vectorchord.ai
Scalable, fast, and disk-friendly vector search in Postgres, vectorchord is the successor of pgvecto.rs.
Forwarded from Notification
🔵 عنوان مقاله
Indexing JSONB in Postgres
🟢 خلاصه مقاله:
اJSONB در PostgreSQL برای دادههای نیمه‌ساخت‌یافته بسیار کاربردی است، اما سرعت بازیابی به انتخاب شاخص درست بستگی دارد. برای پرس‌وجوهای مبتنی بر وجود کلید معمولاً GIN بهترین گزینه است؛
ا jsonb_ops دامنهٔ وسیع‌تری از عملگرها را پشتیبانی می‌کند، در حالی‌که jsonb_path_ops برای شمول بهینه‌تر و کوچکتر است.
اگر مرتب روی یک مقدار اسکالر داخل JSONB فیلتر یا مرتب‌سازی می‌کنید (مثل data->>'sku')، شاخص B-tree روی یک عبارت یا ستون تولیدشده معمولاً سبک‌تر و سریع‌تر است. برای دادههای سنگینِ نوشتاری، هزینهٔ نگهداری GIN را در نظر بگیرید و در صورت امکان از شاخص‌های جزئی و بیان‌محور استفاده کنید. در کل، شاخص را مطابق الگوی واقعی پرس‌وجو بسازید و نتیجه را با بنچمارک روی بار کاری خودتان تأیید کنید.
🟣لینک مقاله:
https://postgresweekly.com/link/173137/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Indexing JSONB in Postgres
🟢 خلاصه مقاله:
اJSONB در PostgreSQL برای دادههای نیمه‌ساخت‌یافته بسیار کاربردی است، اما سرعت بازیابی به انتخاب شاخص درست بستگی دارد. برای پرس‌وجوهای مبتنی بر وجود کلید معمولاً GIN بهترین گزینه است؛
ا jsonb_ops دامنهٔ وسیع‌تری از عملگرها را پشتیبانی می‌کند، در حالی‌که jsonb_path_ops برای شمول بهینه‌تر و کوچکتر است.
اگر مرتب روی یک مقدار اسکالر داخل JSONB فیلتر یا مرتب‌سازی می‌کنید (مثل data->>'sku')، شاخص B-tree روی یک عبارت یا ستون تولیدشده معمولاً سبک‌تر و سریع‌تر است. برای دادههای سنگینِ نوشتاری، هزینهٔ نگهداری GIN را در نظر بگیرید و در صورت امکان از شاخص‌های جزئی و بیان‌محور استفاده کنید. در کل، شاخص را مطابق الگوی واقعی پرس‌وجو بسازید و نتیجه را با بنچمارک روی بار کاری خودتان تأیید کنید.
🟣لینک مقاله:
https://postgresweekly.com/link/173137/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Crunchy Data
Indexing JSONB in Postgres | Crunchy Data Blog
Level up with JSONB by adding GIN indexes. Also review when not to use a GIN index and how to leverage expression indexes.
🔵 عنوان مقاله
Indexing JSONB in Postgres
🟢 خلاصه مقاله:
این مقاله توضیح می‌دهد چگونه با بهرهگیری درست از قابلیت‌های ایندکس در پستگرس، بازیابی داده از JSONB را سریع و بهینه کنیم. هسته پیام این است که انتخاب نوع ایندکس باید بر اساس الگوی پرس‌وجو باشد: برای جست‌وجوهای شامل‌بودن و وجود کلید، GIN گزینه اصلی است (نسخه پیش‌فرض برای عملگرهای متنوع و jsonb_path_ops برای ایندکس کوچکتر و سریع‌ترِ خاص پرس‌وجوهای @>). برای فیلتر و سورت بر روی مقادیر اسکالر داخل JSONB، ایندکس‌های بی‌تری روی عبارت‌های استخراج‌شده (مثل user_id یا زمان) کاراترند؛ همچنین می‌توان از ایندکس‌های جزئی و پوششی برای کاهش هزینه خواندن استفاده کرد. باید میان سرعت خواندن، اندازه ایندکس و سربار نوشتن توازن برقرار کرد، با EXPLAIN صحت استفاده از ایندکس را سنجید و از ایندکس‌گذاری بیش‌ازحد پرهیز نمود؛ در موارد پرتکرار، تبدیل چند کلید مهم به ستونهای تولیدی و ایندکس‌کردن آنها تعادلی عملی میان انعطاف و کارایی ایجاد می‌کند.
🟣لینک مقاله:
https://postgresweekly.com/link/173137/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Indexing JSONB in Postgres
🟢 خلاصه مقاله:
این مقاله توضیح می‌دهد چگونه با بهرهگیری درست از قابلیت‌های ایندکس در پستگرس، بازیابی داده از JSONB را سریع و بهینه کنیم. هسته پیام این است که انتخاب نوع ایندکس باید بر اساس الگوی پرس‌وجو باشد: برای جست‌وجوهای شامل‌بودن و وجود کلید، GIN گزینه اصلی است (نسخه پیش‌فرض برای عملگرهای متنوع و jsonb_path_ops برای ایندکس کوچکتر و سریع‌ترِ خاص پرس‌وجوهای @>). برای فیلتر و سورت بر روی مقادیر اسکالر داخل JSONB، ایندکس‌های بی‌تری روی عبارت‌های استخراج‌شده (مثل user_id یا زمان) کاراترند؛ همچنین می‌توان از ایندکس‌های جزئی و پوششی برای کاهش هزینه خواندن استفاده کرد. باید میان سرعت خواندن، اندازه ایندکس و سربار نوشتن توازن برقرار کرد، با EXPLAIN صحت استفاده از ایندکس را سنجید و از ایندکس‌گذاری بیش‌ازحد پرهیز نمود؛ در موارد پرتکرار، تبدیل چند کلید مهم به ستونهای تولیدی و ایندکس‌کردن آنها تعادلی عملی میان انعطاف و کارایی ایجاد می‌کند.
🟣لینک مقاله:
https://postgresweekly.com/link/173137/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Crunchy Data
Indexing JSONB in Postgres | Crunchy Data Blog
Level up with JSONB by adding GIN indexes. Also review when not to use a GIN index and how to leverage expression indexes.
❤1
🔵 عنوان مقاله
Bypass Postgres Catalog Overhead with Direct Partition Hash Calculations
🟢 خلاصه مقاله:
کار اصلی مقاله نشان می‌دهد که در جداول پارتیشن‌بندی‌شده‌ی PostgreSQL، هزینه‌ی مراجعه مکرر به کاتالوگ برای مسیردهی رکوردها می‌تواند با افزایش تعداد پارتیشن‌ها یا همزمانی بالا به گلوگاه تبدیل شود. راه‌حل پیشنهادی، محاسبه مستقیم هش پارتیشن بر اساس کلید پارتیشن و ارسال تعیین‌شده رکورد به پارتیشن درست است؛ رویکردی که با دور زدن مسیر وابسته به کاتالوگ، سربار برنامه‌ریز/اجرا را کم کرده و تأخیرهای دُم را پایدارتر می‌کند. نکته‌ی کلیدی هماهنگی دقیق الگوریتم هش، کالیشن و نگاشت پارتیشن بین برنامه و پایگاه داده و مدیریت ایمن تغییرات هنگام افزودن/بازچینی پارتیشن‌هاست. بخش دوم توضیح می‌دهد چرا PostgreSQL بستر مناسبی برای اجرای گردش‌کارِ پایدار است: تراکنش‌ها و WAL برای دوام، قیود و کلیدهای تکرارنشدنی برای درستی، و امکاناتی مانند SKIP LOCKED و لاک‌های مشورتی برای زمانبندی و صف. ترکیب این دو ایده—ذخیره وضعیت و صف کار در جداول هش‌پارتیشن و مسیردهی مستقیم با محاسبه هش—سامانه‌ای می‌سازد که هم مقیاسپذیر است و هم قابل اتکا، بدون قربانی‌کردن سازگاری در بارهای نوشتاری سنگین و همزمان.
🟣لینک مقاله:
https://postgresweekly.com/link/173139/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Bypass Postgres Catalog Overhead with Direct Partition Hash Calculations
🟢 خلاصه مقاله:
کار اصلی مقاله نشان می‌دهد که در جداول پارتیشن‌بندی‌شده‌ی PostgreSQL، هزینه‌ی مراجعه مکرر به کاتالوگ برای مسیردهی رکوردها می‌تواند با افزایش تعداد پارتیشن‌ها یا همزمانی بالا به گلوگاه تبدیل شود. راه‌حل پیشنهادی، محاسبه مستقیم هش پارتیشن بر اساس کلید پارتیشن و ارسال تعیین‌شده رکورد به پارتیشن درست است؛ رویکردی که با دور زدن مسیر وابسته به کاتالوگ، سربار برنامه‌ریز/اجرا را کم کرده و تأخیرهای دُم را پایدارتر می‌کند. نکته‌ی کلیدی هماهنگی دقیق الگوریتم هش، کالیشن و نگاشت پارتیشن بین برنامه و پایگاه داده و مدیریت ایمن تغییرات هنگام افزودن/بازچینی پارتیشن‌هاست. بخش دوم توضیح می‌دهد چرا PostgreSQL بستر مناسبی برای اجرای گردش‌کارِ پایدار است: تراکنش‌ها و WAL برای دوام، قیود و کلیدهای تکرارنشدنی برای درستی، و امکاناتی مانند SKIP LOCKED و لاک‌های مشورتی برای زمانبندی و صف. ترکیب این دو ایده—ذخیره وضعیت و صف کار در جداول هش‌پارتیشن و مسیردهی مستقیم با محاسبه هش—سامانه‌ای می‌سازد که هم مقیاسپذیر است و هم قابل اتکا، بدون قربانی‌کردن سازگاری در بارهای نوشتاری سنگین و همزمان.
🟣لینک مقاله:
https://postgresweekly.com/link/173139/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Shayon Mukherjee
Bypass PostgreSQL catalog overhead with direct partition hash calculations
Eliminating PostgreSQL catalog traversal overhead with local partition calculations for up to 20x faster hash partition queries.
🔵 عنوان مقاله
Postgres 17.6, 16.10, 15.14, 14.19, 13.22, and 18 Beta 3 Released
🟢 خلاصه مقاله:
تمام نسخه‌های پشتیبانی‌شده‌ی پستگرس به‌روزرسانی شدند: 13.22، 14.19، 15.14، 16.10 و 17.6، به‌همراه انتشار بتای سوم نسخه 18. این نسخه‌ها برای رفع چند آسیب‌پذیری امنیتی و اعمال اصلاحات متعدد عرضه شده‌اند. انتشار نهایی پستگرس 18 حدود یک ماه دیگر انتظار می‌رود و توصیه می‌شود مدیران سامانه‌ها با بررسی یادداشت‌های انتشار، برنامهٔ به‌روزرسانی را در اولویت قرار دهند.
🟣لینک مقاله:
https://postgresweekly.com/link/173129/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Postgres 17.6, 16.10, 15.14, 14.19, 13.22, and 18 Beta 3 Released
🟢 خلاصه مقاله:
تمام نسخه‌های پشتیبانی‌شده‌ی پستگرس به‌روزرسانی شدند: 13.22، 14.19، 15.14، 16.10 و 17.6، به‌همراه انتشار بتای سوم نسخه 18. این نسخه‌ها برای رفع چند آسیب‌پذیری امنیتی و اعمال اصلاحات متعدد عرضه شده‌اند. انتشار نهایی پستگرس 18 حدود یک ماه دیگر انتظار می‌رود و توصیه می‌شود مدیران سامانه‌ها با بررسی یادداشت‌های انتشار، برنامهٔ به‌روزرسانی را در اولویت قرار دهند.
🟣لینک مقاله:
https://postgresweekly.com/link/173129/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
PostgreSQL News
PostgreSQL 17.6, 16.10, 15.14, 14.19, 13.22, and 18 Beta 3 Released!
The PostgreSQL Global Development Group has released an update to all supported versions of PostgreSQL, including 17.6, 16.10, 15.14, 14.19, …
❤2
🔵 عنوان مقاله
adopted a new usage-based pricing model
🟢 خلاصه مقاله:
این مقاله از تغییر به مدل قیمت‌گذاری مصرف‌محور خبر می‌دهد: پرداخت به‌ازای مصرف با حداقل ماهانه ۵ دلار. هدف، هم‌راستاسازی هزینه با میزان استفاده و افزایش انعطاف است؛ کاربران کم‌مصرف معمولاً حداقل را می‌پردازند و پرمصرف‌ها متناسب با مصرف هزینه می‌دهند. این رویکرد پیش‌بینی‌پذیری صورت‌حساب را کاهش می‌دهد، بنابراین بهتر است کاربران الگوی مصرف خود را برآورد و آن را مدیریت کنند.
🟣لینک مقاله:
https://postgresweekly.com/link/173153/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
adopted a new usage-based pricing model
🟢 خلاصه مقاله:
این مقاله از تغییر به مدل قیمت‌گذاری مصرف‌محور خبر می‌دهد: پرداخت به‌ازای مصرف با حداقل ماهانه ۵ دلار. هدف، هم‌راستاسازی هزینه با میزان استفاده و افزایش انعطاف است؛ کاربران کم‌مصرف معمولاً حداقل را می‌پردازند و پرمصرف‌ها متناسب با مصرف هزینه می‌دهند. این رویکرد پیش‌بینی‌پذیری صورت‌حساب را کاهش می‌دهد، بنابراین بهتر است کاربران الگوی مصرف خود را برآورد و آن را مدیریت کنند.
🟣لینک مقاله:
https://postgresweekly.com/link/173153/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Neon
Neon’s New Pricing, Explained: Usage-Based With a $5 Minimum - Neon
We just rolled out a major pricing update, including two of our most requested changes: more storage for Free users, and a $5 /month plan.
❤1
🔵 عنوان مقاله
a guide on how to migrate existing Postgres databases
🟢 خلاصه مقاله:
یک راهنمای عملی برای مهاجرت پایگاه‌های داده موجود PostgreSQL معرفی می‌شود که در Golang Weekly برجسته شده و روی نیازهای توسعه‌دهندگان Go تمرکز دارد. رویکرد کلی، فرایندی و مرحله‌به‌مرحله است: ارزیابی دقیق وضعیت فعلی، انتخاب راهبرد متناسب با محدودیت‌های زمان‌اختلال، خودکارسازی گام‌ها، و اعتبارسنجی مستمر.
این راهنما بر برنامهریزی دقیق (شناخت طرح‌واره‌ها، حجم داده، ایندکس‌ها، افزونه‌ها و تفاوت نسخه‌ها) و تمرین مهاجرت در محیط staging تأکید دارد. راهبردهای رایج مانند ارتقای درجا، قطع‌وبرقراری آبی/سبز و روش‌های مبتنی بر تکرار/همگامسازی مقایسه می‌شوند. الگوهای ایمن تغییر طرح‌واره (expand/contract)، ساخت ایندکس‌های همزمان، پرکردن تدریجی دادههای حجیم، پشتیبان‌گیری و برنامه بازگشت از نکات کلیدی هستند.
برای تیم‌های Go، نسخه‌بندی SQL، اجرای مهاجرت در CI/CD، اسکریپت‌های تکرارپذیر، پایش لحظهای و هماهنگی انتشار کد با تغییرات دیتابیس (مثلاً با feature flag) توصیه می‌شود. همچنین به یکپارچگی داده، قفل‌ها و تراکنش‌های طولانی، و اعتبارسنجی پس از مهاجرت پرداخته می‌شود. در نهایت، ملاحظات فضای ابری و یک چک‌لیست پیش از اجرا ارائه می‌گردد تا مهاجرت PostgreSQL با ریسک کمتر و وقفه حداقلی انجام شود.
🟣لینک مقاله:
https://postgresweekly.com/link/173132/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
a guide on how to migrate existing Postgres databases
🟢 خلاصه مقاله:
یک راهنمای عملی برای مهاجرت پایگاه‌های داده موجود PostgreSQL معرفی می‌شود که در Golang Weekly برجسته شده و روی نیازهای توسعه‌دهندگان Go تمرکز دارد. رویکرد کلی، فرایندی و مرحله‌به‌مرحله است: ارزیابی دقیق وضعیت فعلی، انتخاب راهبرد متناسب با محدودیت‌های زمان‌اختلال، خودکارسازی گام‌ها، و اعتبارسنجی مستمر.
این راهنما بر برنامهریزی دقیق (شناخت طرح‌واره‌ها، حجم داده، ایندکس‌ها، افزونه‌ها و تفاوت نسخه‌ها) و تمرین مهاجرت در محیط staging تأکید دارد. راهبردهای رایج مانند ارتقای درجا، قطع‌وبرقراری آبی/سبز و روش‌های مبتنی بر تکرار/همگامسازی مقایسه می‌شوند. الگوهای ایمن تغییر طرح‌واره (expand/contract)، ساخت ایندکس‌های همزمان، پرکردن تدریجی دادههای حجیم، پشتیبان‌گیری و برنامه بازگشت از نکات کلیدی هستند.
برای تیم‌های Go، نسخه‌بندی SQL، اجرای مهاجرت در CI/CD، اسکریپت‌های تکرارپذیر، پایش لحظهای و هماهنگی انتشار کد با تغییرات دیتابیس (مثلاً با feature flag) توصیه می‌شود. همچنین به یکپارچگی داده، قفل‌ها و تراکنش‌های طولانی، و اعتبارسنجی پس از مهاجرت پرداخته می‌شود. در نهایت، ملاحظات فضای ابری و یک چک‌لیست پیش از اجرا ارائه می‌گردد تا مهاجرت PostgreSQL با ریسک کمتر و وقفه حداقلی انجام شود.
🟣لینک مقاله:
https://postgresweekly.com/link/173132/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Planetscale
Postgres Imports — PlanetScale
Learn how to use PlanetScale to power your application.
❤2
🔵 عنوان مقاله
VectorChord 0.5: Scalable, Fast, and Disk-Friendly Vector Search
🟢 خلاصه مقاله:
VectorChord 0.5 یک افزونه متن‌باز جست‌وجوی برداری برای PostgreSQL است که با مجوز دوگانه AGPLv3/ELv2 عرضه می‌شود و بر سرعت، مقیاس‌پذیری و کارایی دیسک تأکید دارد. این ابزار با انواع داده و دستورهای pgvector سازگار است، بنابراین بسیاری از برنامه‌های فعلی می‌توانند با تغییرات حداقلی آن را بیازمایند یا مهاجرت دهند. هدف آن ارائه بهبود چشمگیر کارایی و پشتیبانی از مجموعه‌داده‌های بزرگ‌تر (حتی فراتر از حافظه) است و برای کاربردهایی مانند جست‌وجوی معنایی، RAG و سیستمهای توصیه مناسب توصیف می‌شود. مخزن GitHub پروژه شامل کد، مستندات و راهنمای ارزیابی عملکرد است و گزینه‌ای عملی برای تیم‌هایی است که می‌خواهند در اکوسیستم Postgres بمانند اما جست‌وجوی برداری سریع‌تر و مقیاس‌پذیرتری داشته باشند.
🟣لینک مقاله:
https://postgresweekly.com/link/173145/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
VectorChord 0.5: Scalable, Fast, and Disk-Friendly Vector Search
🟢 خلاصه مقاله:
VectorChord 0.5 یک افزونه متن‌باز جست‌وجوی برداری برای PostgreSQL است که با مجوز دوگانه AGPLv3/ELv2 عرضه می‌شود و بر سرعت، مقیاس‌پذیری و کارایی دیسک تأکید دارد. این ابزار با انواع داده و دستورهای pgvector سازگار است، بنابراین بسیاری از برنامه‌های فعلی می‌توانند با تغییرات حداقلی آن را بیازمایند یا مهاجرت دهند. هدف آن ارائه بهبود چشمگیر کارایی و پشتیبانی از مجموعه‌داده‌های بزرگ‌تر (حتی فراتر از حافظه) است و برای کاربردهایی مانند جست‌وجوی معنایی، RAG و سیستمهای توصیه مناسب توصیف می‌شود. مخزن GitHub پروژه شامل کد، مستندات و راهنمای ارزیابی عملکرد است و گزینه‌ای عملی برای تیم‌هایی است که می‌خواهند در اکوسیستم Postgres بمانند اما جست‌وجوی برداری سریع‌تر و مقیاس‌پذیرتری داشته باشند.
🟣لینک مقاله:
https://postgresweekly.com/link/173145/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
vectorchord.ai
Scalable, fast, and disk-friendly vector search in Postgres, vectorchord is the successor of pgvecto.rs.
👍2
🔵 عنوان مقاله
'self-driving' Postgres
🟢 خلاصه مقاله:
منظور از «Postgres خودران» سامانه‌ای است که با تکیه بر تله‌متری داخلی و معیارهای میزبان، تنظیمات و نگهداشت‌های روزمره را به‌صورت خودکار انجام می‌دهد تا کارایی پایدار با حداقل دخالت انسانی حفظ شود. این سامانه با چرخه مشاهده–تصمیم–اقدام، پارامترهای حافظه و موازی‌سازی، تنظیمات autovacuum/ANALYZE، مدیریت شاخص‌ها و زمانبندی وظایف نگهداشت (مانند VACUUM و REINDEX) را به‌صورت ایمن و مرحله‌ای بهینه می‌کند و در صورت افت نسبت به اهداف سطح خدمت (SLO) به‌سرعت بازمی‌گردد. با خط‌کش‌های ایمنی، آزمایش کاناری/نسخه پشتیبان، ثبت شفاف تصمیم‌ها و امکان تأیید انسانی برای ریسک‌های بالا، هدف آن کاهش کار تکراری و خطای انسانی و تقویت نقش DBA است، نه جایگزینی کامل آن.
🟣لینک مقاله:
https://postgresweekly.com/link/173135/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
'self-driving' Postgres
🟢 خلاصه مقاله:
منظور از «Postgres خودران» سامانه‌ای است که با تکیه بر تله‌متری داخلی و معیارهای میزبان، تنظیمات و نگهداشت‌های روزمره را به‌صورت خودکار انجام می‌دهد تا کارایی پایدار با حداقل دخالت انسانی حفظ شود. این سامانه با چرخه مشاهده–تصمیم–اقدام، پارامترهای حافظه و موازی‌سازی، تنظیمات autovacuum/ANALYZE، مدیریت شاخص‌ها و زمانبندی وظایف نگهداشت (مانند VACUUM و REINDEX) را به‌صورت ایمن و مرحله‌ای بهینه می‌کند و در صورت افت نسبت به اهداف سطح خدمت (SLO) به‌سرعت بازمی‌گردد. با خط‌کش‌های ایمنی، آزمایش کاناری/نسخه پشتیبان، ثبت شفاف تصمیم‌ها و امکان تأیید انسانی برای ریسک‌های بالا، هدف آن کاهش کار تکراری و خطای انسانی و تقویت نقش DBA است، نه جایگزینی کامل آن.
🟣لینک مقاله:
https://postgresweekly.com/link/173135/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Postgres FM
Postgres FM | Self-driving Postgres
Nikolay and Michael discuss self-driving Postgres — what it could mean, using self-driving cars as a reference, and ideas for things to build and optimize for in this area. Here are some links to t...
❤1