886 subscribers
45 photos
3 videos
1 file
1.43K links
🕸 Database Academy

حمایت مالی:
https://www.coffeete.ir/mrbardia72

ادمین:
@mrbardia72
Download Telegram
نکات و ترفندهای SQL برای بهینه سازی عملکرد دیتابیس شما.

#SQL #Database #Optimization #Performance #TipsAndTricks

https://github.com/ben-n93/SQL-tips-and-tricks


👑 @Database_Academy
🔥1
🔵 عنوان مقاله
Getting Excited About Postgres 18

🟢 خلاصه مقاله:
Postgres 18 تا یک هفته دیگر نهایی می‌شود و مهم‌ترین ویژگی تازه‌اش asynchronous I/O است؛ قابلیتی که امکان انجام عملیات خواندن/نوشتن بدون مسدود کردن مسیر اجرای اصلی را می‌دهد و در بسیاری از سناریوها باعث افزایش توان عملیاتی و کاهش تأخیر می‌شود. این تغییر برای بارهای کاری پرتراکنش، سیستم‌های ترکیبی OLTP/تحلیلی و پردازش‌های سنگین I/O نوید عملکرد روان‌تر و پایدارتر را می‌دهد. با انتشار نسخه نهایی، انتظار می‌رود راهنماها و بهترین‌عمل‌ها برای بهره‌گیری از این بهبودها ارائه شود و تیم‌ها بتوانند با تنظیمات مناسب، از جهش عملکردی Postgres 18 بهره ببرند.

#Postgres18 #Postgres #PostgreSQL #AsynchronousIO #Database #Performance #OpenSource

🟣لینک مقاله:
https://postgresweekly.com/link/174461/web


👑 @Database_Academy
1
🔵 عنوان مقاله
Understanding WAL and Optimizing It with a Dedicated Disk

🟢 خلاصه مقاله:
WAL روشی کلیدی برای پایداری و ریکاوری پس از کرش است: تغییرات ابتدا به شکل ترتیبی در یک لاگ نوشته و به‌صورت پایدار flush می‌شوند و سپس در صورت نیاز روی داده‌های اصلی اعمال یا بازپخش می‌گردند. گلوگاه اصلی معمولاً همان fsync/flush است که باید دوام را تضمین کند. وقتی WAL روی همان دیسکی باشد که فایل‌های داده نیز روی آن I/O تصادفی انجام می‌دهند، وقفه و رقابت صف موجب جهش در تاخیر به‌ویژه در p99/p999 می‌شود. قرار دادن WAL روی یک دیسک اختصاصی این مسیر حساس را ایزوله می‌کند، الگوی نوشتن ترتیبی را حفظ می‌کند و تاخیر را قابل پیش‌بینی‌تر و بهره‌وری را بیشتر می‌سازد.

در عمل می‌توان از یک NVMe مستقل یا یک ولوم ابری جداگانه استفاده کرد؛ فایل‌سیستم‌های رایج مانند ext4 یا XFS با تنظیمات ساده و بدون سربار اضافی مناسب‌اند و باید اطمینان داشت که semantics مربوط به write barrier و cache flush مطابق نیازهای دوام هستند. از منظر Golang، بهینه‌سازی WAL معمولاً با سگمنت‌بندی و پیش‌اختصاص فایل‌ها، نوشتن هم‌تراز با بلوک، checksum، batch کردن درخواست‌ها، group commit با آستانه زمانی/حجمی، استفاده سنجیده از O_DSYNC/fdatasync و مدیریت دقیق بافر انجام می‌شود. اندازه‌گیری دقیق قبل و بعد (میانگین و p99 fsync، نرخ نوشتن، و زمان انتهابه‌انتها) مشخص می‌کند آیا دیسک اختصاصی هزینه‌اش را جبران می‌کند یا خیر؛ برای بارهای نوشتاری بالا یا SLA سخت‌گیرانه، این ایزولاسیون معمولاً ارزشمند است.

#WAL #Golang #Databases #Performance #Storage #NVMe #SystemsDesign

🟣لینک مقاله:
https://postgresweekly.com/link/174762/web


👑 @Database_Academy
1
🔵 عنوان مقاله
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
🔵 عنوان مقاله
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
🔵 عنوان مقاله
How I Learned to Use wal_inspect

🟢 خلاصه مقاله:
این نوشته روایت یادگیری کار با pg_walinspect برای خواندن و فهمیدن رفتار write-ahead log در PostgreSQL است. نویسنده نشان می‌دهد چطور می‌توان با کوئری گرفتن از WAL در بازه‌های مشخص LSN، الگوی فعالیت سیستم را دید: از نقش checkpointها و full-page writeها تا اثر autovacuum، split شدن ایندکس‌ها، بارگذاری‌های حجیم و منشأ افزایش I/O. مزیت pg_walinspect این است که داخل دیتابیس و با SQL می‌شود داده‌ها را خلاصه و فیلتر کرد و با زمان و متریک‌های مانیتورینگ تطبیق داد، بدون خروج به ابزارهای بیرونی.

رویکرد پیشنهادی این است: بازه زمانی/LSN را محدود کنید، ابتدا خلاصه‌ها را ببینید و سپس در صورت نیاز به جزئیات بروید؛ هنگام عیب‌یابی، روی resource managerهای مرتبط تمرکز کنید و الگوهای WAL را با لاگ‌ها و نمایه‌های آماری مثل pg_stat هم‌راستا کنید. محدودیت اصلی این است که محتوای سطرها را نمی‌بینید و فقط به فراداده دسترسی دارید، اما همین برای ساختن و آزمودن فرضیه‌ها کافی است. در نتیجه، pg_walinspect ابزار کم‌هزینه و امنی برای بهبود observability، کاهش زمان رفع اشکال و فهم عمیق‌تر رفتار PostgreSQL محسوب می‌شود.

#PostgreSQL #WAL #pg_walinspect #DatabaseInternals #Observability #Performance #Replication

🟣لینک مقاله:
https://postgresweekly.com/link/175096/web


👑 @Database_Academy
🔵 عنوان مقاله
PostgreSQL R2DBC Driver 1.1

🟢 خلاصه مقاله:
PostgreSQL R2DBC Driver 1.1 دسترسی Reactive و غیرمسدودکننده به PostgreSQL را برای برنامه‌های Java فراهم می‌کند. با تکیه بر R2DBC و پشتیبانی از backpressure، اجرای کوئری‌ها و استریم نتایج به‌صورت asynchronous انجام می‌شود و زیر بار بالا کارایی و بهره‌وری منابع بهبود می‌یابد. این درایور با Project Reactor، Spring WebFlux و Spring Data R2DBC یکپارچه است و اجازه می‌دهد کل مسیر از HTTP تا دیتابیس Reactive باقی بماند و قابلیت‌هایی مثل ترکیب، لغو و مدیریت جریان‌ها را فراهم می‌کند. نسخه 1.1 بر بلوغ و پایداری تمرکز دارد و با بهبود هم‌خوانی با R2DBC SPI و بهینه‌سازی رفتار تحت فشار، برای استفاده تولیدی مناسب‌تر شده است. اگر معماری شما Reactive است یا به همزمانی بالا و استریم داده نیاز دارید، این درایور انتخاب مناسبی است؛ در سناریوهای ساده و مسدودکننده، JDBC همچنان می‌تواند گزینه‌ای عملی باشد.

#PostgreSQL #R2DBC #Java #SpringWebFlux #ReactiveProgramming #NonBlocking #Databases #Performance

🟣لینک مقاله:
https://postgresweekly.com/link/175405/web


👑 @Database_Academy
🔵 عنوان مقاله
Postgres 18 Released

🟢 خلاصه مقاله:
Postgres 18 طبق برنامه منتشر شد. این نسخه جهش انقلابی نیست، اما مجموعه‌ای از بهبودهای هدفمند ارائه می‌دهد که در عمل به اجرای سریع‌تر کوئری‌ها، استفاده مؤثرتر از ایندکس‌ها، I/O کارآمدتر و نگه‌داری سبک‌تر (VACUUM/autovacuum) منجر می‌شود. بهینه‌سازی‌های تکرار و بازیابی نیز پایداری و توان عملیاتی را برای سناریوهای High Availability بهتر می‌کنند. علاوه بر این، گزینه‌های پیکربندی و پایش شفاف‌تر و سخت‌گیری‌های امنیتی تازه، مدیریت و تیونینگ را ساده‌تر می‌سازد. برای ارتقا، یادداشت‌های نسخه را بررسی کنید، سازگاری اکستنشن‌ها را بسنجید و روی محیط Stage با بار کاری واقعی تست بگیرید.

#Postgres #PostgreSQL #Database #Performance #Release #SQL #OpenSource #DevOps

🟣لینک مقاله:
https://postgresweekly.com/link/174773/web


👑 @Database_Academy
🔵 عنوان مقاله
date and timestamp versions of random(min, max)

🟢 خلاصه مقاله:
این مقاله به دو به‌روزرسانی کاربردی اشاره می‌کند: افزوده‌شدن نسخه‌های مبتنی‌بر نوع‌های date و timestamp برای تابع random(min, max) و نمایش برآوردهای برنامه‌ریز برای گره Memoize در خروجی EXPLAIN. با پشتیبانی جدید random(min, max)، می‌توان مقادیر تصادفی از نوع تاریخ یا زمان را مستقیماً در یک بازه مشخص تولید کرد؛ کاری مفید برای تولید داده‌ی آزمایشی، شبیه‌سازی بار کاری و ناشناس‌سازی داده‌های زمانی بدون نیاز به تبدیل‌های اضافی. همچنین، EXPLAIN اکنون برآوردهای مربوط به Memoize را نشان می‌دهد تا روشن‌تر شود چرا برنامه‌ریز از این گره استفاده کرده و تأثیر تخمینی کش و هزینه‌ها چیست؛ موضوعی که به عیب‌یابی و بهینه‌سازی پرس‌وجوها کمک می‌کند.

#Databases #SQL #EXPLAIN #Memoize #Random #Date #Timestamp #Performance

🟣لینک مقاله:
https://postgresweekly.com/link/175090/web


👑 @Database_Academy
👍1
🔵 عنوان مقاله
Key Operational Enhancements and Integration Options in Postgres 16

🟢 خلاصه مقاله:
این مطلب با تمرکز بر مخاطبان Golang Weekly توضیح می‌دهد که Postgres 16 چه بهبودهایی برای عملیات روزمره و یکپارچه‌سازی با سرویس‌ها آورده است. نویسنده روی حوزه‌های عملی مثل کارایی پایدارتر تحت بار، رفتار بهتر autovacuum، و رصدپذیری دقیق‌تر برای IO و پردازه‌های پس‌زمینه تأکید می‌کند تا تنظیمات و عیب‌یابی سریع‌تر و مطمئن‌تر انجام شود. همچنین به ارتقاهای مرتبط با replication منطقی و سنک‌کردن ایمن‌تر، مدیریت slotها و سناریوهای failover اشاره می‌کند تا پیاده‌سازی‌های HA و چندمنطقه‌ای ساده‌تر شوند. در بخش یکپارچه‌سازی، گزینه‌های Go مانند pgx و database/sql، مدیریت connection pooling با pgxpool یا PgBouncer، اتصال به سامانه‌های رویدادمحور از طریق logical decoding و ابزارهایی مثل Debezium، و الگوهای LISTEN/NOTIFY و FDW مرور می‌شود. جمع‌بندی مقاله: Postgres 16 دردسرهای عملیاتی را کمتر و ادغام با معماری‌های متنوع را ساده‌تر می‌کند و یک چک‌لیست کوتاه برای ارزیابی و ارتقای امن ارائه می‌دهد.

#Postgres16 #PostgreSQL #Golang #Go #Database #Replication #Observability #Performance

🟣لینک مقاله:
https://postgresweekly.com/link/175401/web


👑 @Database_Academy
🔵 عنوان مقاله
memoize planner estimates in EXPLAIN.

🟢 خلاصه مقاله:
**
این مطلب که در شماره اخیر Golang Weekly معرفی شده، درباره memoize کردن برآوردهای planner در EXPLAIN است تا تحلیل پرس‌وجوها سریع‌تر و قابل‌اتکاتر شود. ایده اصلی این است که تخمین‌های میانی (مثل cardinality و هزینه‌ها) بر اساس نسخه نرمال‌شده‌ی بخش‌های پرس‌وجو و ورودی‌های اثرگذار (آمار جداول، وضعیت schema، و تنظیمات planner) ذخیره شوند و در اجرای‌های بعدی EXPLAIN دوباره استفاده شوند. نتیجه: کاهش هزینه محاسبات تکراری، ثبات بیشتر خروجی‌ها، و مقایسه آسان‌تر تغییرات.

در پیاده‌سازی با Go می‌توان با cacheهای سبک، هش‌کردن پرس‌وجوی نرمال‌شده و وضعیت کاتالوگ، و قلاب‌های ابطال (invalidation) قابل‌تنظیم به این هدف رسید؛ این رویکرد برای ابزارهای توسعه، CI و بنچمارک‌ها سودمند است. البته چالش‌ها هم مهم‌اند: کهنگی داده‌های cache با تغییر آمار یا تنظیمات، ضرورت سیاست‌های ابطال شفاف، ترجیحاً cache کردن فقط برآوردها (نه کل plan)، ارائه نشانگرهای hit/miss در خروجی EXPLAIN، و تعیین دامنه و سقف اندازه cache (مثلاً در سطح session).

به طور خلاصه، memoize کردن برآوردهای planner در EXPLAIN چرخه‌های تحلیل را تسریع و نتایج را پایدارتر می‌کند، به شرط آنکه مرزهای cache و سیاست‌های ابطال به‌خوبی مدیریت شوند.

#Golang #Go #EXPLAIN #Database #QueryPlanner #Memoization #Performance #Optimization

🟣لینک مقاله:
https://postgresweekly.com/link/175091/web


👑 @Database_Academy