Database Labdon
882 subscribers
37 photos
3 videos
1 file
899 links
🕸 Database Academy

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

ادمین:
@mrbardia72
Download Telegram
🔵 عنوان مقاله
Benchmarking Postgres 17 vs 18

🟢 خلاصه مقاله:
نویسنده یک بنچمارک گسترده و دقیق بین Postgres 17 و Postgres 18 با ۹۶ ترکیب مختلف انجام داده است. نتیجه کلی امیدوارکننده است: Postgres 18 در اغلب سناریوها بهبود عملکرد محسوسی نشان می‌دهد. همچنین دیسک‌های محلی بهترین نتایج را ارائه می‌کنند و انتخاب آن‌ها برای کارهای دیتابیسی مزیت دارد. در عین حال، تنظیمات دستی همچنان اثرگذار است و نباید فقط به مقادیر پیش‌فرض بسنده کرد. جمع‌بندی: ارتقا به Postgres 18 ارزشمند است، اما بهتر است در محیط خودتان تست کنید، از ذخیره‌سازی محلی استفاده کنید و با تیونینگ هدفمند حداکثر بهره را بگیرید.

#Postgres #PostgreSQL #Benchmarking #DatabasePerformance #Postgres18 #PerformanceTesting #Tuning #Storage

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


👑 @Database_Academy
🔵 عنوان مقاله
Understanding and Setting Postgres JDBC Fetch Size

🟢 خلاصه مقاله:
این مقاله اهمیت تنظیم درست Fetch Size در JDBC برای Postgres را توضیح می‌دهد: مقدار پیش‌فرض 0 عملاً کل نتایج را یک‌باره در حافظه می‌ریزد و برای حجم‌های بزرگ خطرناک است. برای استریم واقعی باید auto-commit را خاموش کنید (setAutoCommit(false)) و روی Statement/PreparedStatement مقدار setFetchSize(n) بگذارید یا از defaultRowFetchSize در اتصال استفاده کنید؛ در حالت auto-commit فعال، درایور از cursor سمت سرور استفاده نمی‌کند و Fetch Size نادیده گرفته می‌شود. انتخاب مقدار به اندازه ردیف‌ها، تأخیر شبکه و حافظه بستگی دارد؛ معمولاً 100 تا 1000 شروع خوبی است و برای ردیف‌های بزرگ (JSON/BYTEA) بهتر است مقدار کوچک‌تر باشد. در Spring JdbcTemplate و jOOQ می‌توانید fetchSize را مستقیم تنظیم کنید؛ در JPA/Hibernate برای استریم با PostgreSQL علاوه بر hibernate.jdbc.fetch_size معمولاً نیاز به ResultSet رو به جلو و auto-commit خاموش دارید. حواستان باشد استریم باعث باز ماندن تراکنش می‌شود و می‌تواند VACUUM را به تأخیر بیندازد؛ پس جریان‌ها را کوتاه نگه دارید و برای سناریوهای تعاملی از صفحه‌بندی استفاده کنید. این موضوع اخیراً در Golang Weekly برجسته شده است و برای تیم‌هایی که Java و Go را ترکیب می‌کنند کاربردی است.

#PostgreSQL #JDBC #FetchSize #DatabasePerformance #Java #GolangWeekly #Streaming #PerformanceTuning

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


👑 @Database_Academy
🔵 عنوان مقاله
Pipelining Comes to psql in Postgres 18

🟢 خلاصه مقاله:
** در Postgres 18، ابزار psql فرمان‌های داخلی برای فعال‌سازی و کنترل pipelining در اسکریپت‌های SQL اضافه کرده است. با این قابلیت، چندین کوئری پشت‌سرهم ارسال می‌شوند و منتظر پاسخ تک‌به‌تک نمی‌مانند؛ در نتیجه رفت‌وبرگشت‌های شبکه کمتر و زمان اجرا کوتاه‌تر می‌شود. به‌گفته Daniel، این کار می‌تواند بهره‌وری و throughput کوئری‌ها را به‌طور چشمگیری افزایش دهد، به‌ویژه در اسکریپت‌های پر از دستورات کوچک.

این ویژگی برای کارهای حجیم و خودکار مانند بارگذاری داده، پردازش‌های ETL، تحلیل‌ها و مهاجرت‌های اسکیما بسیار مفید است. می‌توان pipelining را فقط در بخش‌های مناسب یک اسکریپت فعال کرد و برای اطمینان از سازگاری و بازگردانی، مرزبندی تراکنش‌ها و مدیریت خطا را دقیق انجام داد. در صورت عدم استفاده، رفتار psql مانند قبل باقی می‌ماند و با سایر تکنیک‌های بهینه‌سازی سرور تکمیل می‌شود، نه اینکه جایگزین آن‌ها باشد.

#Postgres
#psql
#Pipelining
#SQL
#DatabasePerformance
#PostgreSQL18
#Throughput
#ETL

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


👑 @Database_Academy
🔵 عنوان مقاله
SQL Shader (Tool)

🟢 خلاصه مقاله:
SQL Shader ابزاری مرورگری بر پایه DuckDB-WASM است که کوئری‌های SQL را به گرافیک‌های رویه‌ایِ بلادرنگ تبدیل می‌کند تا رفتار و کارایی موتور پایگاه‌داده را به‌صورت بصری کاوش و درک کنید. همه‌چیز به‌صورت محلی در مرورگر اجرا می‌شود، بدون نیاز به سرور و با حفظ حریم خصوصی. با تغییر کوئری‌ها—مثل فیلترها، نوع join یا اندازه داده—نمایش‌های بصری فوراً تغییر می‌کنند و شاخص‌هایی مانند زمان اجرا، تعداد ردیف‌ها یا الگوی عملگرها را به شکل قابل مشاهده نشان می‌دهند. این ابزار برای آموزش مفاهیم پایگاه‌داده، نمایش تعاملی عملکرد، و آزمایش سریع رفتار کوئری‌ها بسیار کاربردی است.

#SQL #DuckDB #WASM #WebAssembly #DataVisualization #DatabasePerformance #BrowserTools #SQLShader

🟣لینک مقاله:
https://dmkskd.github.io/sql-shader/?utm_source=tldrdata


👑 @Database_Academy
🔵 عنوان مقاله
The Benefits of a DESCending Index

🟢 خلاصه مقاله:
گذشته از کاربرد شناخته‌شده‌ی DESC در همخوان‌سازی ایندکس با ORDER BYهای ترکیبی، در برخی سناریوهای خاص یک ایندکسِ نزولی می‌تواند هنگام ساخت و درج، فضای کمتری اشغال کند. وقتی الگوی درج داده‌ها با جهت مرتب‌سازی ایندکس هم‌راستا باشد، احتمال شکاف صفحه کمتر می‌شود و چیدمان برگ‌ها فشرده‌تر می‌ماند؛ نتیجه می‌تواند ایندکسی کوچک‌تر و با محلیّت حافظه بهتر باشد.

از نظر اجرا هم مزیتی وجود دارد: برای تولید همان ترتیب نتایج، یک اسکن رو‌به‌جلو روی ایندکسِ نزولی معمولاً از اسکن رو‌به‌عقب روی ایندکسِ صعودی کاراتر است، چون با پیش‌خوانی دیسک و الگوهای کش سازگارتر است. بنابراین برای پرس‌وجوهای «جدیدترین‌ها اول» مثل ORDER BY created_at DESC همراه با LIMIT، انتخاب ایندکس نزولی اغلب اجرای پایدارتر و سریع‌تری می‌دهد. جمع‌بندی: جهت ایندکس را بر اساس الگوی غالب ORDER BY انتخاب و هر دو حالت را با EXPLAIN روی داده‌های واقعی بسنجید.

#PostgreSQL #Indexing #DESC #ORDERBY #QueryOptimization #DatabasePerformance #BTree #TopN

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


👑 @Database_Academy
🔵 عنوان مقاله
Postgres 18's UUIDv7: Faster and Secure Time-Ordered IDs

🟢 خلاصه مقاله:
**پشتیبانی از UUIDv7 در Postgres 18 شناسه‌هایی زمان‌مرتب ارائه می‌دهد که برخلاف UUIDv4 باعث پراکندگی شدید ایندکس‌ها نمی‌شوند. بخش زمان در ابتدای UUIDv7 باعث می‌شود درج‌ها عمدتاً به انتهای B-tree اضافه شوند و از شکستن صفحه‌ها، افت کش و ناپایداری توان نوشتن جلوگیری شود. هم‌زمان، بخش‌های تصادفیِ کافی باقی می‌ماند تا شناسه‌ها منحصربه‌فرد، غیرقابل پیش‌بینی و مناسب برای محیط‌های توزیع‌شده باشند؛ بدون افشای جزئیات سخت‌افزاری مانند نسخه‌های قدیمی‌تر.

برای تیم‌های Go که از Postgres استفاده می‌کنند، این تغییر به‌خوبی با الگوهای متداول سرویس‌های رویدادمحور، لاگ‌های افزایشی و نوشتن در مقیاس افقی سازگار است. تولید UUIDv7 در لایه اپلیکیشن و ذخیره آن در ستون نوع uuid ساده است و بسیاری از کتابخانه‌های Go از آن پشتیبانی می‌کنند. برای مهاجرت، جدول‌های جدید می‌توانند مستقیماً از UUIDv7 استفاده کنند و جدول‌های موجود می‌توانند به‌تدریج تغییر کنند؛ تنها به صحت و یکنواختی ساعت سرورها برای حفظ ترتیب توجه کنید و برای نیازهای زمانی دقیق همچنان از ستون‌های timestamp بهره بگیرید.

به‌طور خلاصه، UUIDv7 در Postgres 18 ترکیبی از عملکرد بهتر درج و ایندکس، سادگی عملیاتی و امنیت بیشتر را فراهم می‌کند؛ همان‌طور که در Golang Weekly نیز بر هم‌سویی طبیعی آن با معماری سرویس‌های Go تاکید شده است.

#Postgres #PostgreSQL #UUIDv7 #Go #Golang #DatabasePerformance #Scalability

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


👑 @Database_Academy
🔵 عنوان مقاله
pg_ivm 1.13: Incremental View Maintenance (IVM) Extension

🟢 خلاصه مقاله:
pg_ivm 1.13 یک افزونه برای PostgreSQL است که رویکرد Incremental View Maintenance (IVM) را به کار می‌گیرد تا به‌جای بازمحاسبه کامل، فقط تغییرات لازم را روی materialized view اعمال کند. در مقایسه با REFRESH MATERIALIZED VIEW، این روش با به‌روزرسانی‌های افزایشی باعث کاهش زمان، مصرف منابع و قفل‌گذاری می‌شود و به‌ویژه برای پایگاه‌های داده حجیم، داشبوردهای تحلیلی و سناریوهای نزدیک به زمان واقعی مفید است.

#PostgreSQL #pg_ivm #IVM #MaterializedViews #DatabasePerformance #DataEngineering #IncrementalUpdates

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


👑 @Database_Academy
🔵 عنوان مقاله
Don't Give Postgres Too Much Memory

🟢 خلاصه مقاله:
خلاصه‌ای از دیدگاه Tomas این است که در Postgres همیشه «حافظه بیشتر=بهتر» نیست. بالا بردن بی‌محابای maintenance_work_mem و work_mem می‌تواند اندازه مجموعه کاری را بزرگ‌تر از CPU cache کند و با افزایش cache miss، سرعت مرتب‌سازی و هش را کم کند. علاوه بر آن، تخصیص‌های بزرگ، بار مدیریت حافظه روی OS را زیاد می‌کند و در بار همزمان، چون work_mem به‌ازای هر نود و هر کوئری اعمال می‌شود، مصرف واقعی حافظه چندبرابر شده و افت کارایی رخ می‌دهد. نتیجه عملی: مقادیر را معقول و مرحله‌ای تنظیم کنید، با سناریوهای واقعی بنچمارک بگیرید، در صورت نیاز به‌صورت موردی با SET مقدار work_mem را برای عملیات سنگین بالا ببرید، و به تعامل CPU cache و مدیریت حافظه OS توجه کنید؛ همیشه مقدار بیشتر سریع‌تر نیست.

#Postgres #PostgreSQL #DatabasePerformance #work_mem #maintenance_work_mem #CPUCaches #OSMemory

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


👑 @Database_Academy
🔵 عنوان مقاله
pg_qualstats: Extension for Collecting Statistics About Predicates

🟢 خلاصه مقاله:
pg_qualstats یک افزونه برای PostgreSQL است که آمار مربوط به استفاده از گزاره‌ها در WHERE و JOIN را جمع‌آوری می‌کند تا نشان دهد کدام فیلترها در عمل بیشترین استفاده و بیشترین اثر را دارند. این داده‌ها به شما کمک می‌کند برای بار کاری واقعی خود، ایندکس‌های هدفمند (تکی، ترکیبی، جزئی یا بر اساس عبارت) طراحی کنید و با کاهش I/O و تأخیر، کارایی را بهبود دهید. می‌توانید نتایج را مستقیم از نماهای افزونه ببینید یا از طریق POWA (Postgres Workload Analyzer) آن‌ها را تحلیل و اولویت‌بندی کنید. در کنار ابزاری مثل pg_stat_statements، این افزونه مشخص می‌کند کدام بخش از یک کوئری پرهزینه است و در نتیجه یافتن ایندکس‌های از دست‌رفته و ارزیابی اثربخشی ایندکس‌های جدید ساده‌تر می‌شود.

#PostgreSQL #pg_qualstats #POWA #PostgresWorkloadAnalyzer #QueryOptimization #Indexing #DatabasePerformance

🟣لینک مقاله:
https://postgresweekly.com/link/175733/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