📌 Database Administration (DBA) Engineering Manager
📝 Type: Visa Sponsorship
🌍 Relocation Package: ✅
🏢 Company: TradingView
📍 Location: UNITED KINGDOM
⌨️ Category: #Programming
🔗 Tags: #javascript #python #reactjs #typescript #golang #mysql #postgresql #redis #kubernetes #aws #cloud
📝 Type: Visa Sponsorship
🌍 Relocation Package: ✅
🏢 Company: TradingView
📍 Location: UNITED KINGDOM
⌨️ Category: #Programming
🔗 Tags: #javascript #python #reactjs #typescript #golang #mysql #postgresql #redis #kubernetes #aws #cloud
🔵 عنوان مقاله
'the PostgreSQL creators totally nailed it.'
🟢 خلاصه مقاله:
در آخرین شماره Golang Weekly، مقاله‌ای تأکید می‌کند که سازندگان PostgreSQL «کاملاً درست عمل کردند». نویسنده توضیح می‌دهد چرا این پایگاه‌داده با ترکیب استانداردهای شفاف SQL، قابلیت اتکا، کارایی بالا و امکاناتی مانند JSONB و ایندکس‌های قدرتمند، برای طیف وسیعی از نیازها مناسب است. برای توسعه‌دهندگان Go، هم‌نشینی PostgreSQL با ابزارهایی مثل pgx و GORM، سادگی در ادغام، و رفتار قابل پیش‌بینی در محیط تولید، ارزش ویژه‌ای دارد. جامعه فعال، مستندسازی خوب و سازگاری عقب‌رو نیز استفاده بلندمدت را مطمئن می‌کند. جمع‌بندی مقاله این است که برای بسیاری از تیم‌های Go، PostgreSQL یک انتخاب پیش‌فرض قوی و عملیاتی است و سازندگانش در رسیدن به این تعادل «حرفه‌ای» عمل کرده‌اند.
#PostgreSQL #Golang #Go #Databases #GolangWeekly #OpenSource #Backend #SoftwareEngineering
🟣لینک مقاله:
https://postgresweekly.com/link/174751/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
'the PostgreSQL creators totally nailed it.'
🟢 خلاصه مقاله:
در آخرین شماره Golang Weekly، مقاله‌ای تأکید می‌کند که سازندگان PostgreSQL «کاملاً درست عمل کردند». نویسنده توضیح می‌دهد چرا این پایگاه‌داده با ترکیب استانداردهای شفاف SQL، قابلیت اتکا، کارایی بالا و امکاناتی مانند JSONB و ایندکس‌های قدرتمند، برای طیف وسیعی از نیازها مناسب است. برای توسعه‌دهندگان Go، هم‌نشینی PostgreSQL با ابزارهایی مثل pgx و GORM، سادگی در ادغام، و رفتار قابل پیش‌بینی در محیط تولید، ارزش ویژه‌ای دارد. جامعه فعال، مستندسازی خوب و سازگاری عقب‌رو نیز استفاده بلندمدت را مطمئن می‌کند. جمع‌بندی مقاله این است که برای بسیاری از تیم‌های Go، PostgreSQL یک انتخاب پیش‌فرض قوی و عملیاتی است و سازندگانش در رسیدن به این تعادل «حرفه‌ای» عمل کرده‌اند.
#PostgreSQL #Golang #Go #Databases #GolangWeekly #OpenSource #Backend #SoftwareEngineering
🟣لینک مقاله:
https://postgresweekly.com/link/174751/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Crunchy Data
Postgres’ Original Project Goals: The Creators Totally Nailed It | Crunchy Data Blog
Dig in to the original goals of the Postgres academic project at UC Berkeley and how they shaped the Postgres we use today.
❤3
🔵 عنوان مقاله
Understanding WAL and Optimizing It with a Dedicated Disk
🟢 خلاصه مقاله:
WAL روشی کلیدی برای پایداری و ریکاوری پس از کرش است: تغییرات ابتدا به شکل ترتیبی در یک لاگ نوشته و به‌صورت پایدار flush می‌شوند و سپس در صورت نیاز روی داده‌های اصلی اعمال یا بازپخش می‌گردند. گلوگاه اصلی معمولاً همان fsync/flush است که باید دوام را تضمین کند. وقتی WAL روی همان دیسکی باشد که فایل‌های داده نیز روی آن I/O تصادفی انجام می‌دهند، وقفه و رقابت صف موجب جهش در تاخیر به‌ویژه در p99/p999 می‌شود. قرار دادن WAL روی یک دیسک اختصاصی این مسیر حساس را ایزوله می‌کند، الگوی نوشتن ترتیبی را حفظ می‌کند و تاخیر را قابل پیش‌بینی‌تر و بهره‌وری را بیشتر می‌سازد.
در عمل می‌توان از یک NVMe مستقل یا یک ولوم ابری جداگانه استفاده کرد؛ فایل‌سیستم‌های رایج مانند ext4 یا XFS با تنظیمات ساده و بدون سربار اضافی مناسب‌اند و باید اطمینان داشت که semantics مربوط به write barrier و cache flush مطابق نیازهای دوام هستند. از منظر Golang، بهینه‌سازی WAL معمولاً با سگمنت‌بندی و پیش‌اختصاص فایل‌ها، نوشتن هم‌تراز با بلوک، checksum، batch کردن درخواست‌ها، group commit با آستانه زمانی/حجمی، استفاده سنجیده از O_DSYNC/fdatasync و مدیریت دقیق بافر انجام می‌شود. اندازه‌گیری دقیق قبل و بعد (میانگین و p99 fsync، نرخ نوشتن، و زمان انتهابه‌انتها) مشخص می‌کند آیا دیسک اختصاصی هزینه‌اش را جبران می‌کند یا خیر؛ برای بارهای نوشتاری بالا یا SLA سخت‌گیرانه، این ایزولاسیون معمولاً ارزشمند است.
#WAL #Golang #Databases #Performance #Storage #NVMe #SystemsDesign
🟣لینک مقاله:
https://postgresweekly.com/link/174762/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Understanding WAL and Optimizing It with a Dedicated Disk
🟢 خلاصه مقاله:
WAL روشی کلیدی برای پایداری و ریکاوری پس از کرش است: تغییرات ابتدا به شکل ترتیبی در یک لاگ نوشته و به‌صورت پایدار flush می‌شوند و سپس در صورت نیاز روی داده‌های اصلی اعمال یا بازپخش می‌گردند. گلوگاه اصلی معمولاً همان fsync/flush است که باید دوام را تضمین کند. وقتی WAL روی همان دیسکی باشد که فایل‌های داده نیز روی آن I/O تصادفی انجام می‌دهند، وقفه و رقابت صف موجب جهش در تاخیر به‌ویژه در p99/p999 می‌شود. قرار دادن WAL روی یک دیسک اختصاصی این مسیر حساس را ایزوله می‌کند، الگوی نوشتن ترتیبی را حفظ می‌کند و تاخیر را قابل پیش‌بینی‌تر و بهره‌وری را بیشتر می‌سازد.
در عمل می‌توان از یک NVMe مستقل یا یک ولوم ابری جداگانه استفاده کرد؛ فایل‌سیستم‌های رایج مانند ext4 یا XFS با تنظیمات ساده و بدون سربار اضافی مناسب‌اند و باید اطمینان داشت که semantics مربوط به write barrier و cache flush مطابق نیازهای دوام هستند. از منظر Golang، بهینه‌سازی WAL معمولاً با سگمنت‌بندی و پیش‌اختصاص فایل‌ها، نوشتن هم‌تراز با بلوک، checksum، batch کردن درخواست‌ها، group commit با آستانه زمانی/حجمی، استفاده سنجیده از O_DSYNC/fdatasync و مدیریت دقیق بافر انجام می‌شود. اندازه‌گیری دقیق قبل و بعد (میانگین و p99 fsync، نرخ نوشتن، و زمان انتهابه‌انتها) مشخص می‌کند آیا دیسک اختصاصی هزینه‌اش را جبران می‌کند یا خیر؛ برای بارهای نوشتاری بالا یا SLA سخت‌گیرانه، این ایزولاسیون معمولاً ارزشمند است.
#WAL #Golang #Databases #Performance #Storage #NVMe #SystemsDesign
🟣لینک مقاله:
https://postgresweekly.com/link/174762/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Stormatics
PostgreSQL WAL: Boost Performance with a Dedicated Disk
Learn how to speed up PostgreSQL by moving WAL to its own disk. Cut I/O contention and improve write performance safely.
❤1
🔵 عنوان مقاله
Cumulative Statistics in Postgres 18
🟢 خلاصه مقاله:
این مطلب از Golang Weekly توضیح می‌دهد که cumulative statistics در Postgres 18 چگونه با تجمیع شمارنده‌ها و زمان‌ها در طول زمان، تصویری روندی از رفتار بار کاری ارائه می‌کند؛ تصویری که برای عیب‌یابی کارایی، برنامه‌ریزی ظرفیت و تعریف SLO بسیار مفیدتر از نماهای لحظه‌ای است. نویسنده انواع داده‌های قابل‌دسترسی از طریق نماها و اکستنشن‌ها (مثل آمار سطح کوئری، الگوهای دسترسی به جدول و ایندکس، I/O و فعالیت پس‌زمینه) را مرور می‌کند و تأکید دارد که در Postgres 18 ارائه و استفاده از این آمارها روان‌تر و قابل‌مقایسه‌تر شده است.
برای تیم‌های Go نیز رویکردی عملی پیشنهاد می‌شود: استخراج دوره‌ای آمار از طریق database/sql یا pgx، اسکن در ساختارها و ارسال به Prometheus تا داشبوردها و هشدارها بتوانند معیارهایی مانند تاخیر، نسبت cache hit و گروه‌های کوئری پرهزینه را در طول زمان دنبال کنند. نکات عملی شامل زمان‌بندی مناسب برای reset شمارنده‌ها (مثلاً همزمان با استقرار)، فیلتر کردن آمار بر اساس database یا application_name و اطمینان از سبک‌وزن بودن کوئری‌های مانیتورینگ است. ترکیب این قابلیت‌ها با جمع‌آوری سبک در Go راهی پایدار برای یافتن گلوگاه‌ها و حفظ کارایی در تکامل سیستم فراهم می‌کند.
#Postgres #PostgreSQL #CumulativeStatistics #DatabasePerformance #Observability #Go #Golang #Monitoring
🟣لینک مقاله:
https://postgresweekly.com/link/175101/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Cumulative Statistics in Postgres 18
🟢 خلاصه مقاله:
این مطلب از Golang Weekly توضیح می‌دهد که cumulative statistics در Postgres 18 چگونه با تجمیع شمارنده‌ها و زمان‌ها در طول زمان، تصویری روندی از رفتار بار کاری ارائه می‌کند؛ تصویری که برای عیب‌یابی کارایی، برنامه‌ریزی ظرفیت و تعریف SLO بسیار مفیدتر از نماهای لحظه‌ای است. نویسنده انواع داده‌های قابل‌دسترسی از طریق نماها و اکستنشن‌ها (مثل آمار سطح کوئری، الگوهای دسترسی به جدول و ایندکس، I/O و فعالیت پس‌زمینه) را مرور می‌کند و تأکید دارد که در Postgres 18 ارائه و استفاده از این آمارها روان‌تر و قابل‌مقایسه‌تر شده است.
برای تیم‌های Go نیز رویکردی عملی پیشنهاد می‌شود: استخراج دوره‌ای آمار از طریق database/sql یا pgx، اسکن در ساختارها و ارسال به Prometheus تا داشبوردها و هشدارها بتوانند معیارهایی مانند تاخیر، نسبت cache hit و گروه‌های کوئری پرهزینه را در طول زمان دنبال کنند. نکات عملی شامل زمان‌بندی مناسب برای reset شمارنده‌ها (مثلاً همزمان با استقرار)، فیلتر کردن آمار بر اساس database یا application_name و اطمینان از سبک‌وزن بودن کوئری‌های مانیتورینگ است. ترکیب این قابلیت‌ها با جمع‌آوری سبک در Go راهی پایدار برای یافتن گلوگاه‌ها و حفظ کارایی در تکامل سیستم فراهم می‌کند.
#Postgres #PostgreSQL #CumulativeStatistics #DatabasePerformance #Observability #Go #Golang #Monitoring
🟣لینک مقاله:
https://postgresweekly.com/link/175101/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Data Bene
Cumulative Statistics in PostgreSQL 18
In PostgreSQL 18, the statistics & monitoring subsystem receives a significant overhaul - extended cumulative statistics, new per-backend I/O visibility, the ability for extensions to export / import / adjust statistics, and much more. Let's explore these…
🔵 عنوان مقاله
PG Back Web 0.5: A Postgres Backup System with Web Interface
🟢 خلاصه مقاله:
PG Back Web 0.5 یک اپ مبتنی بر Go است که با یک رابط وب کاربرپسند، مدیریت پشتیبان‌گیری‌های Postgres را ساده می‌کند. این ابزار امکان زمان‌بندی بکاپ‌ها (از جمله ذخیره به S3)، پایش وضعیت بکاپ‌ها و اتصال رویدادها از طریق Webhookها را فراهم می‌کند. به‌صورت Docker image ارائه شده و اکنون از Postgres 18 نیز پشتیبانی می‌کند و برای تیم‌هایی مناسب است که می‌خواهند فرایند بکاپ را استاندارد، قابل مشاهده و خودکار کنند.
#Postgres #DatabaseBackups #GoLang #S3 #Docker #DevOps #WebInterface #DataProtection
🟣لینک مقاله:
https://postgresweekly.com/link/175102/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
PG Back Web 0.5: A Postgres Backup System with Web Interface
🟢 خلاصه مقاله:
PG Back Web 0.5 یک اپ مبتنی بر Go است که با یک رابط وب کاربرپسند، مدیریت پشتیبان‌گیری‌های Postgres را ساده می‌کند. این ابزار امکان زمان‌بندی بکاپ‌ها (از جمله ذخیره به S3)، پایش وضعیت بکاپ‌ها و اتصال رویدادها از طریق Webhookها را فراهم می‌کند. به‌صورت Docker image ارائه شده و اکنون از Postgres 18 نیز پشتیبانی می‌کند و برای تیم‌هایی مناسب است که می‌خواهند فرایند بکاپ را استاندارد، قابل مشاهده و خودکار کنند.
#Postgres #DatabaseBackups #GoLang #S3 #Docker #DevOps #WebInterface #DataProtection
🟣لینک مقاله:
https://postgresweekly.com/link/175102/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
GitHub
GitHub - eduardolat/pgbackweb: 🐘 Effortless PostgreSQL backups with a user-friendly web interface! 🌐💾
🐘 Effortless PostgreSQL backups with a user-friendly web interface! 🌐💾 - eduardolat/pgbackweb
🔵 عنوان مقاله
A cute example of solving a logic puzzle
🟢 خلاصه مقاله:
این مطلب در Golang Weekly یک نمونه دوست‌داشتنی از حل یک پازل منطقی را نشان می‌دهد: تبدیل سرنخ‌های متنی به قیود دقیق، مدل‌سازی حالت‌ها، و حذف تدریجی گزینه‌های نامعتبر تا رسیدن به پاسخ یکتا. رویکرد آن بر سادگی و شفافیت تکیه دارد—با استفاده از ساختارهای داده ساده و اندکی backtracking یا constraint propagation که پیاده‌سازی‌اش در Go روان و قابل دنبال‌کردن است. فراتر از یک معما، پیام اصلی این است که پازل‌های منطقی محیطی عالی برای تمرین تفکر الگوریتمی در Go فراهم می‌کنند؛ از مدل‌سازی و آزمون‌پذیری تا ملاحظات کارایی. در پایان، خواننده تشویق می‌شود با نسخه‌های مختلف معما و شیوه‌های بیان قیود آزمایش کند و از فرایند تبدیل سرنخ‌های غیررسمی به منطق اجرایی لذت ببرد.
#Golang #Go #LogicPuzzle #AlgorithmicThinking #ConstraintSolving #Backtracking #GolangWeekly
🟣لینک مقاله:
https://postgresweekly.com/link/175724/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
A cute example of solving a logic puzzle
🟢 خلاصه مقاله:
این مطلب در Golang Weekly یک نمونه دوست‌داشتنی از حل یک پازل منطقی را نشان می‌دهد: تبدیل سرنخ‌های متنی به قیود دقیق، مدل‌سازی حالت‌ها، و حذف تدریجی گزینه‌های نامعتبر تا رسیدن به پاسخ یکتا. رویکرد آن بر سادگی و شفافیت تکیه دارد—با استفاده از ساختارهای داده ساده و اندکی backtracking یا constraint propagation که پیاده‌سازی‌اش در Go روان و قابل دنبال‌کردن است. فراتر از یک معما، پیام اصلی این است که پازل‌های منطقی محیطی عالی برای تمرین تفکر الگوریتمی در Go فراهم می‌کنند؛ از مدل‌سازی و آزمون‌پذیری تا ملاحظات کارایی. در پایان، خواننده تشویق می‌شود با نسخه‌های مختلف معما و شیوه‌های بیان قیود آزمایش کند و از فرایند تبدیل سرنخ‌های غیررسمی به منطق اجرایی لذت ببرد.
#Golang #Go #LogicPuzzle #AlgorithmicThinking #ConstraintSolving #Backtracking #GolangWeekly
🟣لینک مقاله:
https://postgresweekly.com/link/175724/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Reddit
cthart's comment on "Logic"
Explore this conversation and more from the puzzle community
🔵 عنوان مقاله
Key Operational Enhancements and Integration Options in Postgres 16
🟢 خلاصه مقاله:
این مطلب با تمرکز بر مخاطبان Golang Weekly توضیح می‌دهد که Postgres 16 چه بهبودهایی برای عملیات روزمره و یکپارچه‌سازی با سرویس‌ها آورده است. نویسنده روی حوزه‌های عملی مثل کارایی پایدارتر تحت بار، رفتار بهتر autovacuum، و رصدپذیری دقیق‌تر برای IO و پردازه‌های پس‌زمینه تأکید می‌کند تا تنظیمات و عیب‌یابی سریع‌تر و مطمئن‌تر انجام شود. همچنین به ارتقاهای مرتبط با replication منطقی و سنک‌کردن ایمن‌تر، مدیریت slotها و سناریوهای failover اشاره می‌کند تا پیاده‌سازی‌های HA و چندمنطقه‌ای ساده‌تر شوند. در بخش یکپارچه‌سازی، گزینه‌های Go مانند pgx و database/sql، مدیریت connection pooling با pgxpool یا PgBouncer، اتصال به سامانه‌های رویدادمحور از طریق logical decoding و ابزارهایی مثل Debezium، و الگوهای LISTEN/NOTIFY و FDW مرور می‌شود. جمع‌بندی مقاله: Postgres 16 دردسرهای عملیاتی را کمتر و ادغام با معماری‌های متنوع را ساده‌تر می‌کند و یک چک‌لیست کوتاه برای ارزیابی و ارتقای امن ارائه می‌دهد.
#Postgres16 #PostgreSQL #Golang #Go #Database #Replication #Observability #Performance
🟣لینک مقاله:
https://postgresweekly.com/link/175401/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Key Operational Enhancements and Integration Options in Postgres 16
🟢 خلاصه مقاله:
این مطلب با تمرکز بر مخاطبان Golang Weekly توضیح می‌دهد که Postgres 16 چه بهبودهایی برای عملیات روزمره و یکپارچه‌سازی با سرویس‌ها آورده است. نویسنده روی حوزه‌های عملی مثل کارایی پایدارتر تحت بار، رفتار بهتر autovacuum، و رصدپذیری دقیق‌تر برای IO و پردازه‌های پس‌زمینه تأکید می‌کند تا تنظیمات و عیب‌یابی سریع‌تر و مطمئن‌تر انجام شود. همچنین به ارتقاهای مرتبط با replication منطقی و سنک‌کردن ایمن‌تر، مدیریت slotها و سناریوهای failover اشاره می‌کند تا پیاده‌سازی‌های HA و چندمنطقه‌ای ساده‌تر شوند. در بخش یکپارچه‌سازی، گزینه‌های Go مانند pgx و database/sql، مدیریت connection pooling با pgxpool یا PgBouncer، اتصال به سامانه‌های رویدادمحور از طریق logical decoding و ابزارهایی مثل Debezium، و الگوهای LISTEN/NOTIFY و FDW مرور می‌شود. جمع‌بندی مقاله: Postgres 16 دردسرهای عملیاتی را کمتر و ادغام با معماری‌های متنوع را ساده‌تر می‌کند و یک چک‌لیست کوتاه برای ارزیابی و ارتقای امن ارائه می‌دهد.
#Postgres16 #PostgreSQL #Golang #Go #Database #Replication #Observability #Performance
🟣لینک مقاله:
https://postgresweekly.com/link/175401/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Severalnines
Key Operational enhancements and integration options in PostgreSQL 16
Discover why PostgreSQL 16 remains a crucial step for teams with its improved query planner and operational advancements for databases.
🔵 عنوان مقاله
memoize planner estimates in EXPLAIN.
🟢 خلاصه مقاله:
**
این مطلب که در شماره اخیر Golang Weekly معرفی شده، درباره memoize کردن برآوردهای planner در EXPLAIN است تا تحلیل پرس‌وجوها سریع‌تر و قابل‌اتکاتر شود. ایده اصلی این است که تخمین‌های میانی (مثل cardinality و هزینه‌ها) بر اساس نسخه نرمال‌شده‌ی بخش‌های پرس‌وجو و ورودی‌های اثرگذار (آمار جداول، وضعیت schema، و تنظیمات planner) ذخیره شوند و در اجرای‌های بعدی EXPLAIN دوباره استفاده شوند. نتیجه: کاهش هزینه محاسبات تکراری، ثبات بیشتر خروجی‌ها، و مقایسه آسان‌تر تغییرات.
در پیاده‌سازی با Go می‌توان با cacheهای سبک، هش‌کردن پرس‌وجوی نرمال‌شده و وضعیت کاتالوگ، و قلاب‌های ابطال (invalidation) قابل‌تنظیم به این هدف رسید؛ این رویکرد برای ابزارهای توسعه، CI و بنچمارک‌ها سودمند است. البته چالش‌ها هم مهم‌اند: کهنگی داده‌های cache با تغییر آمار یا تنظیمات، ضرورت سیاست‌های ابطال شفاف، ترجیحاً cache کردن فقط برآوردها (نه کل plan)، ارائه نشانگرهای hit/miss در خروجی EXPLAIN، و تعیین دامنه و سقف اندازه cache (مثلاً در سطح session).
به طور خلاصه، memoize کردن برآوردهای planner در EXPLAIN چرخه‌های تحلیل را تسریع و نتایج را پایدارتر می‌کند، به شرط آنکه مرزهای cache و سیاست‌های ابطال به‌خوبی مدیریت شوند.
#Golang #Go #EXPLAIN #Database #QueryPlanner #Memoization #Performance #Optimization
🟣لینک مقاله:
https://postgresweekly.com/link/175091/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
memoize planner estimates in EXPLAIN.
🟢 خلاصه مقاله:
**
این مطلب که در شماره اخیر Golang Weekly معرفی شده، درباره memoize کردن برآوردهای planner در EXPLAIN است تا تحلیل پرس‌وجوها سریع‌تر و قابل‌اتکاتر شود. ایده اصلی این است که تخمین‌های میانی (مثل cardinality و هزینه‌ها) بر اساس نسخه نرمال‌شده‌ی بخش‌های پرس‌وجو و ورودی‌های اثرگذار (آمار جداول، وضعیت schema، و تنظیمات planner) ذخیره شوند و در اجرای‌های بعدی EXPLAIN دوباره استفاده شوند. نتیجه: کاهش هزینه محاسبات تکراری، ثبات بیشتر خروجی‌ها، و مقایسه آسان‌تر تغییرات.
در پیاده‌سازی با Go می‌توان با cacheهای سبک، هش‌کردن پرس‌وجوی نرمال‌شده و وضعیت کاتالوگ، و قلاب‌های ابطال (invalidation) قابل‌تنظیم به این هدف رسید؛ این رویکرد برای ابزارهای توسعه، CI و بنچمارک‌ها سودمند است. البته چالش‌ها هم مهم‌اند: کهنگی داده‌های cache با تغییر آمار یا تنظیمات، ضرورت سیاست‌های ابطال شفاف، ترجیحاً cache کردن فقط برآوردها (نه کل plan)، ارائه نشانگرهای hit/miss در خروجی EXPLAIN، و تعیین دامنه و سقف اندازه cache (مثلاً در سطح session).
به طور خلاصه، memoize کردن برآوردهای planner در EXPLAIN چرخه‌های تحلیل را تسریع و نتایج را پایدارتر می‌کند، به شرط آنکه مرزهای cache و سیاست‌های ابطال به‌خوبی مدیریت شوند.
#Golang #Go #EXPLAIN #Database #QueryPlanner #Memoization #Performance #Optimization
🟣لینک مقاله:
https://postgresweekly.com/link/175091/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
🔵 عنوان مقاله
PostGIS Performance: pg_stat_statements and Postgres Tuning
🟢 خلاصه مقاله:
**این مقاله نشان می‌دهد چطور با استفاده از PostGIS روی Postgres می‌توان کارایی پرس‌وجوهای مکانی را بهبود داد. محور اصلی کار، اندازه‌گیری دقیق با pg_stat_statements برای شناسایی پرهزینه‌ترین پرس‌وجوها و سپس تحلیل آن‌ها با EXPLAIN/ANALYZE است. توصیه‌های کلیدی شامل انتخاب درست geometry یا geography، ساخت ایندکس‌های GiST/SP-GiST، نوشتن شرط‌های قابل استفاده توسط ایندکس (مثل ST_Intersects و محدوده‌های جعبه‌ای)، و اجرای VACUUM/ANALYZE پس از بارگذاری‌های حجیم است. در بخش تنظیمات Postgres هم به shared_buffers، effective_cache_size، work_mem، موازی‌سازی، تنظیمات autovacuum و در صورت نیاز پارتیشن‌بندی اشاره می‌شود. برای سرویس‌های Go (به نقل از Golang Weekly)، استفاده از pooling مناسب، جلوگیری از الگوهای N+1، Batch کردن عملیات، بهره‌گیری از COPY و تعیین statement_timeout توصیه شده است. رویکرد کلی: اندازه‌گیری، اعمال تغییرات هدفمند، و اعتبارسنجی مداوم برای رسیدن به کارایی پایدار و سریع‌تر.
#PostGIS #PostgreSQL #pg_stat_statements #DatabaseTuning #Geospatial #Golang #Performance #SQL
🟣لینک مقاله:
https://postgresweekly.com/link/176025/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
PostGIS Performance: pg_stat_statements and Postgres Tuning
🟢 خلاصه مقاله:
**این مقاله نشان می‌دهد چطور با استفاده از PostGIS روی Postgres می‌توان کارایی پرس‌وجوهای مکانی را بهبود داد. محور اصلی کار، اندازه‌گیری دقیق با pg_stat_statements برای شناسایی پرهزینه‌ترین پرس‌وجوها و سپس تحلیل آن‌ها با EXPLAIN/ANALYZE است. توصیه‌های کلیدی شامل انتخاب درست geometry یا geography، ساخت ایندکس‌های GiST/SP-GiST، نوشتن شرط‌های قابل استفاده توسط ایندکس (مثل ST_Intersects و محدوده‌های جعبه‌ای)، و اجرای VACUUM/ANALYZE پس از بارگذاری‌های حجیم است. در بخش تنظیمات Postgres هم به shared_buffers، effective_cache_size، work_mem، موازی‌سازی، تنظیمات autovacuum و در صورت نیاز پارتیشن‌بندی اشاره می‌شود. برای سرویس‌های Go (به نقل از Golang Weekly)، استفاده از pooling مناسب، جلوگیری از الگوهای N+1، Batch کردن عملیات، بهره‌گیری از COPY و تعیین statement_timeout توصیه شده است. رویکرد کلی: اندازه‌گیری، اعمال تغییرات هدفمند، و اعتبارسنجی مداوم برای رسیدن به کارایی پایدار و سریع‌تر.
#PostGIS #PostgreSQL #pg_stat_statements #DatabaseTuning #Geospatial #Golang #Performance #SQL
🟣لینک مقاله:
https://postgresweekly.com/link/176025/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Crunchy Data
PostGIS Performance: pg_stat_statements and Postgres tuning | Crunchy Data Blog
PostGIS performance basics. Second post in a series covering pg_stat_statements, shared buffers, work_mem, and parallel queries.
🔵 عنوان مقاله
its Call for Proposals is open
🟢 خلاصه مقاله:
** آخرین شماره Golang Weekly اعلام کرده که بخش Call for Proposals برای یک رویداد/ابتکار مرتبط با جامعه Go باز شده است. از اعضای جامعه دعوت می‌شود ایده‌های خود را در قالب سخنرانی، ورکشاپ، لایتنینگ‌تاک و پنل ارسال کنند؛ موضوعات پیشنهادی شامل بهینه‌سازی کارایی، الگوهای هم‌روندی، ابزارها و فریم‌ورک‌ها، سرویس‌های cloud-native با Go، تست و observability، و مطالعات موردی تولیدی است. برای یک پیشنهاد قوی، خلاصه‌ای شفاف با مسئله، مخاطب هدف و دستاوردهای مشخص ارائه کنید؛ نمونه کد یا دمو کمک‌کننده است، و از سخنرانان تازه‌کار نیز استقبال می‌شود. برای جزئیات، زمان‌بندی و لینک ارسال، به شماره اخیر Golang Weekly مراجعه کنید و زودتر ارسال کنید.
#Golang #GolangWeekly #CFP #CallForProposals #GoCommunity #TechTalks #SoftwareEngineering
🟣لینک مقاله:
https://postgresweekly.com/link/175722/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
its Call for Proposals is open
🟢 خلاصه مقاله:
** آخرین شماره Golang Weekly اعلام کرده که بخش Call for Proposals برای یک رویداد/ابتکار مرتبط با جامعه Go باز شده است. از اعضای جامعه دعوت می‌شود ایده‌های خود را در قالب سخنرانی، ورکشاپ، لایتنینگ‌تاک و پنل ارسال کنند؛ موضوعات پیشنهادی شامل بهینه‌سازی کارایی، الگوهای هم‌روندی، ابزارها و فریم‌ورک‌ها، سرویس‌های cloud-native با Go، تست و observability، و مطالعات موردی تولیدی است. برای یک پیشنهاد قوی، خلاصه‌ای شفاف با مسئله، مخاطب هدف و دستاوردهای مشخص ارائه کنید؛ نمونه کد یا دمو کمک‌کننده است، و از سخنرانان تازه‌کار نیز استقبال می‌شود. برای جزئیات، زمان‌بندی و لینک ارسال، به شماره اخیر Golang Weekly مراجعه کنید و زودتر ارسال کنید.
#Golang #GolangWeekly #CFP #CallForProposals #GoCommunity #TechTalks #SoftwareEngineering
🟣لینک مقاله:
https://postgresweekly.com/link/175722/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
cfp.p2d2.cz
Prague PostgreSQL Developer Day 2026
Schedule, talks and talk submissions for Prague PostgreSQL Developer Day 2026
🔥1
🔵 عنوان مقاله
Postgres 18's UUIDv7: Faster and Secure Time-Ordered IDs
🟢 خلاصه مقاله:
**پشتیبانی از UUIDv7 در Postgres 18 شناسه‌هایی زمان‌مرتب ارائه می‌دهد که برخلاف UUIDv4 باعث پراکندگی شدید ایندکس‌ها نمی‌شوند. بخش زمان در ابتدای UUIDv7 باعث می‌شود درج‌ها عمدتاً به انتهای B-tree اضافه شوند و از شکستن صفحه‌ها، افت کش و ناپایداری توان نوشتن جلوگیری شود. همزمان، بخش‌های تصادفیِ کافی باقی می‌ماند تا شناسه‌ها منحصربه‌فرد، غیرقابل پیش‌بینی و مناسب برای محیط‌های توزیع‌شده باشند؛ بدون افشای جزئیات سخت‌افزاری مانند نسخه‌های قدیمی‌تر.
برای تیم‌های Go که از Postgres استفاده می‌کنند، این تغییر به‌خوبی با الگوهای متداول سرویس‌های رویدادمحور، لاگ‌های افزایشی و نوشتن در مقیاس افقی سازگار است. تولید UUIDv7 در لایه اپلیکیشن و ذخیره آن در ستون نوع uuid ساده است و بسیاری از کتابخانه‌های Go از آن پشتیبانی می‌کنند. برای مهاجرت، جدول‌های جدید می‌توانند مستقیماً از UUIDv7 استفاده کنند و جدول‌های موجود می‌توانند به‌تدریج تغییر کنند؛ تنها به صحت و یکنواختی ساعت سرورها برای حفظ ترتیب توجه کنید و برای نیازهای زمانی دقیق همچنان از ستون‌های timestamp بهره بگیرید.
به‌طور خلاصه، UUIDv7 در Postgres 18 ترکیبی از عملکرد بهتر درج و ایندکس، سادگی عملیاتی و امنیت بیشتر را فراهم می‌کند؛ همان‌طور که در Golang Weekly نیز بر هم‌سویی طبیعی آن با معماری سرویس‌های Go تاکید شده است.
#Postgres #PostgreSQL #UUIDv7 #Go #Golang #DatabasePerformance #Scalability
🟣لینک مقاله:
https://postgresweekly.com/link/176368/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Postgres 18's UUIDv7: Faster and Secure Time-Ordered IDs
🟢 خلاصه مقاله:
**پشتیبانی از UUIDv7 در Postgres 18 شناسه‌هایی زمان‌مرتب ارائه می‌دهد که برخلاف UUIDv4 باعث پراکندگی شدید ایندکس‌ها نمی‌شوند. بخش زمان در ابتدای UUIDv7 باعث می‌شود درج‌ها عمدتاً به انتهای B-tree اضافه شوند و از شکستن صفحه‌ها، افت کش و ناپایداری توان نوشتن جلوگیری شود. همزمان، بخش‌های تصادفیِ کافی باقی می‌ماند تا شناسه‌ها منحصربه‌فرد، غیرقابل پیش‌بینی و مناسب برای محیط‌های توزیع‌شده باشند؛ بدون افشای جزئیات سخت‌افزاری مانند نسخه‌های قدیمی‌تر.
برای تیم‌های Go که از Postgres استفاده می‌کنند، این تغییر به‌خوبی با الگوهای متداول سرویس‌های رویدادمحور، لاگ‌های افزایشی و نوشتن در مقیاس افقی سازگار است. تولید UUIDv7 در لایه اپلیکیشن و ذخیره آن در ستون نوع uuid ساده است و بسیاری از کتابخانه‌های Go از آن پشتیبانی می‌کنند. برای مهاجرت، جدول‌های جدید می‌توانند مستقیماً از UUIDv7 استفاده کنند و جدول‌های موجود می‌توانند به‌تدریج تغییر کنند؛ تنها به صحت و یکنواختی ساعت سرورها برای حفظ ترتیب توجه کنید و برای نیازهای زمانی دقیق همچنان از ستون‌های timestamp بهره بگیرید.
به‌طور خلاصه، UUIDv7 در Postgres 18 ترکیبی از عملکرد بهتر درج و ایندکس، سادگی عملیاتی و امنیت بیشتر را فراهم می‌کند؛ همان‌طور که در Golang Weekly نیز بر هم‌سویی طبیعی آن با معماری سرویس‌های Go تاکید شده است.
#Postgres #PostgreSQL #UUIDv7 #Go #Golang #DatabasePerformance #Scalability
🟣لینک مقاله:
https://postgresweekly.com/link/176368/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Hashrocket
PostgreSQL 18's UUIDv7: Faster and Secure Time-Ordered IDs
PostgreSQL 18 dropped last month with a bunch of exciting updates. While the performance improvements are always welcome, there's one developer-friendly feature that deserves the spotlight: native support for UUIDv7. This new format might change how model…
🔵 عنوان مقاله
her experience of last week's PGConf EU event.
🟢 خلاصه مقاله:
تجربه نویسنده از PGConf EU هفته گذشته نشان می‌دهد که رویداد امسال ترکیبی از راهکارهای عملی، مطالعه‌های موردی واقعی و گفت‌وگوهای ارزشمند جانبی بود. تمرکز اصلی روی بهینه‌سازی کارایی، تاب‌آوری عملیاتی، مهاجرت‌ها، انتخاب Extensionها، استقرار ابری و Observability بود و نتیجه‌گیری او این است که اکوسیستم PostgreSQL بالغ‌تر و قابل‌دسترس‌تر از گذشته شده است. او در ادامه به آخرین مقاله Golang Weekly اشاره می‌کند که به‌خوبی با این موضوعات پیوند می‌خورد: الگوهای مؤثر در Go برای کار با پایگاه‌داده، از جمله استفاده بهینه از database/sql، زمان‌هایی که استفاده از pgx ترجیح دارد، مدیریت context برای Timeout و Cancellation، Pooling اتصال‌ها و راهبردهای Backpressure در بار همزمانی بالا. جمع‌بندی او این است که ترکیب درس‌های PGConf EU با نکات Golang Weekly یک نقشه راه عملی برای ساخت سرویس‌های داده‌محور در Go فراهم می‌کند؛ نقشه‌ای که به بهبود پایه‌های کارایی، پوشش تست مسیرهای دسترسی به داده و شفاف‌تر کردن SLOها با Observability بهتر منجر می‌شود.
#PGConfEU #PostgreSQL #Golang #GolangWeekly #DatabaseEngineering #PerformanceTuning #GoProgramming #Observability
🟣لینک مقاله:
https://postgresweekly.com/link/176359/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
her experience of last week's PGConf EU event.
🟢 خلاصه مقاله:
تجربه نویسنده از PGConf EU هفته گذشته نشان می‌دهد که رویداد امسال ترکیبی از راهکارهای عملی، مطالعه‌های موردی واقعی و گفت‌وگوهای ارزشمند جانبی بود. تمرکز اصلی روی بهینه‌سازی کارایی، تاب‌آوری عملیاتی، مهاجرت‌ها، انتخاب Extensionها، استقرار ابری و Observability بود و نتیجه‌گیری او این است که اکوسیستم PostgreSQL بالغ‌تر و قابل‌دسترس‌تر از گذشته شده است. او در ادامه به آخرین مقاله Golang Weekly اشاره می‌کند که به‌خوبی با این موضوعات پیوند می‌خورد: الگوهای مؤثر در Go برای کار با پایگاه‌داده، از جمله استفاده بهینه از database/sql، زمان‌هایی که استفاده از pgx ترجیح دارد، مدیریت context برای Timeout و Cancellation، Pooling اتصال‌ها و راهبردهای Backpressure در بار همزمانی بالا. جمع‌بندی او این است که ترکیب درس‌های PGConf EU با نکات Golang Weekly یک نقشه راه عملی برای ساخت سرویس‌های داده‌محور در Go فراهم می‌کند؛ نقشه‌ای که به بهبود پایه‌های کارایی، پوشش تست مسیرهای دسترسی به داده و شفاف‌تر کردن SLOها با Observability بهتر منجر می‌شود.
#PGConfEU #PostgreSQL #Golang #GolangWeekly #DatabaseEngineering #PerformanceTuning #GoProgramming #Observability
🟣لینک مقاله:
https://postgresweekly.com/link/176359/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
DEV Community
My PGConf EU 2025 experience
Last week marked the 2025 edition of PGConf EU. I had many roles, and I'm excited to let you know...
❤1
🔵 عنوان مقاله
ClickPipes for Postgres now supports failover replication slots.
🟢 خلاصه مقاله:
** این به‌روزرسانی اعلام می‌کند که ClickPipes for Postgres اکنون از failover replication slots پشتیبانی می‌کند؛ قابلیتی که در محیط‌های با قابلیت دسترس‌پذیری بالا باعث تداوم جریان داده هنگام جابه‌جایی از primary به standby می‌شود. با حفظ موقعیت اسلات در زمان failover، مصرف‌کنندگان CDC می‌توانند بی‌وقفه روی primary جدید ادامه دهند، بدون از دست‌دادن داده یا رشد غیرقابل‌کنترل WAL. این تغییر ریسک عملیاتی را کم می‌کند، پیاده‌سازی HA را ساده‌تر می‌سازد و برای تیم‌های Go که روی Postgres سرویس‌های داده می‌سازند—طبق پوشش آخرین شماره Golang Weekly—خبر مهمی است.
#Postgres #Replication #Failover #ClickPipes #Golang #CDC #HighAvailability #DataEngineering
🟣لینک مقاله:
https://postgresweekly.com/link/176987/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
ClickPipes for Postgres now supports failover replication slots.
🟢 خلاصه مقاله:
** این به‌روزرسانی اعلام می‌کند که ClickPipes for Postgres اکنون از failover replication slots پشتیبانی می‌کند؛ قابلیتی که در محیط‌های با قابلیت دسترس‌پذیری بالا باعث تداوم جریان داده هنگام جابه‌جایی از primary به standby می‌شود. با حفظ موقعیت اسلات در زمان failover، مصرف‌کنندگان CDC می‌توانند بی‌وقفه روی primary جدید ادامه دهند، بدون از دست‌دادن داده یا رشد غیرقابل‌کنترل WAL. این تغییر ریسک عملیاتی را کم می‌کند، پیاده‌سازی HA را ساده‌تر می‌سازد و برای تیم‌های Go که روی Postgres سرویس‌های داده می‌سازند—طبق پوشش آخرین شماره Golang Weekly—خبر مهمی است.
#Postgres #Replication #Failover #ClickPipes #Golang #CDC #HighAvailability #DataEngineering
🟣لینک مقاله:
https://postgresweekly.com/link/176987/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
ClickHouse
ClickPipes for Postgres now supports failover replication slots
Learn about how failover-ready replication slots keep Postgres CDC pipelines running without interruption.
🔵 عنوان مقاله
Spock: Logical Multi-Master PostgreSQL Replication
🟢 خلاصه مقاله:
این مقاله Spock را معرفی می‌کند؛ لایه‌ای برای Logical Multi‑Master Replication روی PostgreSQL که اجازه می‌دهد چند نود همزمان عملیات نوشتن را بپذیرند و داده‌ها را بین خود همگام نگه دارند. برخلاف Physical Replication که به یک لیدر متکی است، Spock با استفاده از logical decoding تغییرات سطری را دریافت و روی نودهای دیگر اعمال می‌کند و بدین ترتیب امکان active‑active و حتی انتشار بخشی از DDL را فراهم می‌سازد.
نویسنده چالش‌های اصلی Multi‑Master را توضیح می‌دهد: تشخیص و رفع تضادهای نوشتن، سیاست‌های قابل پیکربندی مثل last‑update‑wins یا روش‌های سفارشی، مدیریت شناسه‌های یکتا و sequenceها، و تغییر توپولوژی بدون توقف. از نظر عملیاتی نیز نظارت بر lag، ثبت و رصد تضادها، و طراحی الگوهای اپلیکیشنی مثل upsert و عملیات idempotent ضروری است؛ استفاده از UUID به جای sequenceهای متمرکز می‌تواند تعارض‌ها را کم کند. نتیجه‌گیری این است که Spock جایگزین ساده برای سازگاری قوی سراسری نیست، اما برای سناریوهای active‑active با پذیرش eventual consistency گزینه‌ای قوی است.
در مقایسه با گزینه‌های دیگر (Built‑in Logical Replication تک‑مستر، Physical Streaming، و راهکارهایی مانند BDR یا Bucardo)، Spock تمرکز را بر Multi‑Master منطقی می‌گذارد و در قبال پیچیدگی بیشتر، استقلال از یک primary واحد را می‌دهد. از آن‌جا که این مطلب در Golang Weekly آمده، نکات پیاده‌سازی برای سرویس‌های Go نیز مطرح می‌شود: اتصال از طریق database/sql یا pgx به نود محلی برای کاهش تاخیر، مدیریت retry و conflict، و استفاده از الگوهایی مثل transactional outbox و CDC برای ساخت سیستم‌های رویدادمحور قابل اتکا.
#PostgreSQL #Spock #LogicalReplication #MultiMaster #Golang #DistributedSystems #DatabaseReplication #HighAvailability
🟣لینک مقاله:
https://postgresweekly.com/link/177326/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Spock: Logical Multi-Master PostgreSQL Replication
🟢 خلاصه مقاله:
این مقاله Spock را معرفی می‌کند؛ لایه‌ای برای Logical Multi‑Master Replication روی PostgreSQL که اجازه می‌دهد چند نود همزمان عملیات نوشتن را بپذیرند و داده‌ها را بین خود همگام نگه دارند. برخلاف Physical Replication که به یک لیدر متکی است، Spock با استفاده از logical decoding تغییرات سطری را دریافت و روی نودهای دیگر اعمال می‌کند و بدین ترتیب امکان active‑active و حتی انتشار بخشی از DDL را فراهم می‌سازد.
نویسنده چالش‌های اصلی Multi‑Master را توضیح می‌دهد: تشخیص و رفع تضادهای نوشتن، سیاست‌های قابل پیکربندی مثل last‑update‑wins یا روش‌های سفارشی، مدیریت شناسه‌های یکتا و sequenceها، و تغییر توپولوژی بدون توقف. از نظر عملیاتی نیز نظارت بر lag، ثبت و رصد تضادها، و طراحی الگوهای اپلیکیشنی مثل upsert و عملیات idempotent ضروری است؛ استفاده از UUID به جای sequenceهای متمرکز می‌تواند تعارض‌ها را کم کند. نتیجه‌گیری این است که Spock جایگزین ساده برای سازگاری قوی سراسری نیست، اما برای سناریوهای active‑active با پذیرش eventual consistency گزینه‌ای قوی است.
در مقایسه با گزینه‌های دیگر (Built‑in Logical Replication تک‑مستر، Physical Streaming، و راهکارهایی مانند BDR یا Bucardo)، Spock تمرکز را بر Multi‑Master منطقی می‌گذارد و در قبال پیچیدگی بیشتر، استقلال از یک primary واحد را می‌دهد. از آن‌جا که این مطلب در Golang Weekly آمده، نکات پیاده‌سازی برای سرویس‌های Go نیز مطرح می‌شود: اتصال از طریق database/sql یا pgx به نود محلی برای کاهش تاخیر، مدیریت retry و conflict، و استفاده از الگوهایی مثل transactional outbox و CDC برای ساخت سیستم‌های رویدادمحور قابل اتکا.
#PostgreSQL #Spock #LogicalReplication #MultiMaster #Golang #DistributedSystems #DatabaseReplication #HighAvailability
🟣لینک مقاله:
https://postgresweekly.com/link/177326/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
GitHub
GitHub - pgEdge/spock: Logical multi-master PostgreSQL replication
Logical multi-master PostgreSQL replication. Contribute to pgEdge/spock development by creating an account on GitHub.
🔵 عنوان مقاله
discuss what went wrong (and right!) with implementing asynchronous I/O
🟢 خلاصه مقاله:
این مقاله در Golang Weekly با مرور تجربه پیاده‌سازی I/O ناهمگام توضیح می‌دهد که چرا ایده «عدم انسداد» ساده به نظر می‌رسد اما در عمل با تفاوت‌های پلتفرمی و جزئیات ظریف سیستم‌عامل پیچیده می‌شود. بین Linux (epoll و io_uring)، BSD (kqueue) و Windows (IOCP) نه‌تنها APIها متفاوت‌اند، بلکه معنای آمادگی در برابر تکمیل، تریگر لبه‌ای یا سطحی، زمان‌بندی، و چرخه عمر descriptorها هم فرق می‌کند.
در Go، فلسفه این بوده که پیچیدگی پشت goroutine و netpoller پنهان شود تا کدنویسی ساده و «مسدودکننده» بماند، در حالی که اجرای واقعی غیرمسدودکننده باشد. این انتخاب، یادگیری و صحت را بهبود داده، اما در مقیاس بالا مشکل‌هایی مثل انسدادهای پنهان در برنامه‌ریز، نشت goroutine به‌دلیل لغو ناقص، بی‌عدالتی بین ارتباط‌ها، و اختلافات پلتفرمی در خطاها و semantics را آشکار کرده است.
اشتباهات رایج از «نشت انتزاع» می‌آیند: ساده‌سازی بیش از حد APIهای مسدودکننده، نبودِ backpressure کافی و رصدپذیری، اتکا زودهنگام به یک قابلیت خاص کرنل، و آزمون‌های ناپایدار که تفاوت‌های سیستم‌عامل‌ها را می‌پوشانند؛ خروجی آن هم تاخیرهای غیرقابل پیش‌بینی، رشد حافظه و مشکلات پایداری است.
در عوض، نقاط قوت هم پررنگ‌اند: مدل «کدنویسی مسدودکننده، اجرای ناهمگام» با بهبودهای تدریجی در runtime، netpoller، تایمرها و preemption همراه شده و الگوهای استاندارد مثل context.Context برای لغو، channels برای backpressure، و کتابخانه‌های net/http و database/sql رفتارهای امن‌تری فراهم کرده‌اند. روی Linux، آزمایش‌های محتاطانه با io_uring امید به کاهش syscallها و بیدارباش‌ها را نشان می‌دهد، با fallbacks برای سازگاری. استقرار تدریجی و بنچمارک‌های دقیق هم جلوی پسرفت‌ها را گرفته‌اند.
جمع‌بندی عملی: پیش و پس از تغییر مسیر I/O حتما اندازه‌گیری کنید؛ لغو را به چرخه عمر منابع گره بزنید؛ منطق مخصوص هر پلتفرم را ایزوله نگه دارید؛ backpressure را در APIها نمایان کنید؛ و روی رصدپذیری (tracing/metrics) برای عمق صف‌ها، wakeupها و تعامل با scheduler سرمایه‌گذاری کنید. از قابلیت‌های جدید کرنل به‌صورت افزایشی و با احتیاط استفاده کنید و سطح برنامه‌نویسی را ساده نگه دارید. در عمل، از فراخوانی‌های مبتنی بر context و timeout استفاده کنید، از ایجاد goroutine بی‌رویه برای I/O پرهیز کنید، به استانداردها تکیه کنید، تنها با داده سراغ tuning بروید، و حتما روی Linux، BSD و Windows تست بگیرید. دستاوردهای I/O ناهمگام واقعی‌اند، اما با انضباط مهندسی به‌دست می‌آیند، نه صرفا با انتخاب یک primitive جدید.
#Golang #AsyncIO #Concurrency #SystemsProgramming #epoll #kqueue #io_uring #Netpoller
🟣لینک مقاله:
https://postgresweekly.com/link/176360/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
discuss what went wrong (and right!) with implementing asynchronous I/O
🟢 خلاصه مقاله:
این مقاله در Golang Weekly با مرور تجربه پیاده‌سازی I/O ناهمگام توضیح می‌دهد که چرا ایده «عدم انسداد» ساده به نظر می‌رسد اما در عمل با تفاوت‌های پلتفرمی و جزئیات ظریف سیستم‌عامل پیچیده می‌شود. بین Linux (epoll و io_uring)، BSD (kqueue) و Windows (IOCP) نه‌تنها APIها متفاوت‌اند، بلکه معنای آمادگی در برابر تکمیل، تریگر لبه‌ای یا سطحی، زمان‌بندی، و چرخه عمر descriptorها هم فرق می‌کند.
در Go، فلسفه این بوده که پیچیدگی پشت goroutine و netpoller پنهان شود تا کدنویسی ساده و «مسدودکننده» بماند، در حالی که اجرای واقعی غیرمسدودکننده باشد. این انتخاب، یادگیری و صحت را بهبود داده، اما در مقیاس بالا مشکل‌هایی مثل انسدادهای پنهان در برنامه‌ریز، نشت goroutine به‌دلیل لغو ناقص، بی‌عدالتی بین ارتباط‌ها، و اختلافات پلتفرمی در خطاها و semantics را آشکار کرده است.
اشتباهات رایج از «نشت انتزاع» می‌آیند: ساده‌سازی بیش از حد APIهای مسدودکننده، نبودِ backpressure کافی و رصدپذیری، اتکا زودهنگام به یک قابلیت خاص کرنل، و آزمون‌های ناپایدار که تفاوت‌های سیستم‌عامل‌ها را می‌پوشانند؛ خروجی آن هم تاخیرهای غیرقابل پیش‌بینی، رشد حافظه و مشکلات پایداری است.
در عوض، نقاط قوت هم پررنگ‌اند: مدل «کدنویسی مسدودکننده، اجرای ناهمگام» با بهبودهای تدریجی در runtime، netpoller، تایمرها و preemption همراه شده و الگوهای استاندارد مثل context.Context برای لغو، channels برای backpressure، و کتابخانه‌های net/http و database/sql رفتارهای امن‌تری فراهم کرده‌اند. روی Linux، آزمایش‌های محتاطانه با io_uring امید به کاهش syscallها و بیدارباش‌ها را نشان می‌دهد، با fallbacks برای سازگاری. استقرار تدریجی و بنچمارک‌های دقیق هم جلوی پسرفت‌ها را گرفته‌اند.
جمع‌بندی عملی: پیش و پس از تغییر مسیر I/O حتما اندازه‌گیری کنید؛ لغو را به چرخه عمر منابع گره بزنید؛ منطق مخصوص هر پلتفرم را ایزوله نگه دارید؛ backpressure را در APIها نمایان کنید؛ و روی رصدپذیری (tracing/metrics) برای عمق صف‌ها، wakeupها و تعامل با scheduler سرمایه‌گذاری کنید. از قابلیت‌های جدید کرنل به‌صورت افزایشی و با احتیاط استفاده کنید و سطح برنامه‌نویسی را ساده نگه دارید. در عمل، از فراخوانی‌های مبتنی بر context و timeout استفاده کنید، از ایجاد goroutine بی‌رویه برای I/O پرهیز کنید، به استانداردها تکیه کنید، تنها با داده سراغ tuning بروید، و حتما روی Linux، BSD و Windows تست بگیرید. دستاوردهای I/O ناهمگام واقعی‌اند، اما با انضباط مهندسی به‌دست می‌آیند، نه صرفا با انتخاب یک primitive جدید.
#Golang #AsyncIO #Concurrency #SystemsProgramming #epoll #kqueue #io_uring #Netpoller
🟣لینک مقاله:
https://postgresweekly.com/link/176360/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Talking Postgres with Claire Giordano
Talking Postgres with Claire Giordano | What went wrong (& what went right) with AIO with Andres Freund
Six years, a prototype, and a brief multi-layered descent into “wronger and wronger” design—what does it take to land a major architectural change in Postgres? In Episode 31 of Talking Postgres, An...