🔵 عنوان مقاله
Tuning Asynchronous I/O (AIO) in Postgres 18
🟢 خلاصه مقاله:
در Postgres 18 قابلیت AIO اضافه شده که امکان ارسال همزمان عملیات خواندن/نوشتن بدون بلوکهکردن پردازشها را میدهد. نتیجهاش استفاده بهتر از CPU، افزایش توان عبوری و کاهش لگهای انتهای توزیع، بهویژه روی SSD/NVMe است. برای تیونینگ، از مقدارهای پیشفرض شروع کنید و با اندازهگیری دقیق جلو بروید؛ عمق صف مهمترین اهرم است: عمق کم پهناباند را هدر میدهد و عمق زیاد تاخیر را بالا میبرد. اندازهی دستههای ارسال، shared_buffers، و ریتم نوشتنهای WAL/چکپوینت باید با نوع کار (OLTP در برابر تحلیلمحور) و نوع دیسک تنظیم شوند. با pg_stat_io و رویدادهای انتظار در Postgres و ابزارهای سیستمعاملی مثل iostat، perf و pidstat پ99 تاخیر، صفها و استفادهی دیسک/CPU را پایش کنید. تفاوتهای پلتفرمی مهماند: روی Linux با io_uring، فایلسیستمها (XFS/ext4/ZFS) و دیسکهای ابری/شبکهای رفتار متفاوتی دارند؛ HDD به عمق صف محافظهکارانهتر نیاز دارد و NVMe از عمق بیشتر سود میبرد. در تمام مراحل، دوام (fsync، synchronous_commit) را با تست خرابی و بازیابی راستیآزمایی کنید. رویکرد مرحلهای—بالقوه با pgbench—و تنظیم تدریجی عمق صف و پارامترهای نوشتن، معمولاً بهترین کارایی پایدار را بههمراه میآورد.
#Postgres #AIO #DatabasePerformance #io_uring #WAL #NVMe #Linux #Postgres18
🟣لینک مقاله:
https://postgresweekly.com/link/174756/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Tuning Asynchronous I/O (AIO) in Postgres 18
🟢 خلاصه مقاله:
در Postgres 18 قابلیت AIO اضافه شده که امکان ارسال همزمان عملیات خواندن/نوشتن بدون بلوکهکردن پردازشها را میدهد. نتیجهاش استفاده بهتر از CPU، افزایش توان عبوری و کاهش لگهای انتهای توزیع، بهویژه روی SSD/NVMe است. برای تیونینگ، از مقدارهای پیشفرض شروع کنید و با اندازهگیری دقیق جلو بروید؛ عمق صف مهمترین اهرم است: عمق کم پهناباند را هدر میدهد و عمق زیاد تاخیر را بالا میبرد. اندازهی دستههای ارسال، shared_buffers، و ریتم نوشتنهای WAL/چکپوینت باید با نوع کار (OLTP در برابر تحلیلمحور) و نوع دیسک تنظیم شوند. با pg_stat_io و رویدادهای انتظار در Postgres و ابزارهای سیستمعاملی مثل iostat، perf و pidstat پ99 تاخیر، صفها و استفادهی دیسک/CPU را پایش کنید. تفاوتهای پلتفرمی مهماند: روی Linux با io_uring، فایلسیستمها (XFS/ext4/ZFS) و دیسکهای ابری/شبکهای رفتار متفاوتی دارند؛ HDD به عمق صف محافظهکارانهتر نیاز دارد و NVMe از عمق بیشتر سود میبرد. در تمام مراحل، دوام (fsync، synchronous_commit) را با تست خرابی و بازیابی راستیآزمایی کنید. رویکرد مرحلهای—بالقوه با pgbench—و تنظیم تدریجی عمق صف و پارامترهای نوشتن، معمولاً بهترین کارایی پایدار را بههمراه میآورد.
#Postgres #AIO #DatabasePerformance #io_uring #WAL #NVMe #Linux #Postgres18
🟣لینک مقاله:
https://postgresweekly.com/link/174756/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Tomas Vondra
Tuning AIO in PostgreSQL 18
One of the significant improvements in PG18 is AIO. What are some basic tuning recommendations?
🔵 عنوان مقاله
How to Implement the Outbox Pattern in Go and Postgres
🟢 خلاصه مقاله:
** الگوی Outbox روشی عملی برای حذف مشکل دونوشتن و تضمین تحویل مطمئن پیامهاست. در این روش، تغییرات دامنه و یک رکورد رویداد در جدول outbox داخل همان تراکنش Postgres ذخیره میشوند؛ سپس یک پردازشگر در Go رویدادها را از جدول خوانده و به پیامرسانهایی مانند Kafka یا RabbitMQ منتشر میکند. با استفاده از فیلدهایی مانند ID، کلید موجودیت، نوع رویداد، payload به صورت JSONB، وضعیت/تعداد تلاش، و زمانها، همگامی داده و پیام تضمین میشود. پردازشگر با انتخاب دستههای کوچک و بهکارگیری SELECT … FOR UPDATE SKIP LOCKED از رقابت جلوگیری کرده، پس از انتشار وضعیت را به «پردازششده» تغییر میدهد و شکستها را با backoff و صف خطا مدیریت میکند. این الگو تحویل حداقل-یکبار را فراهم میکند و با مصرفکنندههای idempotent میتوان به پردازش مؤثرِ یکباره رسید. برای کارایی بهتر، ایندکسگذاری بر status و created_at، پارتیشنبندی جدول، حفظ ترتیب بر اساس کلید موجودیت و نظارت بر عمق صف و تأخیر انتشار توصیه میشود. بهعنوان جایگزین، CDC با منبعخوانی منطقی Postgres (مثلاً Debezium) میتواند بهجای polling استفاده شود، هرچند پیچیدگی عملیاتی بیشتری دارد. با آزمونهای یکپارچه، مدیریت مهاجرتهای شِما و پاکسازی دادههای پردازششده، پیادهسازی در Go و Postgres به پلی پایدار بین پایگاهداده و سامانه پیامرسان تبدیل میشود؛ همان رویکردی که Alex Pliutau در معرفی پیادهسازی Outbox با Go و Postgres بر آن تأکید دارد.
#OutboxPattern #Go #Postgres #Microservices #EventDriven #TransactionalOutbox #Reliability #Messaging
🟣لینک مقاله:
https://postgresweekly.com/link/174464/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
How to Implement the Outbox Pattern in Go and Postgres
🟢 خلاصه مقاله:
** الگوی Outbox روشی عملی برای حذف مشکل دونوشتن و تضمین تحویل مطمئن پیامهاست. در این روش، تغییرات دامنه و یک رکورد رویداد در جدول outbox داخل همان تراکنش Postgres ذخیره میشوند؛ سپس یک پردازشگر در Go رویدادها را از جدول خوانده و به پیامرسانهایی مانند Kafka یا RabbitMQ منتشر میکند. با استفاده از فیلدهایی مانند ID، کلید موجودیت، نوع رویداد، payload به صورت JSONB، وضعیت/تعداد تلاش، و زمانها، همگامی داده و پیام تضمین میشود. پردازشگر با انتخاب دستههای کوچک و بهکارگیری SELECT … FOR UPDATE SKIP LOCKED از رقابت جلوگیری کرده، پس از انتشار وضعیت را به «پردازششده» تغییر میدهد و شکستها را با backoff و صف خطا مدیریت میکند. این الگو تحویل حداقل-یکبار را فراهم میکند و با مصرفکنندههای idempotent میتوان به پردازش مؤثرِ یکباره رسید. برای کارایی بهتر، ایندکسگذاری بر status و created_at، پارتیشنبندی جدول، حفظ ترتیب بر اساس کلید موجودیت و نظارت بر عمق صف و تأخیر انتشار توصیه میشود. بهعنوان جایگزین، CDC با منبعخوانی منطقی Postgres (مثلاً Debezium) میتواند بهجای polling استفاده شود، هرچند پیچیدگی عملیاتی بیشتری دارد. با آزمونهای یکپارچه، مدیریت مهاجرتهای شِما و پاکسازی دادههای پردازششده، پیادهسازی در Go و Postgres به پلی پایدار بین پایگاهداده و سامانه پیامرسان تبدیل میشود؛ همان رویکردی که Alex Pliutau در معرفی پیادهسازی Outbox با Go و Postgres بر آن تأکید دارد.
#OutboxPattern #Go #Postgres #Microservices #EventDriven #TransactionalOutbox #Reliability #Messaging
🟣لینک مقاله:
https://postgresweekly.com/link/174464/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
packagemain.tech
How to implement the Outbox pattern in Go and Postgres
How and why to use the Outbox pattern to build a robust event-driven system.
کنترل اجرای همزمان با Idempotency و Global Lock در Redis
یکی از چالشهای بزرگ در سیستمهای پرترافیک، اجرای همزمان (Concurrency) درخواستهاست. وقتی چند درخواست همزمان به یک سرویس حساس مثل پرداخت یا رزرو ارسال میشوند، احتمال ایجاد داده تکراری یا Race Condition بسیار بالاست.
راهکار من: ترکیب Idempotency با قابلیت Global Lock در Redis
قابلیت Global Lock تضمین میکند که در هر لحظه فقط یک درخواست واقعی اجرا شود.
قابلیت Idempotency اطمینان میدهد که اگر درخواستهای مشابه همزمان ارسال شوند، نتیجه یکسان به کاربر برگردد و هیچ عملیات تکراری اجرا نشود.
من از این ترکیب استفاده کردم در بخش پرداخت ها و نتیجه اش عالی بود
<Mojtaba Zaferani/>
یکی از چالشهای بزرگ در سیستمهای پرترافیک، اجرای همزمان (Concurrency) درخواستهاست. وقتی چند درخواست همزمان به یک سرویس حساس مثل پرداخت یا رزرو ارسال میشوند، احتمال ایجاد داده تکراری یا Race Condition بسیار بالاست.
راهکار من: ترکیب Idempotency با قابلیت Global Lock در Redis
قابلیت Global Lock تضمین میکند که در هر لحظه فقط یک درخواست واقعی اجرا شود.
قابلیت Idempotency اطمینان میدهد که اگر درخواستهای مشابه همزمان ارسال شوند، نتیجه یکسان به کاربر برگردد و هیچ عملیات تکراری اجرا نشود.
من از این ترکیب استفاده کردم در بخش پرداخت ها و نتیجه اش عالی بود
<Mojtaba Zaferani/>
🔵 عنوان مقاله
Going Down the Rabbit Hole of Postgres 18 Features
🟢 خلاصه مقاله:
**این مطلب با حفظ شور انتشار اخیر Postgres 18، بهجای ارجاع مستقیم به یادداشتهای طولانی انتشار، مرور قابلفهمی از ویژگیهای جدید ارائه میدهد. Tudor تغییرات مهم و بهبودهای عملی را در قالبی موضوعمحور توضیح میدهد تا روشن شود هر قابلیت چه مسئلهای را حل میکند و در چه سناریوهایی سودمند است. تمرکز متن بر فهم ساده، مقایسه با نسخههای قبلی و اشاره به نکات سازگاری و برنامهریزی برای ارتقاست. خروجی، یک نقشه راه عملی برای تیمهاست تا سریعتر تصمیم بگیرند کدام قابلیتها را همین حالا بیازمایند و کدام را بعداً ارزیابی کنند.
#Postgres18 #PostgreSQL #Database #ReleaseNotes #OpenSource #SQL #DBA #Performance
🟣لینک مقاله:
https://postgresweekly.com/link/175084/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Going Down the Rabbit Hole of Postgres 18 Features
🟢 خلاصه مقاله:
**این مطلب با حفظ شور انتشار اخیر Postgres 18، بهجای ارجاع مستقیم به یادداشتهای طولانی انتشار، مرور قابلفهمی از ویژگیهای جدید ارائه میدهد. Tudor تغییرات مهم و بهبودهای عملی را در قالبی موضوعمحور توضیح میدهد تا روشن شود هر قابلیت چه مسئلهای را حل میکند و در چه سناریوهایی سودمند است. تمرکز متن بر فهم ساده، مقایسه با نسخههای قبلی و اشاره به نکات سازگاری و برنامهریزی برای ارتقاست. خروجی، یک نقشه راه عملی برای تیمهاست تا سریعتر تصمیم بگیرند کدام قابلیتها را همین حالا بیازمایند و کدام را بعداً ارزیابی کنند.
#Postgres18 #PostgreSQL #Database #ReleaseNotes #OpenSource #SQL #DBA #Performance
🟣لینک مقاله:
https://postgresweekly.com/link/175084/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Xata
Going down the rabbit hole of Postgres 18 features by Tudor Golubenco
A comprehensive list of PostgreSQL 18 new features, performance optimizations, operational and observability improvements, and new tools for devs.
🔵 عنوان مقاله
pgsql_tweaks 1.0.0 Released
🟢 خلاصه مقاله:
** pgsql_tweaks 1.0.0 منتشر شد؛ مجموعهای از توابع و viewها که از تجربه روزمره نویسنده در کار با Postgres استخراج شده است. این بسته نیازهای رایج عملیاتی را پوشش میدهد: بررسی نوع دادهها، گردآوری آمار، مانیتورینگ WAL، شناسایی ایندکسهای بلااستفاده، و توابع تبدیلی برای سادهسازی تبدیل داده. هدف، ارائه ابزارهای سبک و مبتنی بر SQL برای پایش و بهینهسازی سریع است تا DBAها و توسعهدهندگان بتوانند بررسیهای استاندارد و تشخیصهای عملکردی را بهسادگی انجام دهند. صفحه رسمی پروژه برای هر قابلیت مستندات جداگانه ارائه میکند.
#Postgres #PostgreSQL #DatabaseTools #WAL #Indexes #Monitoring #Release
🟣لینک مقاله:
https://postgresweekly.com/link/174471/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
pgsql_tweaks 1.0.0 Released
🟢 خلاصه مقاله:
** pgsql_tweaks 1.0.0 منتشر شد؛ مجموعهای از توابع و viewها که از تجربه روزمره نویسنده در کار با Postgres استخراج شده است. این بسته نیازهای رایج عملیاتی را پوشش میدهد: بررسی نوع دادهها، گردآوری آمار، مانیتورینگ WAL، شناسایی ایندکسهای بلااستفاده، و توابع تبدیلی برای سادهسازی تبدیل داده. هدف، ارائه ابزارهای سبک و مبتنی بر SQL برای پایش و بهینهسازی سریع است تا DBAها و توسعهدهندگان بتوانند بررسیهای استاندارد و تشخیصهای عملکردی را بهسادگی انجام دهند. صفحه رسمی پروژه برای هر قابلیت مستندات جداگانه ارائه میکند.
#Postgres #PostgreSQL #DatabaseTools #WAL #Indexes #Monitoring #Release
🟣لینک مقاله:
https://postgresweekly.com/link/174471/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
proopensource.it
ProOpenSource OÜ Blog | pgsql_tweaks 1.0.0 Released
pgsql_tweaks is a bundle of functions and views for PostgreSQL
🔵 عنوان مقاله
The Great Consolidation is underway (2 minute read)
🟢 خلاصه مقاله:
** روند The Great Consolidation در مهندسی داده سرعت گرفته است؛ ادغامهایی مثل Fivetran نشان میدهد بازاری که سالها بیشازحد داغ شده بود، حالا در حال بلوغ و یکپارچهسازی ابزارهای همپوشان است. محرکها شامل خستگی از تکثر ابزارها و هزینههای یکپارچهسازی، فشار برای کاهش هزینهها، و نیاز به حاکمیت، امنیت و مشاهدهپذیری یکپارچه است. پیامدها: ابزارهای تخصصی کمتر و پلتفرمهای جامعتر، تغییر در نقشهراهها، ادغام یا توقف برخی محصولات، و ریسکهای جابهجایی و قفلشدن در فروشنده. راهکار: تکیه بر استانداردها و رابطهای باز، معماری ماژولار، شروط خروج در قراردادها و ارزیابی TCO برای حفظ اختیار عمل. برندگان، پلتفرمهای انتهابهانتها با حاکمیت قوی خواهند بود و ابزارهای نیچی تنها با برتری ۱۰ برابری میمانند. تمرکز بازار از هیجان به پایداری، کارایی و نتایج اندازهپذیر منتقل میشود.
#DataEngineering #Consolidation #MergersAndAcquisitions #DataStack #VendorLockIn #DataPlatforms #Fivetran
🟣لینک مقاله:
https://www.reddit.com/r/dataengineering/comments/1nulrd5/the_great_consolidation_is_underway/?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
The Great Consolidation is underway (2 minute read)
🟢 خلاصه مقاله:
** روند The Great Consolidation در مهندسی داده سرعت گرفته است؛ ادغامهایی مثل Fivetran نشان میدهد بازاری که سالها بیشازحد داغ شده بود، حالا در حال بلوغ و یکپارچهسازی ابزارهای همپوشان است. محرکها شامل خستگی از تکثر ابزارها و هزینههای یکپارچهسازی، فشار برای کاهش هزینهها، و نیاز به حاکمیت، امنیت و مشاهدهپذیری یکپارچه است. پیامدها: ابزارهای تخصصی کمتر و پلتفرمهای جامعتر، تغییر در نقشهراهها، ادغام یا توقف برخی محصولات، و ریسکهای جابهجایی و قفلشدن در فروشنده. راهکار: تکیه بر استانداردها و رابطهای باز، معماری ماژولار، شروط خروج در قراردادها و ارزیابی TCO برای حفظ اختیار عمل. برندگان، پلتفرمهای انتهابهانتها با حاکمیت قوی خواهند بود و ابزارهای نیچی تنها با برتری ۱۰ برابری میمانند. تمرکز بازار از هیجان به پایداری، کارایی و نتایج اندازهپذیر منتقل میشود.
#DataEngineering #Consolidation #MergersAndAcquisitions #DataStack #VendorLockIn #DataPlatforms #Fivetran
🟣لینک مقاله:
https://www.reddit.com/r/dataengineering/comments/1nulrd5/the_great_consolidation_is_underway/?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Reddit
From the dataengineering community on Reddit: The Great Consolidation is underway
Explore this post and more from the dataengineering community
Forwarded from Future Pulse Persian
پاول دورُف: حاضرَم بمیرم، ولی آزادی و امنیت کاربران رو نفروشم!
در گفتوگوی عمیق با «لِکس فریدمن»، بنیانگذار تلگرام از فلسفهٔ زندگی، حریم خصوصی، بیتکوین و مقاومتش در برابر فشار دولتها گفت.
> 🗣
🔒
او تأکید کرد تلگرام هیچوقت “در پشتی” برای دولتها باز نکرده و در برابر فشار روسیه و ایران برای دسترسی به اطلاعات یا سانسور مقاومت کرده است.
>
📱 ۷ اصل فکری و مدیریتی پاول دورُف (بر اساس مصاحبه):
1️⃣ آزادی و اخلاق بالاتر از هر سود مالی — او میگوید حاضر است تمام داراییاش را از دست بدهد تا آزادی بیان و امنیت کاربران حفظ شود.
2️⃣ مینیمالیسم و انضباط شخصی — سبک زندگیاش ساده، بدون الکل، قهوه یا حواسپرتی است؛ تمرکز کامل روی مأموریت و نظم ذهنی.
3️⃣ تیم کوچک، تأثیر بزرگ — معتقد است تیمهای بزرگ بهرهوری را میکُشند؛ موفقیت تلگرام حاصل اعتماد به چند نابغهٔ منضبط است.
4️⃣ مقاومت در برابر سانسور و در پشتی — هیچ دولت یا شرکتی حق کنترل یا شنود تلگرام را ندارد. رمزنگاری و طراحی MTProto را «دیوار آزادی دیجیتال» مینامد.
5️⃣ پول و قدرت ابزارند، نه هدف — او از مدلهای انحصاری و کمیسیونهای اپل و گوگل انتقاد میکند و تأکید دارد که ثروت نباید آزادی را محدود کند.
6️⃣ باور به فناوری آزاد مثل بیتکوین — بیتکوین را «نمادِ کاهش نیاز به اعتماد به واسطهها و آزادی مالی» میداند؛ از پروژه TON بهعنوان زیربنای اقتصاد آزاد تلگرام یاد میکند.
7️⃣ نگاه فلسفی به زندگی و مرگ — از کافکا، شوپنهاور و «جاودانگی کوانتومی» میگوید؛ باور دارد انسان باید بدون ترس از مرگ، بر پایهٔ ارزشهای خودش زندگی کند.
در گفتوگوی عمیق با «لِکس فریدمن»، بنیانگذار تلگرام از فلسفهٔ زندگی، حریم خصوصی، بیتکوین و مقاومتش در برابر فشار دولتها گفت.
> 🗣
«من ترجیح میدم بمیرم و تمام داراییم رو از دست بدهم تا اینکه اطلاعات کاربران رو به هر دولتی تحویل بدم.
آزادی و امنیت دادهها، خط قرمز من و تلگرامه.»
🔒
او تأکید کرد تلگرام هیچوقت “در پشتی” برای دولتها باز نکرده و در برابر فشار روسیه و ایران برای دسترسی به اطلاعات یا سانسور مقاومت کرده است.
>
«در روسیه و ایران بارها تلاش شد ما رو مجبور به همکاری کنن. ولی ما مقاومت کردیم چون اگر یکبار کوتاه بیای، دیگه آزادی واقعی وجود نداره.»
📱 ۷ اصل فکری و مدیریتی پاول دورُف (بر اساس مصاحبه):
1️⃣ آزادی و اخلاق بالاتر از هر سود مالی — او میگوید حاضر است تمام داراییاش را از دست بدهد تا آزادی بیان و امنیت کاربران حفظ شود.
2️⃣ مینیمالیسم و انضباط شخصی — سبک زندگیاش ساده، بدون الکل، قهوه یا حواسپرتی است؛ تمرکز کامل روی مأموریت و نظم ذهنی.
3️⃣ تیم کوچک، تأثیر بزرگ — معتقد است تیمهای بزرگ بهرهوری را میکُشند؛ موفقیت تلگرام حاصل اعتماد به چند نابغهٔ منضبط است.
4️⃣ مقاومت در برابر سانسور و در پشتی — هیچ دولت یا شرکتی حق کنترل یا شنود تلگرام را ندارد. رمزنگاری و طراحی MTProto را «دیوار آزادی دیجیتال» مینامد.
5️⃣ پول و قدرت ابزارند، نه هدف — او از مدلهای انحصاری و کمیسیونهای اپل و گوگل انتقاد میکند و تأکید دارد که ثروت نباید آزادی را محدود کند.
6️⃣ باور به فناوری آزاد مثل بیتکوین — بیتکوین را «نمادِ کاهش نیاز به اعتماد به واسطهها و آزادی مالی» میداند؛ از پروژه TON بهعنوان زیربنای اقتصاد آزاد تلگرام یاد میکند.
7️⃣ نگاه فلسفی به زندگی و مرگ — از کافکا، شوپنهاور و «جاودانگی کوانتومی» میگوید؛ باور دارد انسان باید بدون ترس از مرگ، بر پایهٔ ارزشهای خودش زندگی کند.
🤗2
🔵 عنوان مقاله
Apache DataFusion 50.0.0 Released (6 minute read)
🟢 خلاصه مقاله:
Apache DataFusion نسخه 50.0.0 با تمرکز بر بهبود کارایی و تجربه تحلیلی منتشر شد. مهمترین بهبودها شامل dynamic filter pushdown برای inner hash joins است که با انتقال فیلترهای حاصل از join به مرحله اسکن، در بسیاری از سناریوها باعث جهش قابلتوجه در کارایی اسکن میشود. همچنین عملگر nested loop join بازنویسی شده و اکنون تا ۵ برابر سریعتر اجرا میشود و تا ۹۹٪ حافظه کمتری مصرف میکند. در کنار اینها، قابلیت automatic Parquet metadata caching در پرسوجوهای نقطهای (point queries) تا ۱۲ برابر سرعت بیشتر فراهم میکند.
از نظر قابلیتها، پشتیبانی از disk-spilling sorts پایداری پردازش مرتبسازی را در دادههای بزرگ با امکان استفاده از دیسک تضمین میکند. افزوده شدن عبارات QUALIFY و FILTER نیز نگارش پرسوجوهای تحلیلی پیشرفته—از جمله فیلترگذاری پس از window functions و فیلتر روی تجمیعها—را سادهتر میسازد. علاوه بر این، سازگاری گستردهتر با Apache Spark انتقال و اجرای بارهای کاری موجود را با تغییرات کمتر ممکن میکند. مجموع این تغییرات، DataFusion 50.0.0 را برای تحلیل تعاملی، ETL و محیطهای ابری حساس به هزینه به گزینهای ارتقایافته و کارآمد تبدیل میکند.
#ApacheDataFusion #DataFusion #BigData #DataEngineering #QueryEngine #Parquet #SQL #ApacheSpark
🟣لینک مقاله:
https://datafusion.apache.org/blog/2025/09/29/datafusion-50.0.0?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Apache DataFusion 50.0.0 Released (6 minute read)
🟢 خلاصه مقاله:
Apache DataFusion نسخه 50.0.0 با تمرکز بر بهبود کارایی و تجربه تحلیلی منتشر شد. مهمترین بهبودها شامل dynamic filter pushdown برای inner hash joins است که با انتقال فیلترهای حاصل از join به مرحله اسکن، در بسیاری از سناریوها باعث جهش قابلتوجه در کارایی اسکن میشود. همچنین عملگر nested loop join بازنویسی شده و اکنون تا ۵ برابر سریعتر اجرا میشود و تا ۹۹٪ حافظه کمتری مصرف میکند. در کنار اینها، قابلیت automatic Parquet metadata caching در پرسوجوهای نقطهای (point queries) تا ۱۲ برابر سرعت بیشتر فراهم میکند.
از نظر قابلیتها، پشتیبانی از disk-spilling sorts پایداری پردازش مرتبسازی را در دادههای بزرگ با امکان استفاده از دیسک تضمین میکند. افزوده شدن عبارات QUALIFY و FILTER نیز نگارش پرسوجوهای تحلیلی پیشرفته—از جمله فیلترگذاری پس از window functions و فیلتر روی تجمیعها—را سادهتر میسازد. علاوه بر این، سازگاری گستردهتر با Apache Spark انتقال و اجرای بارهای کاری موجود را با تغییرات کمتر ممکن میکند. مجموع این تغییرات، DataFusion 50.0.0 را برای تحلیل تعاملی، ETL و محیطهای ابری حساس به هزینه به گزینهای ارتقایافته و کارآمد تبدیل میکند.
#ApacheDataFusion #DataFusion #BigData #DataEngineering #QueryEngine #Parquet #SQL #ApacheSpark
🟣لینک مقاله:
https://datafusion.apache.org/blog/2025/09/29/datafusion-50.0.0?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @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
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…
🔵 عنوان مقاله
How the COPY Command Gets More User Friendly in Postgres 18
🟢 خلاصه مقاله:
بهروزرسانیهای Postgres 18 بر بهبود تجربه کاربری تمرکز دارد؛ از جمله آسانتر و ایمنتر شدن کار با دستور COPY. هدف این است که پیامهای خطا در مواجهه با ناسازگاری ستونها، مسائل کدگذاری یا ردیفهای CSV معیوب شفافتر و قابل اقدامتر شوند، گزینههای رایج (مثل کار با هدرها و CSV) رفتار پیشفرض قابلاعتمادتری داشته باشند، و جریانهای کاری واردسازی انبوه با امکان نادیدهگرفتن یا ثبت ردیفهای خطادار اصطکاک کمتری داشته باشند. همچنین همگرایی رفتار بین COPY سمت سرور و copy در psql و شفافیت بیشتر در مجوزها و متن خطاها به پیشبینیپذیری و عیبیابی سریعتر کمک میکند.
در کنار اینها، کار روی cumulative statistics نیز پررنگ است. همانطور که Deepak Mahto و Cédric Villemain توضیح میدهند، هدف، ارائه نمایی منسجمتر، کمهزینهتر و دانهدرشتتر از رفتار سیستم در حوزههایی مانند پرسوجو، I/O و waitهاست تا هم پایش آنی و هم برنامهریزی ظرفیت سادهتر شود. برآیند این تغییرات، کاهش غافلگیریها با پیشفرضهای بهتر، بازخورد سریعتر هنگام خطا و مشاهدهپذیری عمیقتر برای تنظیم کارایی در Postgres 18 است.
#Postgres18 #PostgreSQL #COPY #CumulativeStatistics #Database #Observability #DataEngineering #DX
🟣لینک مقاله:
https://postgresweekly.com/link/175100/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
How the COPY Command Gets More User Friendly in Postgres 18
🟢 خلاصه مقاله:
بهروزرسانیهای Postgres 18 بر بهبود تجربه کاربری تمرکز دارد؛ از جمله آسانتر و ایمنتر شدن کار با دستور COPY. هدف این است که پیامهای خطا در مواجهه با ناسازگاری ستونها، مسائل کدگذاری یا ردیفهای CSV معیوب شفافتر و قابل اقدامتر شوند، گزینههای رایج (مثل کار با هدرها و CSV) رفتار پیشفرض قابلاعتمادتری داشته باشند، و جریانهای کاری واردسازی انبوه با امکان نادیدهگرفتن یا ثبت ردیفهای خطادار اصطکاک کمتری داشته باشند. همچنین همگرایی رفتار بین COPY سمت سرور و copy در psql و شفافیت بیشتر در مجوزها و متن خطاها به پیشبینیپذیری و عیبیابی سریعتر کمک میکند.
در کنار اینها، کار روی cumulative statistics نیز پررنگ است. همانطور که Deepak Mahto و Cédric Villemain توضیح میدهند، هدف، ارائه نمایی منسجمتر، کمهزینهتر و دانهدرشتتر از رفتار سیستم در حوزههایی مانند پرسوجو، I/O و waitهاست تا هم پایش آنی و هم برنامهریزی ظرفیت سادهتر شود. برآیند این تغییرات، کاهش غافلگیریها با پیشفرضهای بهتر، بازخورد سریعتر هنگام خطا و مشاهدهپذیری عمیقتر برای تنظیم کارایی در Postgres 18 است.
#Postgres18 #PostgreSQL #COPY #CumulativeStatistics #Database #Observability #DataEngineering #DX
🟣لینک مقاله:
https://postgresweekly.com/link/175100/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Database and Migration Insights
Exploring PostgreSQL 18: A Developer’s Guide to New Features – Part 1: The COPY Command Gets More User-Friendly
PostgreSQL 18, released on September 25, 2024, enhances the COPY command with improved error handling through the REJECT_LIMIT option, allowing data loading to be controlled by limiting errors. Thi…
🙏1
🔵 عنوان مقاله
Apache Gravitino (GitHub Repo)
🟢 خلاصه مقاله:
Apache Gravitino با انتشار نسخه 1.0 بهعنوان یک جایگزین متنباز برای Unity Catalog معرفی شده که بهجای جایگزینی، در کنار Unity Catalog و حاکمیت داده Snowflake کار میکند. این پروژه بهعنوان یک لایه بالادستی بر چندین سیستم عمل میکند و یک نمای یکپارچه از داراییهای داده و ML فراهم میسازد. Gravitino روی اکوسیستمهای متنوعی مثل Hive، Iceberg، Kafka، S3 و رجیستریهای مدل ML کار میکند و کانکتورهای آماده برای پلتفرمهای مختلف و MCP servers دارد. هدف آن، یکپارچهسازی کشف، کاتالوگ و مدیریت حاکمیت در محیطهای ناهمگون است، بدون ایجاد قفل فناوری و در عین حال قابل استفاده در کنار ابزارهای موجود. این پروژه از طریق GitHub در دسترس است.
#ApacheGravitino #DataCatalog #DataGovernance #OpenSource #UnityCatalog #Kafka #Iceberg #S3
🟣لینک مقاله:
https://github.com/apache/gravitino?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Apache Gravitino (GitHub Repo)
🟢 خلاصه مقاله:
Apache Gravitino با انتشار نسخه 1.0 بهعنوان یک جایگزین متنباز برای Unity Catalog معرفی شده که بهجای جایگزینی، در کنار Unity Catalog و حاکمیت داده Snowflake کار میکند. این پروژه بهعنوان یک لایه بالادستی بر چندین سیستم عمل میکند و یک نمای یکپارچه از داراییهای داده و ML فراهم میسازد. Gravitino روی اکوسیستمهای متنوعی مثل Hive، Iceberg، Kafka، S3 و رجیستریهای مدل ML کار میکند و کانکتورهای آماده برای پلتفرمهای مختلف و MCP servers دارد. هدف آن، یکپارچهسازی کشف، کاتالوگ و مدیریت حاکمیت در محیطهای ناهمگون است، بدون ایجاد قفل فناوری و در عین حال قابل استفاده در کنار ابزارهای موجود. این پروژه از طریق GitHub در دسترس است.
#ApacheGravitino #DataCatalog #DataGovernance #OpenSource #UnityCatalog #Kafka #Iceberg #S3
🟣لینک مقاله:
https://github.com/apache/gravitino?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
GitHub
GitHub - apache/gravitino: World's most powerful open data catalog for building a high-performance, geo-distributed and federated…
World's most powerful open data catalog for building a high-performance, geo-distributed and federated metadata lake. - apache/gravitino
Forwarded from Future Pulse Persian
♨️ راز خواب 12 ساعته پاول دورف؛ جایی که ایدههای تلگرام شکل میگیرن!
▪️پاول دورف، مدیرعامل تلگرام، گفته روزی بین ۱۱ تا ۱۲ ساعت میخوابه ، و جالبه که اینو نه تنبلی، بلکه منبع اصلی ایدههای درخشانش میدونه!
▪️دورف صبحها حتی سراغ گوشی هم نمیره، چون معتقده موبایلها جلوی تفکر مستقل رو میگیرن.
خودش میگه:
♨️ راز خواب 12 ساعته پاول دورف؛ جایی که ایدههای تلگرام شکل میگیرن!
▪️پاول دورف، مدیرعامل تلگرام، گفته روزی بین ۱۱ تا ۱۲ ساعت میخوابه ، و جالبه که اینو نه تنبلی، بلکه منبع اصلی ایدههای درخشانش میدونه!
▪️دورف صبحها حتی سراغ گوشی هم نمیره، چون معتقده موبایلها جلوی تفکر مستقل رو میگیرن.
خودش میگه:
«میخوام خودم تصمیم بگیرم چی تو زندگیم مهمه، نه اینکه شرکتها یا الگوریتمها برام تعیین کنن.»
🔵 عنوان مقاله
Implementing a Kalman Filter in Postgres to Smooth GPS Data
🟢 خلاصه مقاله:
** این مقاله نشان میدهد چگونه میتوان Kalman Filter را مستقیماً داخل Postgres پیادهسازی کرد تا دادههای GPS پرنوسان را هموار کرد، بدون نیاز به خروج دادهها به ابزارهای بیرونی. با اجرای مراحل پیشبینی و بهروزرسانی در SQL/PLpgSQL و استفاده از مرتبسازی زمانی و پارتیشنبندی بر اساس دستگاه، صافسازی در همان جایی انجام میشود که دادهها ذخیره شدهاند. نتیجه، مسیرهای روانتر، برآوردهای دقیقتر سرعت/جهت، و سادهتر شدن خط لوله برای کاربردهایی مثل ناوگان و IoT است. همانطور که Thorsten Rieß اشاره میکند، این کاری غیرمعمول در SQL است، اما بهدلیل بازتولیدپذیری، تراکنشی بودن و ادغام آسان با PostGIS و نماها، راهکاری عملی و قدرتمند محسوب میشود.
#KalmanFilter #Postgres #SQL #GPS #PostGIS #TimeSeries #DataSmoothing #IoT
🟣لینک مقاله:
https://postgresweekly.com/link/175098/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Implementing a Kalman Filter in Postgres to Smooth GPS Data
🟢 خلاصه مقاله:
** این مقاله نشان میدهد چگونه میتوان Kalman Filter را مستقیماً داخل Postgres پیادهسازی کرد تا دادههای GPS پرنوسان را هموار کرد، بدون نیاز به خروج دادهها به ابزارهای بیرونی. با اجرای مراحل پیشبینی و بهروزرسانی در SQL/PLpgSQL و استفاده از مرتبسازی زمانی و پارتیشنبندی بر اساس دستگاه، صافسازی در همان جایی انجام میشود که دادهها ذخیره شدهاند. نتیجه، مسیرهای روانتر، برآوردهای دقیقتر سرعت/جهت، و سادهتر شدن خط لوله برای کاربردهایی مثل ناوگان و IoT است. همانطور که Thorsten Rieß اشاره میکند، این کاری غیرمعمول در SQL است، اما بهدلیل بازتولیدپذیری، تراکنشی بودن و ادغام آسان با PostGIS و نماها، راهکاری عملی و قدرتمند محسوب میشود.
#KalmanFilter #Postgres #SQL #GPS #PostGIS #TimeSeries #DataSmoothing #IoT
🟣لینک مقاله:
https://postgresweekly.com/link/175098/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Neon
Implementing a Kalman Filter in Postgres to Smooth GPS Data - Neon
An open-source project that implements a Kalman Filter in Postgres to clean up noisy GPS data directly in the database.
❤1
🔵 عنوان مقاله
How Kafka Works (20 minute read)
🟢 خلاصه مقاله:
Apache Kafka یک پلتفرم متنباز پیامرسانی و رویدادمحور است که رکوردهای key-value را در logهای افزایشی و تغییرناپذیر ذخیره میکند. دادهها در topicها سازماندهی و بین partitionها توزیع میشوند تا مقیاسپذیری افقی و پردازش موازی فراهم شود. ترتیب پیامها در هر partition حفظ میشود، و مصرفکنندهها با تکیه بر offset میتوانند بازپخش دقیق داده و بازیابی وضعیت انجام دهند؛ علاوهبر نگهداشت (retention)، log compaction آخرین رکورد هر key را نگه میدارد. کلاستر Kafka معمولاً حداقل سه broker دارد؛ هر partition یک leader و چند follower دارد و با ضریب تکرار پیشفرض 3 همتابی میشود. نوشتنها به leader انجام میشود و followerها همگامسازی میکنند؛ پایداری با تنظیماتی مانند acks=all و مجموعه ISR کنترل میشود. مدل pull در مصرف به مدیریت backpressure کمک میکند و consumer groupها امکان مقیاسپذیری و تحمل خطا را فراهم میسازند. Kafka بهصورت پیشفرض تحویل at-least-once ارائه میدهد و با idempotent producer و تراکنشها به exactly-once میرسد. در معماری مدرن، پروتکل KRaft جایگزین ZooKeeper شده و هماهنگی، انتخابات leader و بازیابی را در خود Kafka متمرکز میکند و عملیات را ساده و سریعتر میسازد.
#ApacheKafka #KRaft #ZooKeeper #DistributedSystems #EventStreaming #Scalability #FaultTolerance #Messaging
🟣لینک مقاله:
https://newsletter.systemdesign.one/p/how-kafka-works?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
How Kafka Works (20 minute read)
🟢 خلاصه مقاله:
Apache Kafka یک پلتفرم متنباز پیامرسانی و رویدادمحور است که رکوردهای key-value را در logهای افزایشی و تغییرناپذیر ذخیره میکند. دادهها در topicها سازماندهی و بین partitionها توزیع میشوند تا مقیاسپذیری افقی و پردازش موازی فراهم شود. ترتیب پیامها در هر partition حفظ میشود، و مصرفکنندهها با تکیه بر offset میتوانند بازپخش دقیق داده و بازیابی وضعیت انجام دهند؛ علاوهبر نگهداشت (retention)، log compaction آخرین رکورد هر key را نگه میدارد. کلاستر Kafka معمولاً حداقل سه broker دارد؛ هر partition یک leader و چند follower دارد و با ضریب تکرار پیشفرض 3 همتابی میشود. نوشتنها به leader انجام میشود و followerها همگامسازی میکنند؛ پایداری با تنظیماتی مانند acks=all و مجموعه ISR کنترل میشود. مدل pull در مصرف به مدیریت backpressure کمک میکند و consumer groupها امکان مقیاسپذیری و تحمل خطا را فراهم میسازند. Kafka بهصورت پیشفرض تحویل at-least-once ارائه میدهد و با idempotent producer و تراکنشها به exactly-once میرسد. در معماری مدرن، پروتکل KRaft جایگزین ZooKeeper شده و هماهنگی، انتخابات leader و بازیابی را در خود Kafka متمرکز میکند و عملیات را ساده و سریعتر میسازد.
#ApacheKafka #KRaft #ZooKeeper #DistributedSystems #EventStreaming #Scalability #FaultTolerance #Messaging
🟣لینک مقاله:
https://newsletter.systemdesign.one/p/how-kafka-works?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
newsletter.systemdesign.one
How Kafka Works
#91: Learn Everything About Apache Kafka’s Architecture, Including Brokers, KRaft, Topic Partitions, Tiered Storage, Exactly Once, Kafka Connect, Kafka Schema Registry and Kafka Streams
🎉1
🔵 عنوان مقاله
Stateless Postgres Query Router (SPQR) 2.7
🟢 خلاصه مقاله:
** SPQR 2.7 یک Stateless Postgres Query Router است که رویکردی عملی برای افقیسازی از طریق sharding ارائه میدهد و ابتدا در Yandex Cloud شکل گرفته است. این مدل با قراردادن یک لایه مسیریاب بین برنامهها و مجموعهای از shardهای Postgres، مسیریابی پرسوجو را متمرکز و مقیاسپذیری افقی را ساده میکند؛ ماهیت stateless آن نیز استقرار پشت Load Balancer، افزونگی و ارتقای بدون دردسر را ممکن میسازد. انتخاب کلید sharding، بازتوزیع داده و مدیریت پرسوجوهای چند-shard از چالشهای عملیاتی آن است، اما جداسازی مسئولیتها بین لایه مسیریابی و لایه ذخیرهسازی، مسیر روشنی برای رشد مقیاس فراهم میکند. نسخه 2.7 نشاندهنده بلوغ این الگو و تناسب آن با محیطهای cloud-native است، بیآنکه نیاز به ترک اکوسیستم Postgres باشد.
#Postgres #SPQR #YandexCloud #Sharding #DatabaseScaling #DistributedSystems #StatelessArchitecture #PostgreSQL
🟣لینک مقاله:
https://postgresweekly.com/link/174476/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Stateless Postgres Query Router (SPQR) 2.7
🟢 خلاصه مقاله:
** SPQR 2.7 یک Stateless Postgres Query Router است که رویکردی عملی برای افقیسازی از طریق sharding ارائه میدهد و ابتدا در Yandex Cloud شکل گرفته است. این مدل با قراردادن یک لایه مسیریاب بین برنامهها و مجموعهای از shardهای Postgres، مسیریابی پرسوجو را متمرکز و مقیاسپذیری افقی را ساده میکند؛ ماهیت stateless آن نیز استقرار پشت Load Balancer، افزونگی و ارتقای بدون دردسر را ممکن میسازد. انتخاب کلید sharding، بازتوزیع داده و مدیریت پرسوجوهای چند-shard از چالشهای عملیاتی آن است، اما جداسازی مسئولیتها بین لایه مسیریابی و لایه ذخیرهسازی، مسیر روشنی برای رشد مقیاس فراهم میکند. نسخه 2.7 نشاندهنده بلوغ این الگو و تناسب آن با محیطهای cloud-native است، بیآنکه نیاز به ترک اکوسیستم Postgres باشد.
#Postgres #SPQR #YandexCloud #Sharding #DatabaseScaling #DistributedSystems #StatelessArchitecture #PostgreSQL
🟣لینک مقاله:
https://postgresweekly.com/link/174476/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
GitHub
GitHub - pg-sharding/spqr: Stateless Postgres Query Router.
Stateless Postgres Query Router. Contribute to pg-sharding/spqr development by creating an account on GitHub.
🔵 عنوان مقاله
Postgres Migrations Using Logical Replication (7 minute read)
🟢 خلاصه مقاله:
مهاجرت پایگاهدادههای بزرگ Postgres بدون توقف طولانی دشوار است؛ بهویژه در RDS که دسترسی مستقیم به WAL وجود ندارد. روشهای سنتی مانند pg_dump/pg_restore برای دادههای کم مناسباند اما در مقیاس ترابایتی باعث قطعی طولانی میشوند. پشتیبانگیری فیزیکی مبتنی بر WAL برای کلونگیری مفید است، اما در جابهجایی منطقی، تغییرات طرح، یا مهاجرت بین پلتفرمها کارایی ندارد و معمولاً به دسترسی WAL نیاز دارد.
راهحل عملی، logical replication است: پس از همگامسازی اولیه، تغییرات ردیفی بهصورت پیوسته به مقصد استریم میشود تا در زمان برش نهایی، فقط وقفهای کوتاه نیاز باشد. با این حال، logical replication طرح، ایندکسها و sequences را منتقل نمیکند؛ بنابراین باید طرح و ایندکسها را از قبل در مقصد بسازید و sequences را پیش از برش با setval همگام کنید. وجود کلید اصلی یا تنظیم مناسب REPLICA IDENTITY، پایش تاخیر تکرار و مدیریت تراکنشهای بلندمدت ضروری است.
طرح کلی مهاجرت شامل این مراحل است: آمادهسازی مقصد و اعمال طرح؛ بارگذاری اولیه داده (مثلاً با pg_dump --data-only و اجرای موازی)؛ ایجاد PUBLICATION در مبدأ و SUBSCRIPTION در مقصد؛ پایش pg_stat_subnoscription و اعتبارسنجی داده؛ سپس توقف موقت نوشتن، صبر تا صفر شدن تاخیر، همترازی sequences، سوئیچ برنامه به مقصد و نگهداشتن مبدأ در حالت فقطخواندنی برای بازگشت احتمالی. همچنین باید سازگاری نسخهها، پهنایباند شبکه، و محدودیتهای RDS را در نظر بگیرید. برای Postgres-to-Postgres، logical replication معمولاً کمهزینهترین مسیر به مهاجرت با توقف حداقلی است.
#Postgres #LogicalReplication #DatabaseMigration #ZeroDowntime #AWSRDS #WAL #pg_dump #DevOps
🟣لینک مقاله:
https://www.crunchydata.com/blog/postgres-migrations-using-logical-replication?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Postgres Migrations Using Logical Replication (7 minute read)
🟢 خلاصه مقاله:
مهاجرت پایگاهدادههای بزرگ Postgres بدون توقف طولانی دشوار است؛ بهویژه در RDS که دسترسی مستقیم به WAL وجود ندارد. روشهای سنتی مانند pg_dump/pg_restore برای دادههای کم مناسباند اما در مقیاس ترابایتی باعث قطعی طولانی میشوند. پشتیبانگیری فیزیکی مبتنی بر WAL برای کلونگیری مفید است، اما در جابهجایی منطقی، تغییرات طرح، یا مهاجرت بین پلتفرمها کارایی ندارد و معمولاً به دسترسی WAL نیاز دارد.
راهحل عملی، logical replication است: پس از همگامسازی اولیه، تغییرات ردیفی بهصورت پیوسته به مقصد استریم میشود تا در زمان برش نهایی، فقط وقفهای کوتاه نیاز باشد. با این حال، logical replication طرح، ایندکسها و sequences را منتقل نمیکند؛ بنابراین باید طرح و ایندکسها را از قبل در مقصد بسازید و sequences را پیش از برش با setval همگام کنید. وجود کلید اصلی یا تنظیم مناسب REPLICA IDENTITY، پایش تاخیر تکرار و مدیریت تراکنشهای بلندمدت ضروری است.
طرح کلی مهاجرت شامل این مراحل است: آمادهسازی مقصد و اعمال طرح؛ بارگذاری اولیه داده (مثلاً با pg_dump --data-only و اجرای موازی)؛ ایجاد PUBLICATION در مبدأ و SUBSCRIPTION در مقصد؛ پایش pg_stat_subnoscription و اعتبارسنجی داده؛ سپس توقف موقت نوشتن، صبر تا صفر شدن تاخیر، همترازی sequences، سوئیچ برنامه به مقصد و نگهداشتن مبدأ در حالت فقطخواندنی برای بازگشت احتمالی. همچنین باید سازگاری نسخهها، پهنایباند شبکه، و محدودیتهای RDS را در نظر بگیرید. برای Postgres-to-Postgres، logical replication معمولاً کمهزینهترین مسیر به مهاجرت با توقف حداقلی است.
#Postgres #LogicalReplication #DatabaseMigration #ZeroDowntime #AWSRDS #WAL #pg_dump #DevOps
🟣لینک مقاله:
https://www.crunchydata.com/blog/postgres-migrations-using-logical-replication?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Crunchy Data
Postgres Migrations Using Logical Replication | Crunchy Data Blog
Instructions and tips for using logical replication to migrate Postgres to a new platform or host.
🔵 عنوان مقاله
a behind-the-scenes look at EDB's program
🟢 خلاصه مقاله:
نگاهی پشتصحنه به برنامه EDB برای جذب و توانمندسازی مشارکتکنندگان جدید Postgres در شرکت ارائه میدهد. این برنامه با آموزش ساختاریافته، منتورینگ مستمر و استانداردسازی ابزار و گردشکار، ورود به جامعه متنباز را سادهتر میکند و زمان رسیدن به اولین مشارکت را کاهش میدهد. مسیر رشد با نقاط عطف مشخص (از اولین باگ و پچ تا پذیرش در بالادست) سنجیده میشود و بازخوردها مداوماً به بهبود فرآیند میانجامد. نتیجه، تقویت مهارت فردی و همسویی با هنجارهای جامعه Postgres و در نهایت پایداری و کیفیت بالاتر اکوسیستم است.
#Postgres #EDB #OpenSource #Onboarding #DeveloperExperience #OSSContributions #Mentorship #Databases
🟣لینک مقاله:
https://postgresweekly.com/link/175092/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
a behind-the-scenes look at EDB's program
🟢 خلاصه مقاله:
نگاهی پشتصحنه به برنامه EDB برای جذب و توانمندسازی مشارکتکنندگان جدید Postgres در شرکت ارائه میدهد. این برنامه با آموزش ساختاریافته، منتورینگ مستمر و استانداردسازی ابزار و گردشکار، ورود به جامعه متنباز را سادهتر میکند و زمان رسیدن به اولین مشارکت را کاهش میدهد. مسیر رشد با نقاط عطف مشخص (از اولین باگ و پچ تا پذیرش در بالادست) سنجیده میشود و بازخوردها مداوماً به بهبود فرآیند میانجامد. نتیجه، تقویت مهارت فردی و همسویی با هنجارهای جامعه Postgres و در نهایت پایداری و کیفیت بالاتر اکوسیستم است.
#Postgres #EDB #OpenSource #Onboarding #DeveloperExperience #OSSContributions #Mentorship #Databases
🟣لینک مقاله:
https://postgresweekly.com/link/175092/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
EDB
Barcelona beginnings: onboarding new PostgreSQL contributors
PostgreSQL is at the core of what we do at EDB, and several people here work on PostgreSQL full-time. However becoming a contributor and being successful in your contributions is not an easy task. That’s why PostgreSQL powerhouse Andrew Dunstan kicked off…
🔵 عنوان مقاله
a visual explainer of processes and threads
🟢 خلاصه مقاله:
** این مقاله با یک توضیح تصویری، تفاوتهای بنیادین بین فرآیند و رشته را توضیح میدهد: فرآیندها فضای حافظهای جدا دارند و ارتباطشان از طریق مکانیزمهای سیستمعامل انجام میشود، در حالیکه رشتهها داخل یک فرآیند حافظه مشترک دارند، ارتباطشان سریعتر است اما ریسک تداخل و خرابی گستردهتر میشود. سپس این دیدگاه به معماری پایگاههای داده تعمیم داده میشود: Postgres از مدل process-per-connection با فرآیندهای جداگانه برای هر اتصال و حافظه مشترک برای هماهنگی استفاده میکند؛ MySQL در یک mysqld واحد با مدل thread-per-connection (یا thread pool) و رشتههای متعدد اجرا میشود. نتیجه مقایسه: Postgres ایزولاسیون قویتری در سطح حافظه دارد اما سربار هر اتصال بیشتر است و خرابی یک backend میتواند به بازراهاندازی برای حفظ سازگاری منجر شود؛ MySQL از نظر حافظه برای اتصالات زیاد بهینهتر و تعویض متن در آن سریعتر است، ولی خطا یا ازدحام در یک رشته میتواند کل فرایند را متاثر کند و نیازمند تنظیم دقیق برای جلوگیری از رقابت قفلهاست. در عمل، هر دو با ابزارهای connection pooling مانند PgBouncer و ProxySQL افراطها را تعدیل میکنند و انتخاب نهایی به اولویتهای بارکاری بین ایزولاسیون/قابلیت مشاهده در برابر بازده و مقیاسپذیری اتصال بستگی دارد.
#OperatingSystems #Concurrency #Postgres #MySQL #DatabaseArchitecture #Threads #Processes #Performance
🟣لینک مقاله:
https://postgresweekly.com/link/174753/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
a visual explainer of processes and threads
🟢 خلاصه مقاله:
** این مقاله با یک توضیح تصویری، تفاوتهای بنیادین بین فرآیند و رشته را توضیح میدهد: فرآیندها فضای حافظهای جدا دارند و ارتباطشان از طریق مکانیزمهای سیستمعامل انجام میشود، در حالیکه رشتهها داخل یک فرآیند حافظه مشترک دارند، ارتباطشان سریعتر است اما ریسک تداخل و خرابی گستردهتر میشود. سپس این دیدگاه به معماری پایگاههای داده تعمیم داده میشود: Postgres از مدل process-per-connection با فرآیندهای جداگانه برای هر اتصال و حافظه مشترک برای هماهنگی استفاده میکند؛ MySQL در یک mysqld واحد با مدل thread-per-connection (یا thread pool) و رشتههای متعدد اجرا میشود. نتیجه مقایسه: Postgres ایزولاسیون قویتری در سطح حافظه دارد اما سربار هر اتصال بیشتر است و خرابی یک backend میتواند به بازراهاندازی برای حفظ سازگاری منجر شود؛ MySQL از نظر حافظه برای اتصالات زیاد بهینهتر و تعویض متن در آن سریعتر است، ولی خطا یا ازدحام در یک رشته میتواند کل فرایند را متاثر کند و نیازمند تنظیم دقیق برای جلوگیری از رقابت قفلهاست. در عمل، هر دو با ابزارهای connection pooling مانند PgBouncer و ProxySQL افراطها را تعدیل میکنند و انتخاب نهایی به اولویتهای بارکاری بین ایزولاسیون/قابلیت مشاهده در برابر بازده و مقیاسپذیری اتصال بستگی دارد.
#OperatingSystems #Concurrency #Postgres #MySQL #DatabaseArchitecture #Threads #Processes #Performance
🟣لینک مقاله:
https://postgresweekly.com/link/174753/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Planetscale
Processes and Threads — PlanetScale
Processes and threads are fundamental abstrations for operating systems. Learn how they work and how they impact database performance in this interactive article.
خبر های PostgreSQL ای
نسخه های جدید:
ابزار pgwatch: مانیتورینگ PostgreSQL برای جمعآوری و نمایش متریکهای عملکرد دیتابیس.
ابزار Autobase: مدیریت خودکار نسخهبندی (schema migrations) و تغییرات ساختار
افزونه pg_stat_kcache 2.3.1:مشاهده مصرف CPU و I/O کوئریها از طریق kernel.
نسخه های جدید:
ابزار pgwatch: مانیتورینگ PostgreSQL برای جمعآوری و نمایش متریکهای عملکرد دیتابیس.
ابزار Autobase: مدیریت خودکار نسخهبندی (schema migrations) و تغییرات ساختار
افزونه pg_stat_kcache 2.3.1:مشاهده مصرف CPU و I/O کوئریها از طریق kernel.
🔵 عنوان مقاله
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
🔵 عنوان مقاله
Switching Me Softly (7 minute read)
🟢 خلاصه مقاله:
فریشا با ساخت یک چارچوب ارکستریشن خودکار و قابلپیکربندی، بیش از ۲۰ پایگاهداده حیاتی PostgreSQL را از PG12 به PG17 با صفر downtime و بدون از دستدادن داده ارتقا داد. این راهکار با اسکریپتهای مبتنیبر YAML، مهاجرتهای تکرارپذیر و قابل بازگشت را ممکن کرد و چالشهای حساس نظیر مدیریت Debezium CDC، حفظ ترتیب رویدادهای outbox، کنترل replication slotها و اجرای cutoverهای روان با PgBouncer را پوشش داد. در نتیجه، محدودیتهای RDS Blue/Green و ارتقای درجا برطرف شد و یک الگوی پایدار برای ارتقاهای آینده در محیط تولید شکل گرفت.
#PostgreSQL #ZeroDowntime #DatabaseMigration #Debezium #CDC #PgBouncer #YAML #RDSBlueGreen
🟣لینک مقاله:
https://medium.com/fresha-data-engineering/switching-me-softly-cb404d02c28b?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Switching Me Softly (7 minute read)
🟢 خلاصه مقاله:
فریشا با ساخت یک چارچوب ارکستریشن خودکار و قابلپیکربندی، بیش از ۲۰ پایگاهداده حیاتی PostgreSQL را از PG12 به PG17 با صفر downtime و بدون از دستدادن داده ارتقا داد. این راهکار با اسکریپتهای مبتنیبر YAML، مهاجرتهای تکرارپذیر و قابل بازگشت را ممکن کرد و چالشهای حساس نظیر مدیریت Debezium CDC، حفظ ترتیب رویدادهای outbox، کنترل replication slotها و اجرای cutoverهای روان با PgBouncer را پوشش داد. در نتیجه، محدودیتهای RDS Blue/Green و ارتقای درجا برطرف شد و یک الگوی پایدار برای ارتقاهای آینده در محیط تولید شکل گرفت.
#PostgreSQL #ZeroDowntime #DatabaseMigration #Debezium #CDC #PgBouncer #YAML #RDSBlueGreen
🟣لینک مقاله:
https://medium.com/fresha-data-engineering/switching-me-softly-cb404d02c28b?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Medium
Switching me Softly
Zero-downtime PostgreSQL 12→17 upgrade at Fresha: RDS snapshots, logical replication, PgBouncer tricks & Debezium orchestration.
❤1