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

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

ادمین:
@mrbardia72
Download Telegram
🔵 عنوان مقاله
Ratcheting with Postgres CONSTRAINT

🟢 خلاصه مقاله:
خلاصه «ratcheting» روشی برای سفت‌وسخت کردن تدریجی قوانین داده در Postgres با تکیه بر CONSTRAINT است. به‌جای اعمال یک‌باره و پرریسک محدودیت‌ها، ابتدا قواعد را به‌صورت نرم اعمال می‌کنیم (ثبت و پایش تخلفات در اپلیکیشن) و سپس معادل آن‌ها را به‌صورت NOT VALID اضافه می‌کنیم تا فقط نوشتارهای جدید بررسی شوند. بعد از پاک‌سازی و بک‌فیل، با VALIDATE CONSTRAINT قاعده برای کل داده معتبر می‌شود. برای قیود چندردیفی یا چندتراکنشی می‌توان از DEFERRABLE و INITIALLY DEFERRED استفاده کرد. الگوهای رایج شامل تبدیل فیلدهای اختیاری به الزامی با بک‌فیل و سپس SET NOT NULL، افزودن FOREIGN KEY به‌صورت NOT VALID و اعتبارسنجی پس از رفع یتیم‌ها، استفاده از ایندکس‌های UNIQUE جزئی برای یکتایی شرطی، و به‌کارگیری EXCLUDE برای جلوگیری از تداخل‌های زمانی/فضایی است. این رویکرد باعث می‌شود قیود به‌تدریج از اسناد و منطق اپلیکیشن به لایه خود Postgres منتقل شوند و با عملکرد بهتر، ریسک کمتر و سادگی بیشتر، یکپارچگی داده را تضمین کنند.

#Postgres #SQL #DataIntegrity #DatabaseMigrations #Constraints #EXCLUDE #DEFERRABLE #DevOps

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


👑 @Database_Academy
🔥1
🔵 عنوان مقاله
A SQL Heuristic: ORs Are Expensive (10 minute read)

🟢 خلاصه مقاله:
OR در SQL اغلب باعث کندی می‌شود، چون بسیاری از query plannerها برای OR بین ستون‌های مختلف به sequential scan یا index merge/bitmap OR متوسل می‌شوند، در حالی‌که AND به‌طور طبیعی با compound indexها جور است. یک راه مؤثر، بازنویسی OR به چند کوئریِ ایندکس‌پسند و ترکیب آن‌ها با UNION/UNION ALL است تا هر شاخه از ایندکس مناسب خود استفاده کند و زمان اجرا گاهی تا ۱۰۰ برابر کاهش یابد. راه‌حل پایدارتر، بازطراحی schema با extension tables است تا به‌جای OR روی چند خاصیتِ پراکنده، با JOIN به جدول‌های باریک و ایندکس‌شده دسترسی پیدا کنید. همیشه با EXPLAIN/EXPLAIN ANALYZE اندازه‌گیری کنید؛ در جداول کوچک یا OR روی یک ستون (مشابه IN) شاید مشکل نداشته باشید، اما به‌طور کلی: AND را با compound index هماهنگ کنید، از OR بین ستون‌ها بپرهیزید، در صورت لزوم از UNION بهره ببرید و برای مسیرهای پرتردد، بازطراحی schema را در نظر بگیرید.

#SQL #DatabasePerformance #QueryOptimization #Indexes #PostgreSQL #MySQL #DataModeling #EXPLAIN

🟣لینک مقاله:
https://ethanseal.com/articles/ors-are-expensive?utm_source=tldrdata


👑 @Database_Academy
🔵 عنوان مقاله
SkipScan in TimescaleDB: Why DISTINCT Was Slow, How We Built It, and How You Can Use It

🟢 خلاصه مقاله:
SkipScan در TimescaleDB مشکل دیرینه‌ی کندی کوئری‌های DISTINCT را هدف می‌گیرد؛ جایی که برای یافتن مقادیر یکتا، اسکن‌های بزرگ و تکراری روی ایندکس انجام می‌شود. این ویژگی با «پرش» از میان بلوک‌های مقادیر تکراری و رفتن مستقیم به مقدار یکتای بعدی، تعداد خواندن‌ها و مقایسه‌ها را کاهش می‌دهد و DISTINCT و DISTINCT ON را مخصوصاً روی هایپرتیبل‌های بزرگ سریع‌تر می‌کند. برای بهره‌گیری عملی، ایندکس‌های B-tree چندستونه هم‌راستا با کلیدهای DISTINCT و ترتیب ORDER BY بسازید؛ برنامه‌ریز به‌صورت خودکار در الگوهای مناسب SkipScan را انتخاب می‌کند و در غیر این صورت به مسیرهای عادی برمی‌گردد. بیشترین سود زمانی است که داده‌ها تکرار زیاد و هم‌جواری مناسب در ایندکس داشته باشند.

هم‌زمان، Aksman و Hein از TigerData با همراهی Sebastian Insausti به بهبودهای عملیاتی و گزینه‌های یکپارچه‌سازی در Postgres 16 می‌پردازند؛ از رصد و تنظیم‌پذیری بهتر گرفته تا ساده‌تر شدن نگهداری و همگام‌سازی و تقویت اکوسیستم الحاقات و اتصال به سامانه‌های دیگر. این تغییرات عملیاتی، در کنار بهینه‌سازی‌هایی مانند SkipScan، Postgres 16 را به پایه‌ای توانمندتر برای بارهای تحلیلی و زمان‌محور تبدیل می‌کند.

#TimescaleDB #Postgres16 #SkipScan #DISTINCT #DatabasePerformance #TimeSeries #SQL #Postgres

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


👑 @Database_Academy
🔵 عنوان مقاله
How to Do UPDATE ... LIMIT

🟢 خلاصه مقاله:
در Postgres نمی‌توان مستقیم از UPDATE ... LIMIT یا DELETE ... LIMIT استفاده کرد؛ هرچند در برخی لهجه‌های SQL مثل MySQL این امکان وجود دارد. راه‌حل استاندارد این است که ابتدا در یک زیرکوئری یا CTE با ORDER BY و LIMIT، شناسهٔ ردیف‌های هدف را انتخاب کنید و سپس با UPDATE/DELETE روی همان شناسه‌ها عمل کنید. برای محیط‌های همزمان، استفاده از SELECT ... FOR UPDATE SKIP LOCKED در زیرکوئری باعث می‌شود هر پردازش فقط ردیف‌های قفل‌نشده را بردارد و تداخل رخ ندهد. حتماً ORDER BY بگذارید تا انتخاب N ردیف قابل پیش‌بینی باشد و برای کارایی، ایندکس مناسب روی فیلترها و مرتب‌سازی‌ها داشته باشید. در حجم‌های بزرگ، عملیات را به صورت batch تکراری انجام دهید تا از تراکنش‌های طولانی و فشار روی سیستم جلوگیری شود.

#Postgres #SQL #UPDATE #DELETE #LIMIT #CTE #SkipLocked #MySQL

🟣لینک مقاله:
https://postgresweekly.com/link/175093/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
🔵 عنوان مقاله
PostGIS Performance: pg_stat_statements and Postgres Tuning

🟢 خلاصه مقاله:
**این مقاله نشان می‌دهد چطور با استفاده از PostGIS روی Postgres می‌توان کارایی پرس‌وجوهای مکانی را بهبود داد. محور اصلی کار، اندازه‌گیری دقیق با pg_stat_statements برای شناسایی پرهزینه‌ترین پرس‌وجوها و سپس تحلیل آن‌ها با EXPLAIN/ANALYZE است. توصیه‌های کلیدی شامل انتخاب درست geometry یا geography، ساخت ایندکس‌های GiST/SP-GiST، نوشتن شرط‌های قابل استفاده توسط ایندکس (مثل ST_Intersects و محدوده‌های جعبه‌ای)، و اجرای VACUUM/ANALYZE پس از بارگذاری‌های حجیم است. در بخش تنظیمات Postgres هم به shared_buffers، effective_cache_size، work_mem، موازی‌سازی، تنظیمات autovacuum و در صورت نیاز پارتیشن‌بندی اشاره می‌شود. برای سرویس‌های Go (به نقل از Golang Weekly)، استفاده از pooling مناسب، جلوگیری از الگوهای N+1، Batch کردن عملیات، بهره‌گیری از COPY و تعیین statement_timeout توصیه شده است. رویکرد کلی: اندازه‌گیری، اعمال تغییرات هدفمند، و اعتبارسنجی مداوم برای رسیدن به کارایی پایدار و سریع‌تر.

#PostGIS #PostgreSQL #pg_stat_statements #DatabaseTuning #Geospatial #Golang #Performance #SQL

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


👑 @Database_Academy
🔵 عنوان مقاله
Postgres 18: OLD and NEW Rows in the RETURNING Clause

🟢 خلاصه مقاله:
Postgres 18 با تمرکز بر سه حوزه پیش می‌رود: ارگونومی توسعه، قابلیت مشاهده، و بارگذاری داده. پشتیبانی از ارجاع به ردیف‌های OLD و NEW در RETURNING باعث می‌شود نسخه‌های قبل و بعد از تغییر را در همان دستور SQL بگیرید؛ این کار لاگ‌برداری، ثبت تغییرات و منطق حل تعارض را ساده‌تر و کم‌هزینه‌تر می‌کند. بهبودهای COPY—به روایت Brandur Leach—کار با ورودی/خروجی‌های حجیم را خوش‌دست‌تر می‌کند و با پیام‌های واضح‌تر و پیش‌فرض‌های امن‌تر، خطاهای رایج را کم می‌کند. در سطح پایش، Deepak Mahto و Cédric Villemain به ارتقاهای Cumulative Statistics می‌پردازند که با شمارنده‌های منسجم‌تر و سربار کمتر، عیب‌یابی و تنظیم عملکرد را آسان‌تر می‌سازد. حاصل این تغییرات، ترکیبی از تجربه توسعه‌دهنده بهتر و بینش عملیاتی عمیق‌تر در Postgres 18 است.

#Postgres18 #PostgreSQL #RETURNING #COPY #SQL #Database #CumulativeStatistics #OpenSource

🟣لینک مقاله:
https://postgresweekly.com/link/175099/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
🔵 عنوان مقاله
pqr.sql: Generate QR Codes with Pure SQL in Postgres

🟢 خلاصه مقاله:
**pqr.sql یک ایده‌ی خلاقانه است که نشان می‌دهد می‌توان QR Code را تنها با SQL و مستقیماً داخل Postgres تولید کرد. این کار بدون افزونه یا کد اپلیکیشن انجام می‌شود و برای محیط‌های محدود یا سناریوهای خودبسنده مفید است و جنبه آموزشی خوبی برای توانمندی‌های SQL در Postgres دارد. با این حال، به چندصد خط SQL نیاز دارد و برای تولید عملیاتی جایگزین کتابخانه‌های تخصصی نیست؛ اما نمونه‌ای جذاب با کاربردهای غیربدیهی است.

#Postgres #PostgreSQL #SQL #QRCode #PureSQL #Databases #SQLTricks

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


👑 @Database_Academy