🔵 عنوان مقاله
Postgres 13 has reached its 'end of life' today
🟢 خلاصه مقاله:
نسخه Postgres 13 امروز به پایان چرخه پشتیبانی رسید و دیگر هیچ وصله امنیتی یا رفع باگی از سوی جامعه دریافت نمی‌کند. ماندن روی این نسخه ریسک امنیتی و انطباقی دارد و ممکن است مخازن و ارائه‌دهندگان نیز آن را محدود یا از رده خارج کنند. توصیه می‌شود هرچه زودتر به یکی از نسخه‌های پشتیبانی‌شده (مثلاً 14، 15، 16 یا 17) ارتقا دهید. برای ارتقا با توجه به نیازها از pg_upgrade (Downtime کم)، logical replication (تقریباً بی‌وقفه) یا pg_dump/pg_restore استفاده کنید، سازگاری اپلیکیشن و افزونه‌ها را در محیط staging بسنجید، تغییرات پیکربندی و یادداشت‌های انتشار را مرور کنید و از داشتن نسخه پشتیبان و برنامه بازگشت اطمینان بگیرید. در سرویس‌های مدیریت‌شده مانند AWS RDS، Azure Database for PostgreSQL و Google Cloud SQL نیز احتمال زمان‌بندی ارتقای اجباری وجود دارد. اگر ارتقای فوری ممکن نیست، پشتیبانی تمدیدشده شخص ثالث فقط یک راه‌حل موقت است و جایگزین ارتقای واقعی نمی‌شود.
#PostgreSQL #Postgres13 #EOL #DatabaseSecurity #Upgrade #DBA #InfoSec #CloudDatabases
🟣لینک مقاله:
https://postgresweekly.com/link/176979/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Postgres 13 has reached its 'end of life' today
🟢 خلاصه مقاله:
نسخه Postgres 13 امروز به پایان چرخه پشتیبانی رسید و دیگر هیچ وصله امنیتی یا رفع باگی از سوی جامعه دریافت نمی‌کند. ماندن روی این نسخه ریسک امنیتی و انطباقی دارد و ممکن است مخازن و ارائه‌دهندگان نیز آن را محدود یا از رده خارج کنند. توصیه می‌شود هرچه زودتر به یکی از نسخه‌های پشتیبانی‌شده (مثلاً 14، 15، 16 یا 17) ارتقا دهید. برای ارتقا با توجه به نیازها از pg_upgrade (Downtime کم)، logical replication (تقریباً بی‌وقفه) یا pg_dump/pg_restore استفاده کنید، سازگاری اپلیکیشن و افزونه‌ها را در محیط staging بسنجید، تغییرات پیکربندی و یادداشت‌های انتشار را مرور کنید و از داشتن نسخه پشتیبان و برنامه بازگشت اطمینان بگیرید. در سرویس‌های مدیریت‌شده مانند AWS RDS، Azure Database for PostgreSQL و Google Cloud SQL نیز احتمال زمان‌بندی ارتقای اجباری وجود دارد. اگر ارتقای فوری ممکن نیست، پشتیبانی تمدیدشده شخص ثالث فقط یک راه‌حل موقت است و جایگزین ارتقای واقعی نمی‌شود.
#PostgreSQL #Postgres13 #EOL #DatabaseSecurity #Upgrade #DBA #InfoSec #CloudDatabases
🟣لینک مقاله:
https://postgresweekly.com/link/176979/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Percona Database Performance Blog
PostgreSQL 13 Is Reaching End of Life. The Time to Upgrade is Now!
PostgreSQL 13 is reaching end of life on November 13, 2025. Treat your upgrade not as maintenance, but rather as an investment in security, stability, and innovation.
🔵 عنوان مقاله
Learn Advanced Analytical Techniques Used in the Intelligence Community (Sponsor)
🟢 خلاصه مقاله:
این برنامه Online Master of Professional Studies in Applied Intelligence از Georgetown University مهارت‌های تحلیلی پیشرفته مورد استفاده در Intelligence Community را به‌صورت کاربردی آموزش می‌دهد تا تحلیلگران در بخش‌های دولتی و خصوصی بتوانند پدیده‌های پیچیده را تحلیل کنند، روندها را شناسایی کنند و در محیط‌های پرریسک خروجی‌های قابل اقدام ارائه دهند. تمرکز دوره بر تفکر انتقادی، روش‌های تحلیلی ساخت‌یافته، جمع‌آوری و ارزیابی داده‌ها، سنجش تهدید و ارتباط مؤثر با تصمیم‌گیران است و از طریق مطالعه‌ی موردی و تمرین‌های عملی در قالب آنلاینِ منعطف ارائه می‌شود. برای آشنایی بیشتر می‌توانید در یک کلاس نمونه‌ی رایگان شرکت کنید.
#AppliedIntelligence #GeorgetownUniversity #IntelligenceAnalysis #RiskAssessment #AnalyticalSkills #OnlineMasters #PublicSector #PrivateSector
🟣لینک مقاله:
https://scs.georgetown.edu/news-and-events/event/10080/applied-intelligence-sample-class-virtual-2025-10-28?&utm_source=tldr&utm_medium=newsletter&utm_campaign=fy26-encora-ai-en-tldr-data-event-text-vsc-20251016
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Learn Advanced Analytical Techniques Used in the Intelligence Community (Sponsor)
🟢 خلاصه مقاله:
این برنامه Online Master of Professional Studies in Applied Intelligence از Georgetown University مهارت‌های تحلیلی پیشرفته مورد استفاده در Intelligence Community را به‌صورت کاربردی آموزش می‌دهد تا تحلیلگران در بخش‌های دولتی و خصوصی بتوانند پدیده‌های پیچیده را تحلیل کنند، روندها را شناسایی کنند و در محیط‌های پرریسک خروجی‌های قابل اقدام ارائه دهند. تمرکز دوره بر تفکر انتقادی، روش‌های تحلیلی ساخت‌یافته، جمع‌آوری و ارزیابی داده‌ها، سنجش تهدید و ارتباط مؤثر با تصمیم‌گیران است و از طریق مطالعه‌ی موردی و تمرین‌های عملی در قالب آنلاینِ منعطف ارائه می‌شود. برای آشنایی بیشتر می‌توانید در یک کلاس نمونه‌ی رایگان شرکت کنید.
#AppliedIntelligence #GeorgetownUniversity #IntelligenceAnalysis #RiskAssessment #AnalyticalSkills #OnlineMasters #PublicSector #PrivateSector
🟣لینک مقاله:
https://scs.georgetown.edu/news-and-events/event/10080/applied-intelligence-sample-class-virtual-2025-10-28?&utm_source=tldr&utm_medium=newsletter&utm_campaign=fy26-encora-ai-en-tldr-data-event-text-vsc-20251016
➖➖➖➖➖➖➖➖
👑 @Database_Academy
scs.georgetown.edu
Professional Master's Degree Programs
|
Georgetown SCS
|
Georgetown SCS
Georgetown University School of Continuing Studies offers a wide range of options that assist a diverse community of students in reaching their educational goals.
🔵 عنوان مقاله
What Do Postgres 18's New 'Index Searches' Lines in EXPLAIN Mean?
🟢 خلاصه مقاله:
در Postgres 18 خط جدیدی به خروجی EXPLAIN ANALYZE اضافه شده به نام Index Searches که تعداد «پروب‌های منطقی» به ایندکس را در طول اجرای هر نود نشان می‌دهد. این شمارنده با تعداد ردیف‌های تولیدشده فرق دارد: ممکن است یک جست‌وجوی ایندکسی ده‌ها یا صدها ردیف برگرداند (مثلاً در یک رِنج اسکن)، یا برعکس، تعداد زیادی جست‌وجو انجام شود اما خروجی کمی تولید شود.
این خط در نودهای مرتبط با ایندکس مثل Index Scan، Index Only Scan و Bitmap Index Scan دیده می‌شود و در طرح‌های پارامتری (مثلاً Nested Loop با Index Scan در سمت داخلی) بسیار کمک‌کننده است؛ معمولاً برای هر ردیفِ سمت بیرونی، یک Index Search ثبت می‌شود. اگر تعداد Index Searches بالا و خروجی کم باشد، احتمال تکرار پروب‌های غیرکارا وجود دارد و شاید بهتر باشد استراتژی جوین (مثلاً Hash Join)، طراحی ایندکس‌های ترکیبی یا خود عبارت‌های شرطی را بازنگری کنید.
برای تیونینگ، عدد Index Searches را در کنار rows و زمان‌بندی‌ها مقایسه کنید تا «هزینه هر پروب» و «انتخاب‌پذیری» را بهتر بفهمید. توجه کنید که این شاخص نشان‌دهنده پروب‌های منطقی است و مستقیماً بیانگر I/O فیزیکی نیست. همچنین در طرح‌های موازی به‌صورت هر-ورتکر/نود گزارش می‌شود و فقط با EXPLAIN ANALYZE در دسترس است. در مجموع، این قابلیت جدید دید دقیق‌تری از الگوهای دسترسی ایندکس، تناسب ایندکس و انتخاب استراتژی جوین به شما می‌دهد.
#Postgres #PostgreSQL18 #EXPLAINANALYZE #Indexing #QueryOptimization #DatabasePerformance #IndexScan
🟣لینک مقاله:
https://postgresweekly.com/link/176988/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
What Do Postgres 18's New 'Index Searches' Lines in EXPLAIN Mean?
🟢 خلاصه مقاله:
در Postgres 18 خط جدیدی به خروجی EXPLAIN ANALYZE اضافه شده به نام Index Searches که تعداد «پروب‌های منطقی» به ایندکس را در طول اجرای هر نود نشان می‌دهد. این شمارنده با تعداد ردیف‌های تولیدشده فرق دارد: ممکن است یک جست‌وجوی ایندکسی ده‌ها یا صدها ردیف برگرداند (مثلاً در یک رِنج اسکن)، یا برعکس، تعداد زیادی جست‌وجو انجام شود اما خروجی کمی تولید شود.
این خط در نودهای مرتبط با ایندکس مثل Index Scan، Index Only Scan و Bitmap Index Scan دیده می‌شود و در طرح‌های پارامتری (مثلاً Nested Loop با Index Scan در سمت داخلی) بسیار کمک‌کننده است؛ معمولاً برای هر ردیفِ سمت بیرونی، یک Index Search ثبت می‌شود. اگر تعداد Index Searches بالا و خروجی کم باشد، احتمال تکرار پروب‌های غیرکارا وجود دارد و شاید بهتر باشد استراتژی جوین (مثلاً Hash Join)، طراحی ایندکس‌های ترکیبی یا خود عبارت‌های شرطی را بازنگری کنید.
برای تیونینگ، عدد Index Searches را در کنار rows و زمان‌بندی‌ها مقایسه کنید تا «هزینه هر پروب» و «انتخاب‌پذیری» را بهتر بفهمید. توجه کنید که این شاخص نشان‌دهنده پروب‌های منطقی است و مستقیماً بیانگر I/O فیزیکی نیست. همچنین در طرح‌های موازی به‌صورت هر-ورتکر/نود گزارش می‌شود و فقط با EXPLAIN ANALYZE در دسترس است. در مجموع، این قابلیت جدید دید دقیق‌تری از الگوهای دسترسی ایندکس، تناسب ایندکس و انتخاب استراتژی جوین به شما می‌دهد.
#Postgres #PostgreSQL18 #EXPLAINANALYZE #Indexing #QueryOptimization #DatabasePerformance #IndexScan
🟣لینک مقاله:
https://postgresweekly.com/link/176988/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
pgMustard
What do the new Index Searches lines in EXPLAIN mean? - pgMustard
In Postgres 18 you’ll now see “Index Searches” lines in EXPLAIN ANALYZE output. If like me you were wondering what those mean exactly, you’re in the right place.
🔵 عنوان مقاله
NoraSearch: Extension to Quickly Find Substring Match Offsets and Counts
🟢 خلاصه مقاله:
**نوراSearch افزونه‌ای سبک برای جست‌وجوی سریع و دقیق زیررشته‌هاست که فهرستی از جفت‌های {موقعیت شروع، طول تطابق} برمی‌گرداند. برای نمونه، جست‌وجوی 'abra' در 'abracadabra' به صورت {{0,4},{7,4}} گزارش می‌شود. نویسنده یکی از کارکردهای کلیدی آن را تحلیل توالی‌های DNA می‌داند؛ افزون بر آن، در متن‌کاوی، جست‌وجوی کد، پایش لاگ و ایندکس‌گذاری نیز هر جا به موقعیت‌ها و شمارش دقیق تطابق‌ها نیاز باشد، سودمند است.
#SubstringSearch #StringMatching #TextProcessing #Bioinformatics #DNA #PatternMatching #SearchTools
🟣لینک مقاله:
https://postgresweekly.com/link/176026/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
NoraSearch: Extension to Quickly Find Substring Match Offsets and Counts
🟢 خلاصه مقاله:
**نوراSearch افزونه‌ای سبک برای جست‌وجوی سریع و دقیق زیررشته‌هاست که فهرستی از جفت‌های {موقعیت شروع، طول تطابق} برمی‌گرداند. برای نمونه، جست‌وجوی 'abra' در 'abracadabra' به صورت {{0,4},{7,4}} گزارش می‌شود. نویسنده یکی از کارکردهای کلیدی آن را تحلیل توالی‌های DNA می‌داند؛ افزون بر آن، در متن‌کاوی، جست‌وجوی کد، پایش لاگ و ایندکس‌گذاری نیز هر جا به موقعیت‌ها و شمارش دقیق تطابق‌ها نیاز باشد، سودمند است.
#SubstringSearch #StringMatching #TextProcessing #Bioinformatics #DNA #PatternMatching #SearchTools
🟣لینک مقاله:
https://postgresweekly.com/link/176026/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
GitHub
GitHub - lemmerelassal/NoraSearch
Contribute to lemmerelassal/NoraSearch development by creating an account on GitHub.
وکتور دیتابیس‌ها (Vector Databases)
در دنیای امروز، با رشد مدل‌های زبانی بزرگ (LLMها) و اپلیکیشن‌های هوش مصنوعی، یک نیاز جدید در حوزه ذخیره‌سازی داده به‌وجود آمده که چیزی نیست جز درک معنا، نه فقط داده‌های خام.
اینجاست که وکتور دیتابیس‌ها (Vector Databases) وارد صحنه می‌شوند.
برخلاف دیتابیس‌های سنتی که داده‌ها را بر اساس کلید، متن یا ساختار ذخیره‌سازی می‌کنند، وکتور دیتابیس‌ها داده‌ها را به صورت بردارهای عددی چندبُعدی نگهداری می‌کنند. این بردارها در واقع نمایانگر معنا و مفهوم پشت داده‌ها هستند نه صرفاً کلمات یا مقادیر ظاهری.
کاربرد اصلی این نوع دیتابیس‌ها در سیستم‌هایی است که نیاز به جست‌وجوی معنایی (Semantic Search)، تطبیق شباهت (Similarity Matching) و حافظه بلندمدت برای LLMها دارند. به‌عنوان مثال، در یک چت‌بات هوشمند، وکتور دیتابیس کمک می‌کند تا سیستم مکالمات قبلی یا اطلاعات مشابه را بر اساس معنا بازیابی کند، نه فقط تطبیق واژه‌ها.
تفاوت اصلی با دیتابیس‌های سنتی
در دیتابیس‌های رابطه‌ای یا NoSQL، داده بر اساس کلیدها و تطبیق دقیق بازیابی می‌شود.
اما در وکتور دیتابیس، داده‌ها بر اساس درجه شباهت معنایی پیدا می‌شوند.
یعنی اگر کاربر بگوید:
"بهترین مکان برای مطالعه با قهوه خوب"
سیستم می‌تواند داده‌هایی مثل "کافه مناسب برای فریلنسرها" را هم به عنوان نتیجه مرتبط برگرداند.
️ نمونه‌های شناخته‌شده وکتور دیتابیس‌ها
ابزار Pinecone : سرویس ابری مخصوص ذخیره و جست‌وجوی برداری (ساده برای اتصال به LLMها)
ابزار Weaviate : متن‌باز و ماژولار، با قابلیت اضافه کردن embedding model داخلی
ابزار Milvus : یکی از قدرتمندترین پلتفرم‌های متن‌باز در مقیاس بالا (ساخته Zilliz)
ابزار Qdrant : دیتابیس برداری سریع و سبک با API دوستانه (مناسب پروژه‌های کوچک تا متوسط)
ابزار pgvector : افزونه PostgreSQL برای ذخیره و جست‌وجوی برداری (راه ساده برای پروژه‌های موجود)
به نظر می‌رسد وکتور دیتابیس‌ها به‌زودی به یکی از اجزای اصلی معماری نرم‌افزارها تبدیل خواهند شد چرا که استفاده از هوش مصنوعی در همه زمینه ها در حال پیشرفت است.
وکتور دیتابیس‌ها پلی هستند بین داده‌های ساخت‌یافته و درک انسانی.
فناوری‌ای که به سیستم‌ها کمک می‌کند “بفهمند”، نه فقط “ذخیره کنند”.
<Amir Rahimi Nejad/>
در دنیای امروز، با رشد مدل‌های زبانی بزرگ (LLMها) و اپلیکیشن‌های هوش مصنوعی، یک نیاز جدید در حوزه ذخیره‌سازی داده به‌وجود آمده که چیزی نیست جز درک معنا، نه فقط داده‌های خام.
اینجاست که وکتور دیتابیس‌ها (Vector Databases) وارد صحنه می‌شوند.
برخلاف دیتابیس‌های سنتی که داده‌ها را بر اساس کلید، متن یا ساختار ذخیره‌سازی می‌کنند، وکتور دیتابیس‌ها داده‌ها را به صورت بردارهای عددی چندبُعدی نگهداری می‌کنند. این بردارها در واقع نمایانگر معنا و مفهوم پشت داده‌ها هستند نه صرفاً کلمات یا مقادیر ظاهری.
کاربرد اصلی این نوع دیتابیس‌ها در سیستم‌هایی است که نیاز به جست‌وجوی معنایی (Semantic Search)، تطبیق شباهت (Similarity Matching) و حافظه بلندمدت برای LLMها دارند. به‌عنوان مثال، در یک چت‌بات هوشمند، وکتور دیتابیس کمک می‌کند تا سیستم مکالمات قبلی یا اطلاعات مشابه را بر اساس معنا بازیابی کند، نه فقط تطبیق واژه‌ها.
تفاوت اصلی با دیتابیس‌های سنتی
در دیتابیس‌های رابطه‌ای یا NoSQL، داده بر اساس کلیدها و تطبیق دقیق بازیابی می‌شود.
اما در وکتور دیتابیس، داده‌ها بر اساس درجه شباهت معنایی پیدا می‌شوند.
یعنی اگر کاربر بگوید:
"بهترین مکان برای مطالعه با قهوه خوب"
سیستم می‌تواند داده‌هایی مثل "کافه مناسب برای فریلنسرها" را هم به عنوان نتیجه مرتبط برگرداند.
️ نمونه‌های شناخته‌شده وکتور دیتابیس‌ها
ابزار Pinecone : سرویس ابری مخصوص ذخیره و جست‌وجوی برداری (ساده برای اتصال به LLMها)
ابزار Weaviate : متن‌باز و ماژولار، با قابلیت اضافه کردن embedding model داخلی
ابزار Milvus : یکی از قدرتمندترین پلتفرم‌های متن‌باز در مقیاس بالا (ساخته Zilliz)
ابزار Qdrant : دیتابیس برداری سریع و سبک با API دوستانه (مناسب پروژه‌های کوچک تا متوسط)
ابزار pgvector : افزونه PostgreSQL برای ذخیره و جست‌وجوی برداری (راه ساده برای پروژه‌های موجود)
به نظر می‌رسد وکتور دیتابیس‌ها به‌زودی به یکی از اجزای اصلی معماری نرم‌افزارها تبدیل خواهند شد چرا که استفاده از هوش مصنوعی در همه زمینه ها در حال پیشرفت است.
وکتور دیتابیس‌ها پلی هستند بین داده‌های ساخت‌یافته و درک انسانی.
فناوری‌ای که به سیستم‌ها کمک می‌کند “بفهمند”، نه فقط “ذخیره کنند”.
<Amir Rahimi Nejad/>
👍1
🔵 عنوان مقاله
PostgreSQL Event Calendar
🟢 خلاصه مقاله:
PostgreSQL Event Calendar یک سایت متمرکز برای رصد رویدادهای مرتبط با Postgres است و یک فایل ICS / iCalendar هم ارائه می‌دهد که می‌توانید به تقویم خود اضافه کنید تا رویدادها را بدون پیگیری دستی دنبال کنید. فهرست رویدادها تا PGDay Austria در سپتامبر 2026 ادامه دارد که امکان برنامه‌ریزی بلندمدت را برای علاقه‌مندان و اعضای جامعه Postgres فراهم می‌کند.
#PostgreSQL #Postgres #iCalendar #ICS #TechEvents #DatabaseCommunity #PGDayAustria #OpenSource
🟣لینک مقاله:
https://postgresweekly.com/link/176673/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
PostgreSQL Event Calendar
🟢 خلاصه مقاله:
PostgreSQL Event Calendar یک سایت متمرکز برای رصد رویدادهای مرتبط با Postgres است و یک فایل ICS / iCalendar هم ارائه می‌دهد که می‌توانید به تقویم خود اضافه کنید تا رویدادها را بدون پیگیری دستی دنبال کنید. فهرست رویدادها تا PGDay Austria در سپتامبر 2026 ادامه دارد که امکان برنامه‌ریزی بلندمدت را برای علاقه‌مندان و اعضای جامعه Postgres فراهم می‌کند.
#PostgreSQL #Postgres #iCalendar #ICS #TechEvents #DatabaseCommunity #PGDayAustria #OpenSource
🟣لینک مقاله:
https://postgresweekly.com/link/176673/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
🔵 عنوان مقاله
Transaction Pooling in Postgres with Pgcat
🟢 خلاصه مقاله:
این مرور سه موضوع مرتبط در عملیات Postgres را کنار هم می‌گذارد: مدیریت اتصال‌ها با Transaction Pooling از طریق Pgcat، سفر یک پرس‌وجوی SQL درون Postgres، و نقش «Dirty Pages» در کارایی و دوام. در Transaction Pooling، Pgcat اتصال‌های سمت سرور را فقط در طول تراکنش قرض می‌دهد و با افزایش استفاده مجدد از Backendها، هزینه اتصال‌های کوتاه‌عمر را کاهش می‌دهد—به‌ویژه در بارهای Serverless و Microservices. بهای آن، حساسیت به حالت‌های سطح نشست است؛ پس باید وضعیت را داخل تراکنش نگه داشت و به زمان‌بندی‌ها، اندازه Pool و مشاهده‌پذیری توجه کرد. «سفر» Phil Eaton نشان می‌دهد پرس‌وجو چگونه از Parse/Rewrite/Plan به Execution می‌رسد، با تکیه بر آمار و ایندکس‌ها، MVCC، قفل‌ها، Shared Buffers و WAL. توضیحات Jesús Espino و Umair Shahid درباره Dirty Pages می‌گوید صفحاتِ تغییرکرده در حافظه برای کارایی خوب‌اند، اما باید با Checkpoint، Background Writer و تنظیمات WAL مدیریت شوند تا از جهش‌های تاخیری جلوگیری شود. کنار هم، این سه دیدگاه کمک می‌کنند با تغذیه کارآمد اتصال‌ها، فهم مسیر اجرای پرس‌وجو و تنظیم مسیر نوشتن، Postgres را سریع‌تر و قابل‌پیش‌بینی‌تر اجرا کنید.
#Postgres #Pgcat #TransactionPooling #ConnectionPooling #SQL #DatabaseInternals #DirtyPages #WAL
🟣لینک مقاله:
https://postgresweekly.com/link/176685/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Transaction Pooling in Postgres with Pgcat
🟢 خلاصه مقاله:
این مرور سه موضوع مرتبط در عملیات Postgres را کنار هم می‌گذارد: مدیریت اتصال‌ها با Transaction Pooling از طریق Pgcat، سفر یک پرس‌وجوی SQL درون Postgres، و نقش «Dirty Pages» در کارایی و دوام. در Transaction Pooling، Pgcat اتصال‌های سمت سرور را فقط در طول تراکنش قرض می‌دهد و با افزایش استفاده مجدد از Backendها، هزینه اتصال‌های کوتاه‌عمر را کاهش می‌دهد—به‌ویژه در بارهای Serverless و Microservices. بهای آن، حساسیت به حالت‌های سطح نشست است؛ پس باید وضعیت را داخل تراکنش نگه داشت و به زمان‌بندی‌ها، اندازه Pool و مشاهده‌پذیری توجه کرد. «سفر» Phil Eaton نشان می‌دهد پرس‌وجو چگونه از Parse/Rewrite/Plan به Execution می‌رسد، با تکیه بر آمار و ایندکس‌ها، MVCC، قفل‌ها، Shared Buffers و WAL. توضیحات Jesús Espino و Umair Shahid درباره Dirty Pages می‌گوید صفحاتِ تغییرکرده در حافظه برای کارایی خوب‌اند، اما باید با Checkpoint، Background Writer و تنظیمات WAL مدیریت شوند تا از جهش‌های تاخیری جلوگیری شود. کنار هم، این سه دیدگاه کمک می‌کنند با تغذیه کارآمد اتصال‌ها، فهم مسیر اجرای پرس‌وجو و تنظیم مسیر نوشتن، Postgres را سریع‌تر و قابل‌پیش‌بینی‌تر اجرا کنید.
#Postgres #Pgcat #TransactionPooling #ConnectionPooling #SQL #DatabaseInternals #DirtyPages #WAL
🟣لینک مقاله:
https://postgresweekly.com/link/176685/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
EDB
Transaction pooling for Postgres with pgcat
Detailed guide on transaction pooling in Postgres using pgcat by Phil Eaton. Discusses pooling modes, connection poolers and their impact on database performance.
❤1
🔵 عنوان مقاله
PGSync 5.0: Postgres to ElasticSearch/OpenSearch Syncing
🟢 خلاصه مقاله:
PGSync 5.0 یک میان‌افزار برای همگام‌سازی داده‌های Postgres با ElasticSearch/OpenSearch است. این ابزار تغییرات دیتابیس را به‌صورت لحظه‌ای دریافت می‌کند و آن‌ها را به اسناد ساخت‌یافته JSON تبدیل کرده و در ایندکس‌های جست‌وجو می‌نویسد. هدف آن کاهش پیچیدگی ETL سفارشی، پایداری و تاخیر پایین در به‌روزرسانی ایندکس‌ها است. PGSync از الگوهایی مثل backfill اولیه، استریم تغییرات، denormalization، نگاشت انعطاف‌پذیر جدول‌به‌سند و upsertهای idempotent پشتیبانی می‌کند. در نسخه ۵ تمرکز بر کارایی، سادگی پیکربندی و سازگاری یکپارچه با ElasticSearch و OpenSearch است تا مسیر پایدار و سریعی از جدول‌های Postgres به اسناد قابل جست‌وجو فراهم شود.
#PGSync #Postgres #ElasticSearch #OpenSearch #CDC #SearchIndexing #DataSync #RealTime
🟣لینک مقاله:
https://postgresweekly.com/link/175730/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
PGSync 5.0: Postgres to ElasticSearch/OpenSearch Syncing
🟢 خلاصه مقاله:
PGSync 5.0 یک میان‌افزار برای همگام‌سازی داده‌های Postgres با ElasticSearch/OpenSearch است. این ابزار تغییرات دیتابیس را به‌صورت لحظه‌ای دریافت می‌کند و آن‌ها را به اسناد ساخت‌یافته JSON تبدیل کرده و در ایندکس‌های جست‌وجو می‌نویسد. هدف آن کاهش پیچیدگی ETL سفارشی، پایداری و تاخیر پایین در به‌روزرسانی ایندکس‌ها است. PGSync از الگوهایی مثل backfill اولیه، استریم تغییرات، denormalization، نگاشت انعطاف‌پذیر جدول‌به‌سند و upsertهای idempotent پشتیبانی می‌کند. در نسخه ۵ تمرکز بر کارایی، سادگی پیکربندی و سازگاری یکپارچه با ElasticSearch و OpenSearch است تا مسیر پایدار و سریعی از جدول‌های Postgres به اسناد قابل جست‌وجو فراهم شود.
#PGSync #Postgres #ElasticSearch #OpenSearch #CDC #SearchIndexing #DataSync #RealTime
🟣لینک مقاله:
https://postgresweekly.com/link/175730/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Pgsync
PGSync - PGSync
PGSync simplifies your data pipeline by integrating Postgres/MySQL/MariaDB into Elasticsearch/OpenSearch.
منطق پشت کلاستر این CockroachDB چقدر قشنگه.
نوعی دیتابیس SQL که به صورت Master Master کلاستر میشه و از پروتکل RAFT استفاده میکنه.
اما چی!؟ ، مگه RAFT ساختارش به صورت Master Slave ایی تعریف نمیشد؟ پس چجوری توی دیتابیس Master Master داره استفاده میشه؟
شاید اونجوری که CockroachDB میگه اصلا Master Master ایی در کار نیست یا تعریف ما متفاوته .
خلاصه اگه علاقه مند هستین چجوری توی CockroachDB ما RAFT داریم، خوشحال میشم مقاله ایی رو که نوشتم مطالعه کنین، حدودا هم ۵ دقیقه وقتتون رو میگیره.
https://medium.com/@parsagheiratian/the-mentality-behind-cockroachdb-0ed524fcc7ec
<Parsa Gheiratian/>
️️
نوعی دیتابیس SQL که به صورت Master Master کلاستر میشه و از پروتکل RAFT استفاده میکنه.
اما چی!؟ ، مگه RAFT ساختارش به صورت Master Slave ایی تعریف نمیشد؟ پس چجوری توی دیتابیس Master Master داره استفاده میشه؟
شاید اونجوری که CockroachDB میگه اصلا Master Master ایی در کار نیست یا تعریف ما متفاوته .
خلاصه اگه علاقه مند هستین چجوری توی CockroachDB ما RAFT داریم، خوشحال میشم مقاله ایی رو که نوشتم مطالعه کنین، حدودا هم ۵ دقیقه وقتتون رو میگیره.
https://medium.com/@parsagheiratian/the-mentality-behind-cockroachdb-0ed524fcc7ec
<Parsa Gheiratian/>
️️
Medium
The mentality behind CockroachDB
multi-active “master-master”, Raft, ranges, and how “master” really works
🔵 عنوان مقاله
The Art of Lean Governance: The Cybernetics of Data Quality (5 minute read)
🟢 خلاصه مقاله:
** این مقاله پیشنهاد می‌کند برای مدیریت کیفیت داده‌ها از رویکرد سایبرنتیک استفاده شود؛ یعنی اکوسیستم داده مانند یک سامانه خودتنظیم و یادگیرنده با حلقه‌های بازخورد، کنترل و بهبود مداوم دیده شود. عناصر کلیدی شامل موتورهای پویا برای آشتی‌دادن داده‌ها در لحظه، واژه‌نامه‌های کسب‌وکارِ تعبیه‌شده برای یکپارچگی معنایی، و تبارشناسی کامل داده‌ها جهت ردیابی علّی و حاکمیت قوی بر AI است. حاکمیت چابک با سیاست‌ها به‌صورت کد، دروازه‌های کیفیت در CI/CD، و اتوماسیون رویدادمحور اجرا می‌شود؛ مالکیت در تیم‌های دامنه است و گروه مرکزی فقط استانداردها و ابزار مشترک را فراهم می‌کند. با تعریف SLOهای کیفیت و اجرای چرخه کشف → تشخیص → اصلاح → راستی‌آزمایی → یادگیری، کنترل‌ها به‌صورت پیش‌دستانه و مقیاس‌پذیر اعمال می‌شوند و ریسک، هزینه و زمان رفع خطا کاهش می‌یابد.
#DataQuality #Cybernetics #DataGovernance #AIGovernance #DataLineage #Observability #LeanGovernance #MLOps
🟣لینک مقاله:
https://tdan.com/the-art-of-lean-governance-the-cybernetics-of-data-quality/33051?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
The Art of Lean Governance: The Cybernetics of Data Quality (5 minute read)
🟢 خلاصه مقاله:
** این مقاله پیشنهاد می‌کند برای مدیریت کیفیت داده‌ها از رویکرد سایبرنتیک استفاده شود؛ یعنی اکوسیستم داده مانند یک سامانه خودتنظیم و یادگیرنده با حلقه‌های بازخورد، کنترل و بهبود مداوم دیده شود. عناصر کلیدی شامل موتورهای پویا برای آشتی‌دادن داده‌ها در لحظه، واژه‌نامه‌های کسب‌وکارِ تعبیه‌شده برای یکپارچگی معنایی، و تبارشناسی کامل داده‌ها جهت ردیابی علّی و حاکمیت قوی بر AI است. حاکمیت چابک با سیاست‌ها به‌صورت کد، دروازه‌های کیفیت در CI/CD، و اتوماسیون رویدادمحور اجرا می‌شود؛ مالکیت در تیم‌های دامنه است و گروه مرکزی فقط استانداردها و ابزار مشترک را فراهم می‌کند. با تعریف SLOهای کیفیت و اجرای چرخه کشف → تشخیص → اصلاح → راستی‌آزمایی → یادگیری، کنترل‌ها به‌صورت پیش‌دستانه و مقیاس‌پذیر اعمال می‌شوند و ریسک، هزینه و زمان رفع خطا کاهش می‌یابد.
#DataQuality #Cybernetics #DataGovernance #AIGovernance #DataLineage #Observability #LeanGovernance #MLOps
🟣لینک مقاله:
https://tdan.com/the-art-of-lean-governance-the-cybernetics-of-data-quality/33051?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
TDAN.com
The Art of Lean Governance: The Cybernetics of Data Quality
In the age of algorithmic intelligence, data is no longer just an asset — it is a self-regulating system whose health determines the stability and success of modern enterprises. To manage data effectively today, leaders must think in cybernetic terms — as…
Forwarded from Gopher Job
A Data Structure Algorithms Low Level Design and High Level Design collection of resources.
مجموعه‌ای از منابع برای طراحی low level و high level توی مصاحبه‌های الگوریتمی و برنامه‌نویسی
#DSA #LLD #HLD #Algorithm #Interview #Leetcode #Question
https://github.com/arpit20adlakha/Data-Structure-Algorithms-LLD-HLD
مجموعه‌ای از منابع برای طراحی low level و high level توی مصاحبه‌های الگوریتمی و برنامه‌نویسی
#DSA #LLD #HLD #Algorithm #Interview #Leetcode #Question
https://github.com/arpit20adlakha/Data-Structure-Algorithms-LLD-HLD
GitHub
GitHub - arpit20adlakha/Data-Structure-Algorithms-LLD-HLD: A Data Structure Algorithms Low Level Design and High Level Design collection…
A Data Structure Algorithms Low Level Design and High Level Design collection of resources. - arpit20adlakha/Data-Structure-Algorithms-LLD-HLD
👍1
🔵 عنوان مقاله
PlanetScale for Postgres is Now GA
🟢 خلاصه مقاله:
PlanetScale اعلام کرد که PlanetScale for Postgres به مرحله GA رسیده و اکنون برای همه کاربران در دسترس است. این حرکت پس از آن انجام شد که شرکت در ماه جولای ورود خود به فضای PG را اعلام کرد و مجموعه‌ای از بنچمارک‌ها را منتشر نمود. این سرویس تا امروز در فاز private preview بود و اکنون برای استفاده در محیط‌های تولیدی آماده اعلام شده است. به این ترتیب، تیم‌هایی که بر Postgres تکیه دارند می‌توانند از پیشنهاد جدید PlanetScale استفاده کرده و آن را در مقیاس عملیاتی امتحان کنند.
#PlanetScale #Postgres #PG #Database #Cloud #GA #MySQL #DevOps
🟣لینک مقاله:
https://postgresweekly.com/link/174747/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
PlanetScale for Postgres is Now GA
🟢 خلاصه مقاله:
PlanetScale اعلام کرد که PlanetScale for Postgres به مرحله GA رسیده و اکنون برای همه کاربران در دسترس است. این حرکت پس از آن انجام شد که شرکت در ماه جولای ورود خود به فضای PG را اعلام کرد و مجموعه‌ای از بنچمارک‌ها را منتشر نمود. این سرویس تا امروز در فاز private preview بود و اکنون برای استفاده در محیط‌های تولیدی آماده اعلام شده است. به این ترتیب، تیم‌هایی که بر Postgres تکیه دارند می‌توانند از پیشنهاد جدید PlanetScale استفاده کرده و آن را در مقیاس عملیاتی امتحان کنند.
#PlanetScale #Postgres #PG #Database #Cloud #GA #MySQL #DevOps
🟣لینک مقاله:
https://postgresweekly.com/link/174747/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Planetscale
PlanetScale for Postgres is now GA — PlanetScale
PlanetScale for Postgres is now generally available.
🔵 عنوان مقاله
Building a Dev Experience for Postgres in VS Code
🟢 خلاصه مقاله:
مایکروسافت با حضور Rob Emanuele در پادکست Talking Postgres به میزبانی Claire Giordano درباره ساخت یک تجربه توسعه‌دهنده برای Postgres در VS Code صحبت می‌کند. محور گفتگو، افزونه تازهٔ «IDE for Postgres» است که اوایل امسال توسط Microsoft منتشر شد و هدفش آوردن کارهای روزمرهٔ پایگاه‌داده به دل محیط آشنای VS Code و کاهش جابه‌جایی بین ابزارهاست. در این قسمت به انگیزه‌ها، چالش‌های رایج برنامه‌نویسان، نقش بازخورد جامعه، و مسیر آیندهٔ ابزار پرداخته می‌شود تا نشان دهد این افزونه چگونه گردش‌کار نوشتن و آزمون SQL و مدیریت تغییرات را ساده‌تر می‌کند.
#Postgres #VSCode #Microsoft #DeveloperExperience #TalkingPostgres #IDE #DatabaseTools #VSCodeExtension
🟣لینک مقاله:
https://postgresweekly.com/link/176991/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Building a Dev Experience for Postgres in VS Code
🟢 خلاصه مقاله:
مایکروسافت با حضور Rob Emanuele در پادکست Talking Postgres به میزبانی Claire Giordano درباره ساخت یک تجربه توسعه‌دهنده برای Postgres در VS Code صحبت می‌کند. محور گفتگو، افزونه تازهٔ «IDE for Postgres» است که اوایل امسال توسط Microsoft منتشر شد و هدفش آوردن کارهای روزمرهٔ پایگاه‌داده به دل محیط آشنای VS Code و کاهش جابه‌جایی بین ابزارهاست. در این قسمت به انگیزه‌ها، چالش‌های رایج برنامه‌نویسان، نقش بازخورد جامعه، و مسیر آیندهٔ ابزار پرداخته می‌شود تا نشان دهد این افزونه چگونه گردش‌کار نوشتن و آزمون SQL و مدیریت تغییرات را ساده‌تر می‌کند.
#Postgres #VSCode #Microsoft #DeveloperExperience #TalkingPostgres #IDE #DatabaseTools #VSCodeExtension
🟣لینک مقاله:
https://postgresweekly.com/link/176991/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Talking Postgres with Claire Giordano
Talking Postgres with Claire Giordano | Building a dev experience for Postgres in VS Code with Rob Emanuele
What do guitar busking, geospatial queries, and agentic coding have to do with Postgres? In Episode 33 of Talking Postgres, principal engineer Rob Emanuele at Microsoft shares his winding path from...
🔵 عنوان مقاله
Why You Should Prefer MERGE INTO Over INSERT OVERWRITE in Apache Iceberg (7 minute read)
🟢 خلاصه مقاله:
MERGE INTO همراه با استراتژی Merge-on-Read (MOR) در Apache Iceberg برای به‌روزرسانی داده‌ها معمولاً بهتر از INSERT OVERWRITE است، زیرا به‌جای بازنویسی پارتیشن‌ها، تغییرات را به‌صورت دلتا در سطح فایل اضافه می‌کند؛ نتیجه این کار کاهش I/O، زمان اجرای کوتاه‌تر و صرفه‌جویی در هزینه ذخیره‌سازی است. در مقابل، INSERT OVERWRITE با هر تغییر کوچک مجبور به بازنویسی کامل پارتیشن می‌شود و در مواجهه با Partition Evolution آسیب‌پذیرتر است. رویکرد MOR با تکیه بر تکامل پارتیشن مبتنی بر متادیتا، بدون بازنویسی داده‌های تاریخی، با الگوهای افزایشی مثل CDC و رویدادهای دیررس سازگار است. نقطه ضعف MOR نیاز به فشرده‌سازی و خانه‌تکانی دوره‌ای و اندکی سربار در خواندن برای اعمال دلتاهاست؛ با این حال، برای اغلب بارهای کاری افزایشی، انتخاب پیش‌فرض بهتر MERGE INTO (MOR) است و INSERT OVERWRITE فقط زمانی توصیه می‌شود که قصد بازسازی کامل یا اصلاح گسترده و مشخص داده را دارید.
#ApacheIceberg #MERGEINTO #MergeOnRead #DataEngineering #DataLakehouse #PartitionEvolution #BigData #ETL
🟣لینک مقاله:
https://medium.com/expedia-group-tech/why-you-should-prefer-merge-into-over-insert-overwrite-in-apache-iceberg-b6b130cc27d2?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Why You Should Prefer MERGE INTO Over INSERT OVERWRITE in Apache Iceberg (7 minute read)
🟢 خلاصه مقاله:
MERGE INTO همراه با استراتژی Merge-on-Read (MOR) در Apache Iceberg برای به‌روزرسانی داده‌ها معمولاً بهتر از INSERT OVERWRITE است، زیرا به‌جای بازنویسی پارتیشن‌ها، تغییرات را به‌صورت دلتا در سطح فایل اضافه می‌کند؛ نتیجه این کار کاهش I/O، زمان اجرای کوتاه‌تر و صرفه‌جویی در هزینه ذخیره‌سازی است. در مقابل، INSERT OVERWRITE با هر تغییر کوچک مجبور به بازنویسی کامل پارتیشن می‌شود و در مواجهه با Partition Evolution آسیب‌پذیرتر است. رویکرد MOR با تکیه بر تکامل پارتیشن مبتنی بر متادیتا، بدون بازنویسی داده‌های تاریخی، با الگوهای افزایشی مثل CDC و رویدادهای دیررس سازگار است. نقطه ضعف MOR نیاز به فشرده‌سازی و خانه‌تکانی دوره‌ای و اندکی سربار در خواندن برای اعمال دلتاهاست؛ با این حال، برای اغلب بارهای کاری افزایشی، انتخاب پیش‌فرض بهتر MERGE INTO (MOR) است و INSERT OVERWRITE فقط زمانی توصیه می‌شود که قصد بازسازی کامل یا اصلاح گسترده و مشخص داده را دارید.
#ApacheIceberg #MERGEINTO #MergeOnRead #DataEngineering #DataLakehouse #PartitionEvolution #BigData #ETL
🟣لینک مقاله:
https://medium.com/expedia-group-tech/why-you-should-prefer-merge-into-over-insert-overwrite-in-apache-iceberg-b6b130cc27d2?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Medium
Why You Should Prefer MERGE INTO Over INSERT OVERWRITE in Apache Iceberg
Stop overwriting —start merging: a smarter approach to updating Iceberg tables
🔵 عنوان مقاله
All You Can Do Before Airflow (5 minute read)
🟢 خلاصه مقاله:
ساده‌ترین روش ارکستریشن را شروع کنید و فقط وقتی رشد واقعی پیچیدگی آن را توجیه کرد به Airflow مهاجرت کنید. برای بسیاری از نیازها، ترکیبی از cron، اسکریپت‌های Bash یا Python، یک Makefile، کانتینرسازی با Docker Compose و زمان‌بندی‌های مدیریت‌شده مثل Cloud Scheduler یا EventBridge به‌همراه logging، retry و alert کفایت می‌کند. نشانه‌های نیاز به Airflow زمانی ظاهر می‌شوند که وابستگی‌ها و DAGها پیچیده می‌شوند، backfill و SLA اهمیت پیدا می‌کند، مالکیت بین تیم‌ها توزیع می‌شود و به observability، lineage، RBAC و مدیریت secrets نیاز دارید. قبل از مهاجرت، کارها را idempotent و کوچک کنید، state را در دیتابیس/شیء‌استور نگه دارید، تنظیمات را در کد مدیریت کنید، تست و مستندسازی و پایش را جدی بگیرید. قاعده تصمیم این است: ساده‌ترین ابزار کافی امروز را انتخاب کنید و فقط وقتی درد واقعی تجربه کردید به Airflow ارتقا دهید.
#DataOrchestration #ApacheAirflow #DataPipelines #ETL #DataEngineering #Scalability #CronJobs #Observability
🟣لینک مقاله:
https://dataengineeringcentral.substack.com/p/all-you-can-do-before-airflow?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
All You Can Do Before Airflow (5 minute read)
🟢 خلاصه مقاله:
ساده‌ترین روش ارکستریشن را شروع کنید و فقط وقتی رشد واقعی پیچیدگی آن را توجیه کرد به Airflow مهاجرت کنید. برای بسیاری از نیازها، ترکیبی از cron، اسکریپت‌های Bash یا Python، یک Makefile، کانتینرسازی با Docker Compose و زمان‌بندی‌های مدیریت‌شده مثل Cloud Scheduler یا EventBridge به‌همراه logging، retry و alert کفایت می‌کند. نشانه‌های نیاز به Airflow زمانی ظاهر می‌شوند که وابستگی‌ها و DAGها پیچیده می‌شوند، backfill و SLA اهمیت پیدا می‌کند، مالکیت بین تیم‌ها توزیع می‌شود و به observability، lineage، RBAC و مدیریت secrets نیاز دارید. قبل از مهاجرت، کارها را idempotent و کوچک کنید، state را در دیتابیس/شیء‌استور نگه دارید، تنظیمات را در کد مدیریت کنید، تست و مستندسازی و پایش را جدی بگیرید. قاعده تصمیم این است: ساده‌ترین ابزار کافی امروز را انتخاب کنید و فقط وقتی درد واقعی تجربه کردید به Airflow ارتقا دهید.
#DataOrchestration #ApacheAirflow #DataPipelines #ETL #DataEngineering #Scalability #CronJobs #Observability
🟣لینک مقاله:
https://dataengineeringcentral.substack.com/p/all-you-can-do-before-airflow?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Substack
All You Can Do Before Airflow:
4 Orchestration Levels From Cron to Full Pipelines
🔵 عنوان مقاله
How to Listen to Database Changes Through the WAL
🟢 خلاصه مقاله:
شنیدن تغییرات دیتابیس از طریق WAL در Postgres یک روش پایدار برای CDC است که بدون تریگر و پولینگ اضافه، رویدادهای INSERT/UPDATE/DELETE را با ترتیب مبتنی بر LSN و قابلیت بازیابی استریم می‌کند. راه‌اندازی شامل wal_level=logical، ساخت replication slot، انتخاب output plugin مثل pgoutput یا wal2json، گرفتن snapshot اولیه و ذخیره LSN برای پیشرفت مصرف‌کننده است. از منظر عملیاتی باید نگهداری WAL توسط replication slot، backpressure، تراکنش‌های بزرگ، تغییرات schema، و مدیریت failover و امنیت را پایش کنید و با طراحی آیدمپوتنت در مقصد، تحویل at-least-once را کنترل کنید. در مطالب مرتبط، Peter Ullrich به transaction pooling با Pgcat و قیود آن می‌پردازد، Phil Eaton سفر یک کوئری SQL را در Postgres از parse تا execution روایت می‌کند، و Umair Shahid مفهوم Dirty Pages، نقش background writer/checkpointer و اثر تنظیمات بر پایداری I/O را توضیح می‌دهد.
#Postgres #WAL #ChangeDataCapture #LogicalDecoding #Pgcat #SQL #DirtyPages #DatabaseInternals
🟣لینک مقاله:
https://postgresweekly.com/link/176684/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
How to Listen to Database Changes Through the WAL
🟢 خلاصه مقاله:
شنیدن تغییرات دیتابیس از طریق WAL در Postgres یک روش پایدار برای CDC است که بدون تریگر و پولینگ اضافه، رویدادهای INSERT/UPDATE/DELETE را با ترتیب مبتنی بر LSN و قابلیت بازیابی استریم می‌کند. راه‌اندازی شامل wal_level=logical، ساخت replication slot، انتخاب output plugin مثل pgoutput یا wal2json، گرفتن snapshot اولیه و ذخیره LSN برای پیشرفت مصرف‌کننده است. از منظر عملیاتی باید نگهداری WAL توسط replication slot، backpressure، تراکنش‌های بزرگ، تغییرات schema، و مدیریت failover و امنیت را پایش کنید و با طراحی آیدمپوتنت در مقصد، تحویل at-least-once را کنترل کنید. در مطالب مرتبط، Peter Ullrich به transaction pooling با Pgcat و قیود آن می‌پردازد، Phil Eaton سفر یک کوئری SQL را در Postgres از parse تا execution روایت می‌کند، و Umair Shahid مفهوم Dirty Pages، نقش background writer/checkpointer و اثر تنظیمات بر پایداری I/O را توضیح می‌دهد.
#Postgres #WAL #ChangeDataCapture #LogicalDecoding #Pgcat #SQL #DirtyPages #DatabaseInternals
🟣لینک مقاله:
https://postgresweekly.com/link/176684/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Peterullrich
Listen to Database Changes through the Postgres WAL
An in-depth guide to listening to Postgres database changes through the WAL. Covers logical replication, publications, replication slots, and an Elixir implementation.
Forwarded from Linux Labdon
کاهش هزینه سیستم‌های هوش مصنوعی با Semantic Caching
با رشد مدل‌های زبانی بزرگ و پیشرفته، هزینه و زمان پاسخ‌دهی هم به شدت افزایش پیدا کرده. مدل‌هایی مثل GPT-5 یا Claude برای کارهای پیچیده فوق‌العاده‌اند، ولی استفاده از اون‌ها هم پرهزینه و هم کند محسوب میشه. از طرف دیگه، AI Agentها واقعاً «توکن‌خور» هستن؛ یعنی برای انجام یک کار معمولاً چندین مرحله طی می‌کنن: تحقیق، برنامه‌ریزی، عمل و بازتاب و تکرار. همین باعث میشه چندین بار با مدل تماس بگیرن و در نتیجه هزینه و تأخیر افزایش پیدا کنه و متن‌های طولانی‌تر تولید بشه. برای مثال، یه بنچمارک اخیر از TheAgentCompany در ۲۰۲۵ نشون داده اجرای کامل یک Agent گاهی تا ۶.۸ دلار هزینه داره.
یکی از مشکلات اصلی در دنیای واقعی، تکراری بودن سوال‌هاست، مخصوصاً توی پشتیبانی مشتری. کاربران دائماً سوال‌های مشابهی می‌پرسن: مثل «چطور پولم رو پس بگیرم؟» یا «شرایط بازگشت وجه چیه؟» و Agent مجبور میشه هر بار پاسخ رو از صفر تولید کنه. نتیجه‌ش افزایش هزینه، طولانی شدن زمان پاسخ و فشار بیشتر روی سیستم‌های RAG و زیرساخت‌هاست.
در نگاه اول، ممکنه فکر کنیم کش کلاسیک کفایت میکنه. ایده‌ی کش ساده اینه که اگر یک سوال قبلاً پاسخ داده شده، دوباره سراغ مدل نریم. ولی مشکل اینجاست که کش سنتی دنبال Exact Match یا تطابق دقیق متنه. سوال‌هایی که از نظر معنی یکی هستن ولی عبارت‌هاشون فرق میکنه، مثل: «می‌خوام پولم رو پس بگیرم»، «چطور می‌تونم درخواست بازگشت وجه بدم؟» و «سیاست بازگشت پولتون چیه؟»، همه Cache Miss می‌شن و کش عملاً استفاده نمی‌شه.
اینجاست که Semantic Caching وارد میشه. به جای تطابق کلمه‌به‌کلمه، کش به معنی و مفهوم جمله نگاه میکنه. مزیت اصلی‌ش اینه که Recall و Hit Rate بالاتره و احتمال استفاده از کش و صرفه‌جویی خیلی بیشتر میشه. البته چالشش هم اینه که گاهی ممکنه جواب بی‌ربط بده یا همون «False Positive» رخ بده.
روش کار Semantic Caching ساده است ولی هوشمندانه: ابتدا سوال کاربر به Embedding یا بردار عددی تبدیل میشه. بعد با بردارهای موجود در کش با Semantic Search مقایسه میشه. اگر فاصله معنایی کم باشه، پاسخ از کش برگردونده میشه؛ در غیر این صورت به RAG یا LLM می‌ریم. در نهایت سوال و پاسخ جدید هم ذخیره میشه تا دفعه بعدی قابل استفاده باشه.
پیاده‌سازی Semantic Caching با چالش‌هایی همراهه؛ مثل دقت (Accuracy) که آیا کش جواب درست می‌ده، کارایی (Performance) و میزان Cache Hit، سرعت سرویس‌دهی، آپدیت‌پذیری کش و اینکه آیا می‌تونیم کش رو گرم، تازه‌سازی یا پاکسازی کنیم. همچنین مشاهده‌پذیری (Observability) مهمه تا بتونیم hit rate، latency، صرفه‌جویی هزینه و کیفیت کش رو بسنجیم.
معیارهای اصلی سنجش کش شامل Cache Hit Rate هست که نشون می‌ده چند درصد درخواست‌ها از کش پاسخ داده می‌شن و Precision/Recall/F1 Score که کیفیت و دقت پاسخ‌ها رو مشخص میکنه. برای بهبود دقت و کارایی کش هم می‌تونیم Threshold فاصله رو تنظیم کنیم، Reranker اضافه کنیم مثل Cross-encoder یا LLM-as-a-judge، از Fuzzy Matching برای تایپوها استفاده کنیم و فیلترهای اضافی مثل تشخیص پرسش‌های زمان‌محور (Temporal) یا تشخیص کد (Python، Java و…) اعمال کنیم تا سوالات اشتباه وارد کش نشن.
یه مثال واقعی از این تکنولوژی پروژه waLLMartCache در Walmart هست. اون‌ها با نوآوری‌هایی مثل Load Balancer برای توزیع کش روی چند Node و Dual-tiered Storage که L1 = Vector DB و L2 = In-memory Cache مثل Redis هست، هم سرعت و هم دقت رو بالا بردن. Multi-tenancy هم باعث شده چند تیم یا اپلیکیشن از یک زیرساخت مشترک استفاده کنن. Decision Engine هم شامل تشخیص کد و زمانه و اگر سوال مناسب کش نباشه مستقیماً به LLM یا RAG می‌ره. نتیجه‌ش رسیدن به دقت نزدیک ۹۰٪ بوده.
<Reza Jafari/>
👉 https://t.iss.one/addlist/AJ7rh2IzIh02NTI0
با رشد مدل‌های زبانی بزرگ و پیشرفته، هزینه و زمان پاسخ‌دهی هم به شدت افزایش پیدا کرده. مدل‌هایی مثل GPT-5 یا Claude برای کارهای پیچیده فوق‌العاده‌اند، ولی استفاده از اون‌ها هم پرهزینه و هم کند محسوب میشه. از طرف دیگه، AI Agentها واقعاً «توکن‌خور» هستن؛ یعنی برای انجام یک کار معمولاً چندین مرحله طی می‌کنن: تحقیق، برنامه‌ریزی، عمل و بازتاب و تکرار. همین باعث میشه چندین بار با مدل تماس بگیرن و در نتیجه هزینه و تأخیر افزایش پیدا کنه و متن‌های طولانی‌تر تولید بشه. برای مثال، یه بنچمارک اخیر از TheAgentCompany در ۲۰۲۵ نشون داده اجرای کامل یک Agent گاهی تا ۶.۸ دلار هزینه داره.
یکی از مشکلات اصلی در دنیای واقعی، تکراری بودن سوال‌هاست، مخصوصاً توی پشتیبانی مشتری. کاربران دائماً سوال‌های مشابهی می‌پرسن: مثل «چطور پولم رو پس بگیرم؟» یا «شرایط بازگشت وجه چیه؟» و Agent مجبور میشه هر بار پاسخ رو از صفر تولید کنه. نتیجه‌ش افزایش هزینه، طولانی شدن زمان پاسخ و فشار بیشتر روی سیستم‌های RAG و زیرساخت‌هاست.
در نگاه اول، ممکنه فکر کنیم کش کلاسیک کفایت میکنه. ایده‌ی کش ساده اینه که اگر یک سوال قبلاً پاسخ داده شده، دوباره سراغ مدل نریم. ولی مشکل اینجاست که کش سنتی دنبال Exact Match یا تطابق دقیق متنه. سوال‌هایی که از نظر معنی یکی هستن ولی عبارت‌هاشون فرق میکنه، مثل: «می‌خوام پولم رو پس بگیرم»، «چطور می‌تونم درخواست بازگشت وجه بدم؟» و «سیاست بازگشت پولتون چیه؟»، همه Cache Miss می‌شن و کش عملاً استفاده نمی‌شه.
اینجاست که Semantic Caching وارد میشه. به جای تطابق کلمه‌به‌کلمه، کش به معنی و مفهوم جمله نگاه میکنه. مزیت اصلی‌ش اینه که Recall و Hit Rate بالاتره و احتمال استفاده از کش و صرفه‌جویی خیلی بیشتر میشه. البته چالشش هم اینه که گاهی ممکنه جواب بی‌ربط بده یا همون «False Positive» رخ بده.
روش کار Semantic Caching ساده است ولی هوشمندانه: ابتدا سوال کاربر به Embedding یا بردار عددی تبدیل میشه. بعد با بردارهای موجود در کش با Semantic Search مقایسه میشه. اگر فاصله معنایی کم باشه، پاسخ از کش برگردونده میشه؛ در غیر این صورت به RAG یا LLM می‌ریم. در نهایت سوال و پاسخ جدید هم ذخیره میشه تا دفعه بعدی قابل استفاده باشه.
پیاده‌سازی Semantic Caching با چالش‌هایی همراهه؛ مثل دقت (Accuracy) که آیا کش جواب درست می‌ده، کارایی (Performance) و میزان Cache Hit، سرعت سرویس‌دهی، آپدیت‌پذیری کش و اینکه آیا می‌تونیم کش رو گرم، تازه‌سازی یا پاکسازی کنیم. همچنین مشاهده‌پذیری (Observability) مهمه تا بتونیم hit rate، latency، صرفه‌جویی هزینه و کیفیت کش رو بسنجیم.
معیارهای اصلی سنجش کش شامل Cache Hit Rate هست که نشون می‌ده چند درصد درخواست‌ها از کش پاسخ داده می‌شن و Precision/Recall/F1 Score که کیفیت و دقت پاسخ‌ها رو مشخص میکنه. برای بهبود دقت و کارایی کش هم می‌تونیم Threshold فاصله رو تنظیم کنیم، Reranker اضافه کنیم مثل Cross-encoder یا LLM-as-a-judge، از Fuzzy Matching برای تایپوها استفاده کنیم و فیلترهای اضافی مثل تشخیص پرسش‌های زمان‌محور (Temporal) یا تشخیص کد (Python، Java و…) اعمال کنیم تا سوالات اشتباه وارد کش نشن.
یه مثال واقعی از این تکنولوژی پروژه waLLMartCache در Walmart هست. اون‌ها با نوآوری‌هایی مثل Load Balancer برای توزیع کش روی چند Node و Dual-tiered Storage که L1 = Vector DB و L2 = In-memory Cache مثل Redis هست، هم سرعت و هم دقت رو بالا بردن. Multi-tenancy هم باعث شده چند تیم یا اپلیکیشن از یک زیرساخت مشترک استفاده کنن. Decision Engine هم شامل تشخیص کد و زمانه و اگر سوال مناسب کش نباشه مستقیماً به LLM یا RAG می‌ره. نتیجه‌ش رسیدن به دقت نزدیک ۹۰٪ بوده.
<Reza Jafari/>
👉 https://t.iss.one/addlist/AJ7rh2IzIh02NTI0
❤1
🔵 عنوان مقاله
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...
🔵 عنوان مقاله
be careful when you do minor version upgrades
🟢 خلاصه مقاله:
** ارتقای نسخه‌های به‌ظاهر «جزئی» می‌تواند در سیستم‌های مبتنی بر Debian پیامدهای بزرگی داشته باشد. به‌روزرسانی نقطه‌ای Debian ممکن است کتابخانه‌های مرتبط با locale و collation را تغییر دهد و پایگاه داده شما را به به‌روزرسانی collation وادار کند؛ نتیجه می‌تواند بازسازی نمایه‌ها، تغییر ترتیب مرتب‌سازی متن، افت کارایی و حتی اختلال در سرویس باشد. این وضعیت معمولاً با apt upgrade یا unattended-upgrades و همچنین تصاویر کانتینری با برچسب‌های غیرثابت رخ می‌دهد. برای کاهش ریسک، همان نسخه را در staging تست کنید، بسته‌ها را pin/hold کنید، یادداشت‌های انتشار Debian و پایگاه داده را بخوانید، پنجره نگهداری در نظر بگیرید، پشتیبان مطمئن بگیرید و قبل/بعد از ارتقا وضعیت collation را بررسی کنید. «ارتقای جزئی» را نیز مانند ارتقای عمده جدی بگیرید تا از تغییر ناخواسته collation جلوگیری شود.
#Debian #Database #Collation #PostgreSQL #MySQL #Apt #Upgrade #DevOps
🟣لینک مقاله:
https://postgresweekly.com/link/177311/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
be careful when you do minor version upgrades
🟢 خلاصه مقاله:
** ارتقای نسخه‌های به‌ظاهر «جزئی» می‌تواند در سیستم‌های مبتنی بر Debian پیامدهای بزرگی داشته باشد. به‌روزرسانی نقطه‌ای Debian ممکن است کتابخانه‌های مرتبط با locale و collation را تغییر دهد و پایگاه داده شما را به به‌روزرسانی collation وادار کند؛ نتیجه می‌تواند بازسازی نمایه‌ها، تغییر ترتیب مرتب‌سازی متن، افت کارایی و حتی اختلال در سرویس باشد. این وضعیت معمولاً با apt upgrade یا unattended-upgrades و همچنین تصاویر کانتینری با برچسب‌های غیرثابت رخ می‌دهد. برای کاهش ریسک، همان نسخه را در staging تست کنید، بسته‌ها را pin/hold کنید، یادداشت‌های انتشار Debian و پایگاه داده را بخوانید، پنجره نگهداری در نظر بگیرید، پشتیبان مطمئن بگیرید و قبل/بعد از ارتقا وضعیت collation را بررسی کنید. «ارتقای جزئی» را نیز مانند ارتقای عمده جدی بگیرید تا از تغییر ناخواسته collation جلوگیری شود.
#Debian #Database #Collation #PostgreSQL #MySQL #Apt #Upgrade #DevOps
🟣لینک مقاله:
https://postgresweekly.com/link/177311/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Reddit
From the PostgreSQL community on Reddit: Docker's official Postgres image is shipping breaking changes in minor upgrades
Explore this post and more from the PostgreSQL community