Database Labdon – Telegram
Database Labdon
835 subscribers
33 photos
3 videos
1 file
821 links
🕸 Database Academy

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

ادمین:
@mrbardia72
Download Telegram
🔵 عنوان مقاله
full feature set here

🟢 خلاصه مقاله:
این به‌روزرسانی اعلام می‌کند که مجموعه کامل قابلیت‌ها اکنون به‌صورت عمومی در دسترس است و به‌طور رسمی از Postgres 18 پشتیبانی می‌کند. تمام مسیرهای عملیاتی—from provisioning و migrations تا monitoring، HA، backups، pooling و performance tuning—در برابر Postgres 18 اعتبارسنجی شده‌اند و برای اکثر اپلیکیشن‌ها نیازی به تغییر کد نیست. برای ارتقا، راهنمای گام‌به‌گام برای in‑place و blue/green همراه با preflight checks، الگوهای rollout و مسیر بازگشت فراهم است؛ فقط توجه داشته باشید برخی extensions شخص‌ثالث ممکن است با Postgres 18 کمی عقب باشند. این نسخه مزایای بهبودهای عملکردی، پایداری و امنیتی را ارائه می‌دهد؛ تنظیمات جدید به‌صورت محافظه‌کارانه فعال می‌شوند و گزینه‌های پیشرفته قابل تنظیم هستند. پشتیبانی در محیط‌های cloud و on‑prem عرضه شده، تصاویر و قالب‌های CI/CD به‌روزرسانی شده‌اند و اسناد و راهنمای مهاجرت آماده است؛ تیم پشتیبانی برای ارزیابی، پایلوت و استقرار تولید در دسترس است.

#Postgres18 #PostgreSQL #Database #Compatibility #Upgrade #DevOps #Release #DBA

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


👑 @Database_Academy
🔵 عنوان مقاله
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
🔵 عنوان مقاله
Postgres Migrations Using Logical Replication

🟢 خلاصه مقاله:
** مهاجرت به Postgres با تکیه بر Logical Replication به الگوی رایج برای جابه‌جایی کم‌وقفه تبدیل شده است؛ داده‌ها به‌صورت جریان تغییرات منتقل می‌شوند، اسکیما از پیش هماهنگ می‌شود و کات‌اور کنترل‌شده انجام می‌گیرد. در خبرها، یادداشت Elizabeth Christensen به تیتر طنزآمیز The Register درباره IBM و CockroachDB اشاره می‌کند، اما اصل ماجرا این است که IBM به ارائه گزینه‌ای Postgres‑like روی مین‌فریم فکر می‌کند؛ نشانه‌ای از پذیرش گسترده اکوسیستم Postgres و امکان استقرارهای ناهمگون که با Logical Replication به مهاجرت‌های مرحله‌ای کمک می‌کند. در بُعد کارایی، Aksman و Hein از TigerData در TimescaleDB نشان می‌دهند چرا DISTINCT روی داده‌های سری‌زمانی کند می‌شود و چگونه SkipScan با «پرش» در محدوده‌های ایندکس، این کوئری‌ها را سریع‌تر و بهینه‌تر می‌کند. همچنین Sebastian Insausti به بهبودهای عملیاتی و گزینه‌های یکپارچه‌سازی در Postgres 16 می‌پردازد که مدیریت عملیات، مشاهده‌پذیری و معماری‌های هیبریدی مبتنی بر Logical Replication را ساده‌تر می‌کند. توصیه عملی: همسان‌سازی اسکیما، توجه به sequences/constraints/triggers، کوتاه نگه‌داشتن تراکنش‌ها برای کاهش lag، رصد دقیق تاخیر اعمال، تمرین کات‌اور و داشتن مسیر بازگشت تا اطمینان از صحت داده‌ها.

#Postgres
#LogicalReplication
#TimescaleDB
#SkipScan
#CockroachDB
#IBM
#PostgreSQL
#Postgres16

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


👑 @Database_Academy
🔵 عنوان مقاله
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
🔵 عنوان مقاله
Hands on Postgres 18: Async I/O, B-Tree Skip Scan, UUIDv7

🟢 خلاصه مقاله:
بنیان‌گذار pganalyze در یک وبینار، قابلیت‌های مهم Postgres 18 را به‌صورت عملی مرور می‌کند؛ از جمله Async I/O، B-Tree Skip Scan و UUIDv7. بخش Async I/O (از ۴:۲۰ تا ۲۲:۳۰) برجسته‌تر است و نشان می‌دهد چگونه هم‌پوشانی محاسبه و ورودی/خروجی می‌تواند تأخیر را کم و توان عملیاتی را در بارهای I/O-محور افزایش دهد. B-Tree Skip Scan اسکن روی ایندکس‌های مرکب را وقتی فیلتر شامل ستون اول نیست کاراتر می‌کند و هزینه پرس‌وجو را پایین می‌آورد. UUIDv7 نیز با نظم زمانی بهتر، locality ایندکس را بهبود می‌دهد و درج‌ها را پیوسته‌تر می‌کند. نتیجه اینکه این وبینار راهنمایی عملی برای ارزیابی و به‌کارگیری قابلیت‌های جدید Postgres 18 ارائه می‌دهد، و بخش Async I/O ارزش تماشای ویژه‌ای دارد.

#Postgres18 #PostgreSQL #AsyncIO #BTree #UUIDv7 #DatabasePerformance #pganalyze

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


👑 @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
Forwarded from AI Labdon
اگه برنامه نویس هستید و از هوش مصنوعی برای کدنویسی استفاده می‌کنید، واقعاً به خودتون لطف می‌کنید که OpenSpec رو چک کنید. این ابزار به شما کمک می‌کنه کنترل کامل پروژه رو دست بگیرید و از AI به عنوان یک همکار قابل اعتماد استفاده کنید!

تا حالا با دستیارهای کدنویسی هوش مصنوعی (مثل Cursor یا Copilot) کار کردید و به جای چیزی که دقیقاً در ذهن داشتید، یک چیز کاملاً دیگه تحویل گرفتید؟ یا یک بخش رو نوشته و یک بخش دیگه رو براتون خراب کرده

من جدیدا ابزاری رو پیدا کردم به اسم OpenSpec که داره این بازی رو برای همیشه عوض می‌کنه.

ایده‌اش ساده و ناب هست: شما و هوش مصنوعی، قبل از نوشتن حتی یک خط کد، روی «چیزی که باید ساخته بشه» به توافق کامل می‌رسید.

دیگه خبری از پرامپت‌های مبهم در چت و خروجی‌های غیرقابل پیش‌بینی نیست. OpenSpec یک فرآیند کاری سبک و قدرتمند اضافه می‌کنه که پروژه‌ها رو اینطوری پیش می‌بره:

۱. پیشنهاد تغییر (Change Proposal): شما به AI می‌گید چه قابلیتی رو می‌خواید اضافه کنید. AI یک ساختار کامل از مشخصات، وظایف و پیشنهادها رو براتون می‌سازه.

۲. بازبینی و هماهنگی: شما و AI با هم مشخصات رو دقیق می‌کنید تا همه چیز شفاف و بدون ابهام باشه.

۳. پیاده‌سازی: AI بر اساس مشخصات نهایی و توافق شده، کدنویسی رو انجام می‌ده.

۴. آرشیو: بعد از اتمام کار، تغییرات به آرشیو منتقل می‌شن و مشخصات اصلی پروژه رو به‌روز می‌کنن.

چرا این ابزار به خوبی جواب میده 
- بدون نیاز به کلید API: نصب کن و استفاده کن. ساده و سریع.
- با ابزارهای فعلی شما کار می‌کنه: با Claude Code, Cursor, GitHub Copilot, Windsurf و ده‌ها ابزار دیگه یکپارچه می‌شه.
- قابل پیش‌بینی و شفاف: دیگه نمی‌خواد حدس بزنید AI چی می‌سازه. همه چیز از قبل مشخصه.
- عالی برای پروژه‌های موجود: نه فقط برای پروژه‌های جدید، بلکه برای تغییر و توسعه کدهای قدیمی هم عالیه.
- مستندسازی خودکار: هر تغییری با مشخصات و وظایفش ثبت می‌شه و یک سند زنده از پروژه می‌سازه.

اینم آدرس گیتهابش که همه چیز اماده یک جا هست!
https://github.com/Fission-AI/OpenSpec

اگر نتونستنید دستی نصبش کنید ، میتونید فایل README[.]md رو کپی کنید ، بدید به همون ابزار Ai که براتون کد میزنه مثل Claude Code, Cursor, GitHub Copilot ، بگید نصبش کن!

<POURYA/>
کلید فراموش‌شده بهینه‌سازی دیتابیس : Collation در MySQL
به عنوان برنامه‌نویس، همیشه روی ایندکس و کوئری‌ها تمرکز می‌کنیم، اما یک تنظیم ساده در دیتابیس می‌تواند همه چیز را تغییر دهد: Collation
Collation چیست؟
تعیین می‌کند MySQL چگونه داده‌های متنی را مقایسه و مرتب‌سازی می‌کند.
انتخاب اشتباه = مشکلات پنهان
دو نوع اصلی:

نوع یک : ci) Case-Insensitive_)
مقایسه‌ها بدون توجه به حروف بزرگ و کوچک انجام می‌شود. برای مثال کوئری زیر همه ی مواردی مثل ali , Ali , ALI را برمی گرداند.
SELECT * FROM users WHERE username = 'ALI'
در این مثال collation ستون username برابر utf8mb4_unicode_ci می باشد.

نوع دو : bin) Case-Sensitive_)
مقایسه‌ها حساس به حروف بزرگ و کوچک است. برای مثال کوئری زیر فقط ALI
را برمی گرداند.
SELECT * FROM users WHERE username = 'ALI'
در این مثال collation ستون username برابر utf8mb4_bin می باشد.

چرا مهم است؟
عملکرد: collationهای _bin معمولاً سریع‌ترند.
دقت: اگر حساسیت به حروف بزرگ/کوچک مهم است، _bin ضروری است.
یکپارچگی داده: از ذخیره مقادیر تکراری ناخواسته جلوگیری می‌کند.

نکته طلایی:
قبل از طراحی جدول، از خود بپرسید:
"آیا در این فیلد، 'Ali' با 'ali' تفاوت دارد؟"
پاسخ این سؤال، collation مناسب را به شما می‌گوید.


<Babak Mirhosseini/>
🔵 عنوان مقاله
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
🔵 عنوان مقاله
results of its latest State of Developer Ecosystem Report

🟢 خلاصه مقاله:
گزارش جدید State of Developer Ecosystem از JetBrains نشان می‌دهد که برای نخستین بار، Postgres از MySQL در اکوسیستم JetBrains محبوب‌تر شده است. این تغییر حاکی از جابه‌جایی ترجیحات توسعه‌دهندگان به سمت قابلیت‌ها و انعطاف‌پذیری Postgres است؛ هرچند MySQL همچنان در بسیاری از محیط‌های وب و پروژه‌های قدیمی نقش پررنگی دارد. ابزارها و ادغام‌های اکوسیستم JetBrains و گسترش سرویس‌های ابری مدیریت‌شده نیز می‌تواند در این روند مؤثر بوده باشد و نشان می‌دهد انتخاب پایگاه‌داده بیش از پیش بر اساس تناسب با نیاز هر پروژه انجام می‌شود.

#JetBrains #Postgres #MySQL #DeveloperEcosystem #Database #StateOfDeveloperEcosystem #SoftwareTrends

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


👑 @Database_Academy
🔵 عنوان مقاله
A Postgres Trip Report from PGConf NYC 2025

🟢 خلاصه مقاله:
کلر، میزبان پادکست Talking Postgres، دو هفته پس از برگزاری موفق PGConf NYC 2025 گزارشی مفصل و صریح منتشر کرده است؛ او علاوه بر بیان برداشت‌ها و روندهای برجسته و گفتگوهایش با اعضای جامعه، با مجموعه‌ای از عکس‌ها حال‌وهوای رویداد را برای کسانی که حضور نداشتند زنده می‌کند. این گزارش بدون ورود به ریزجزئیات جلسات، روی نکات کاربردی، روندهای قابل‌توجه و حال‌وهوای رو‌به‌رشد جامعه Postgres تمرکز دارد و برای تازه‌واردها و متخصصان به‌طور یکسان مفید است.

#Postgres #PGConfNYC #PGConf2025 #Databases #OpenSource #Conference #TalkingPostgres

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


👑 @Database_Academy
2🍾1
Forwarded from Future Pulse Persian
دارم پادکست پاول دوروف مال تلگرام رو میبینم

نکته جالبش اینجا اگر برادر نابغش نبود هیچ وقت تلگرامی وجود نداشت

نکته دیگه اینه اگر دقت کرده باشید پاول برعکس مارک زاکربرگ ، ایلان ماسک و . . .

زندگی خیلی لاکچری داره ولی ایلان و زاکربرگ همیشه ساده پوشن و خیلی زنی بی آلایشی از خودشون نشون میدن

حتی مارک و ایلان نهایتا ۶ تا ۸  ساعت میخوابن و پاول ۱۲ ساعت

دلیلش از نظر من خیلی جالبه

ایلان و زاکربرگ تمام سهام شرکتشون برای خودشون نیست! سرمایه گذار های بزرگی پشتشونه و هروقت بیان خودشون رو اینطور نشون بدن قطعابا فشار زیادی مواجه میشن

ولی پاول مالک خودش هست و برادرش و کلا ۴۰ برنامه نویس

هیچ وقت هم جواب به کسی نمیده

نکات خیلی زیادی داره این شخص پیشنهاد میکنم حتما درموردش مطالعه کنید

https://www.youtube.com/watch?v=qjPH9njnaVU
2
🔵 عنوان مقاله
Postgres 18 and Beyond: From AIO to Direct IO?

🟢 خلاصه مقاله:
Postgres 18 پشتیبانی از asynchronous IO را اضافه می‌کند تا خواندن/نوشتن‌ها بدون بلوکه‌شدن انجام شوند و کارایی و پایداری تأخیر تحت فشار بار بهتر شود. اکنون این پرسش مطرح است که آیا با Direct IO و دور زدن کامل OS caching می‌توان عملکرد را باز هم بهبود داد؟ مزیت آن حذف دوباره‌کش کردن و کنترل دقیق‌تر کش است، اما در عوض پیچیدگی بالاتر، نیاز به هم‌ترازی، و از دست‌دادن قابلیت‌هایی مثل readahead و writeback هسته را به‌همراه دارد. رویکرد محتمل، راهکار ترکیبی است: تکیه بر OS caching به‌صورت پیش‌فرض و استفاده گزینشی از Direct IO برای اسکن‌های بزرگ، فایل‌های موقت و بارهای تحلیلی. مسیر بعد از نسخه ۱۸ نیز شامل یکپارچه‌سازی عمیق‌تر با io_uring، پیش‌واکشی هوشمند و گزینه‌های Direct IO قابل پیکربندی خواهد بود.

#Postgres #PostgreSQL #AIO #DirectIO #DatabasePerformance #OSCache #io_uring #NVMe

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


👑 @Database_Academy
1
🔵 عنوان مقاله
Visualize Data Lineage Using Amazon SageMaker Catalog for Amazon EMR, AWS Glue, and Amazon Redshift (5 minute read)

🟢 خلاصه مقاله:
قابلیت جدید Amazon SageMaker Unified Studio نمایش خودکار و سرتاسری data lineage را در سراسر AWS Glue، Amazon Redshift و Amazon EMR فراهم می‌کند و تصویری یکپارچه از مسیر ورود، تبدیل و مصرف داده‌ها در تحلیل و ML ارائه می‌دهد. هسته این راهکار، SageMaker Catalog سازگار با OpenLineage است که رویدادهای lineage را ثبت و نسخه‌بندی می‌کند تا تاریخچه‌ای قابل‌اتکا از تبدیلات و تکامل دارایی‌های داده ساخته شود. نتیجه این کار، ردیابی عمیق، ممیزی دقیق و امکان مقایسه تاریخی است؛ از تحلیل اثر تغییرات و اشکال‌زدایی تا بازتولید نتایج و رعایت حاکمیت داده—all در یک نما و بدون نیاز به اتصال‌های سفارشی بین سرویس‌ها.

#DataLineage #AmazonSageMaker #AWSGlue #AmazonRedshift #AmazonEMR #OpenLineage #DataGovernance #MLOps

🟣لینک مقاله:
https://aws.amazon.com/blogs/big-data/visualize-data-lineage-using-amazon-sagemaker-catalog-for-amazon-emr-aws-glue-and-amazon-redshift/?utm_source=tldrdata


👑 @Database_Academy
2
🔵 عنوان مقاله
Inside Husky's query engine: Real-time access to 100 trillion events (10 minute read)

🟢 خلاصه مقاله:
Husky از Datadog با جداسازی سه بخش Planner، Router و Executor، اجرای پرس‌وجوها را در مقیاس بسیار بزرگ و به‌صورت بی‌درنگ ممکن می‌کند. Planner پرس‌وجو را به گراف منطقی از stageها تبدیل می‌کند، آن را به segmentهای قابل اجرا تقسیم کرده و برنامهٔ اجرا تولید می‌کند. Router براساس قواعد و شرایط زمان اجرا، هر segment را به backend مناسب مسیردهی می‌کند تا هم‌زمانی بالا، توازن بار و انعطاف در انتخاب مسیر تضمین شود. Executor کارها را به موتورهای تخصصی مانند SQL engine و custom operators می‌فرستد و نتایج موازی را ترکیب می‌کند. این تفکیک ماژولار باعث مقیاس‌پذیری، امکان اتصال backendهای جدید و بهینه‌سازی پویا برای هر پرس‌وجو می‌شود و دسترسی بی‌درنگ به حجم عظیمی از رویدادها را فراهم می‌کند.

#Datadog #Husky #QueryEngine #RealTimeAnalytics #DistributedSystems #Scalability #DataInfrastructure

🟣لینک مقاله:
https://www.datadoghq.com/blog/engineering/husky-query-architecture/?utm_source=tldrdata


👑 @Database_Academy
1
🔵 عنوان مقاله
From Dark Data to Bright Insights: The Dawn of Smart Storage (6 minute read)

🟢 خلاصه مقاله:
**خلاصه فارسی: گوگل Cloud دو قابلیت جدید برای Cloud Storage معرفی کرده است: auto annotate و object contexts. این قابلیت‌ها با تکیه بر AI برای داده‌های نامنظم به‌صورت خودکار متادیتا و سرنخ‌های معنایی ایجاد می‌کنند تا داده‌های «تاریک» قابل جست‌وجو، حاکمیت‌پذیر و قابل تحلیل شوند. auto annotate (نسخه آزمایشی) در سطح هر شیء برچسب‌ها، تشخیص‌ها و پرچم‌های PII را در مقیاس تولید می‌کند و فرآیند طبقه‌بندی و سازمان‌دهی را تسریع می‌کند. object contexts نیز برچسب‌گذاری بومی و انعطاف‌پذیر و تبار متادیتا را فراهم می‌آورد و به‌صورت یکپارچه با Cloud Storage، IAM و BigQuery کار می‌کند تا هم حاکمیت دسترسی حفظ شود و هم پرس‌وجو و تحلیل متادیتا ممکن شود. هر دو قابلیت فعلاً در دسترس آزمایشی محدود هستند.

#CloudStorage #GoogleCloud #AI #Metadata #DataGovernance #BigQuery #IAM #PII

🟣لینک مقاله:
https://cloud.google.com/blog/products/storage-data-transfer/make-your-unstructured-data-smart-with-cloud-storage/?utm_source=tldrdata


👑 @Database_Academy
🔵 عنوان مقاله
Prague PostgreSQL Developer Day 2026

🟢 خلاصه مقاله:
Prague PostgreSQL Developer Day 2026 در تاریخ January 27–28 در Prague، Czechia برگزار می‌شود و فرصتی برای گردهمایی جامعه PostgreSQL است. Call for Proposals تا November 14 باز است؛ اگر قصد سخنرانی دارید، می‌توانید پیشنهاد خود را (از مطالعات موردی تا مباحث فنی و تجربیات عملی) ارسال کنید.

#PostgreSQL #PPDD2026 #CFP #DeveloperConference #Prague #Czechia #OpenSource

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


👑 @Database_Academy
🔵 عنوان مقاله
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
🔵 عنوان مقاله
Introducing Elephantshark: A Tool to Monitor Postgres Network Traffic

🟢 خلاصه مقاله:
Elephantshark ابزاری برای مشاهده ترافیک شبکه Postgres است که بدون تغییر در کلاینت یا سرور، بین دو طرف قرار می‌گیرد. این ابزار با تکیه بر Ruby همچون یک پراکسی سبک عمل می‌کند: پیام‌های دوطرفه را عبور می‌دهد و همزمان پیام‌های پروتکل Postgres را پارس و لاگ می‌کند. نتیجه، دید شفاف و کم‌اصطکاک از تبادلات شبکه‌ای است که در توسعه، دیباگ، بررسی عملکرد و ممیزی کاربرد دارد و می‌تواند مکمل لاگ‌های سرور و ابزارهای packet capture باشد. کد و مستندات آن از طریق مخزن GitHub در دسترس است.

#Postgres #DatabaseMonitoring #NetworkTraffic #Ruby #Proxy #Observability #GitHub #PostgresProtocol

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


👑 @Database_Academy
🔵 عنوان مقاله
On Developing OAuth Support for Postgres

🟢 خلاصه مقاله:
پشتیبانی از OAuth در نسخه Postgres 18 به‌عنوان یک قابلیت مهم اضافه شده است. نویسنده که از نخستین حامیان این ایده بوده، مسیر تبدیل آن از نمونه‌های اولیه و بحث‌های جامعه به یک ویژگی پایدار را روایت می‌کند و نشان می‌دهد چرا ادغام مستقیم پایگاه‌داده با هویت‌های سازمانی و فضای ابری ضروری است. در پیاده‌سازی، Postgres توکن‌های استاندارد OAuth/OIDC را با بررسی issuer و audience، امضای مبتنی بر JWKS و نگاشت claimها به نقش‌های دیتابیس اعتبارسنجی می‌کند و تنظیمات از طریق پیکربندی آشنا (مانند pg_hba.conf) انجام می‌شود. بخش عملی مقاله نشان می‌دهد چطور می‌توان Postgres را به ارائه‌دهنده‌هایی مثل Okta، Auth0، Azure AD، Google و Keycloak وصل کرد تا کلاینت‌ها با bearer token متصل شوند و دسترسی بر اساس نقش‌های نگاشت‌شده کنترل شود. مزیت‌ها شامل هویت متمرکز، توکن‌های کوتاه‌عمر و قابل ابطال، کنترل دقیق‌تر دسترسی و ادغام ساده‌تر با جریان‌های ابری و بدون رمز عبور است. در ادامه، مسیر آینده شامل نگاشت پیشرفته‌تر claim به نقش، بهبود لاگ و عیب‌یابی، بهینه‌سازی عملکرد، سازگاری گسترده‌تر با ارائه‌دهنده‌ها و پشتیبانی بهتر در درایورها و ابزارهای پیرامونی عنوان می‌شود.

#Postgres #OAuth #Postgres18 #DatabaseSecurity #OIDC #IdentityManagement #OpenSource #Authentication

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


👑 @Database_Academy
🔵 عنوان مقاله
SQLMesh, dbt, and Fivetran... What's Next? (5 minute read)

🟢 خلاصه مقاله:
فشرده‌سازی اخیر در اکوسیستم Modern Data Stack با تصاحب dbt توسط Fivetran و یکپارچه‌سازی‌های اخیر با Tobiko Data و Census نشان می‌دهد که لایه‌های ingestion، transformation، modeling و حتی activation به سمت تجمیع زیر چتر چند فروشنده محدود می‌روند. این روند می‌تواند کار را برای تیم‌ها ساده‌تر کند و به متادیتا، lineage، حاکمیت و صورتحساب یکپارچه بینجامد، اما ریسک‌هایی هم دارد: کوچک شدن سطح open-source و دورتر شدن قابلیت‌های dbt Core از dbt Fusion که می‌تواند به قفل‌شدن در فروشنده و تجربه‌های نامتوازن منجر شود. در این میان، ابزارهایی مثل SQLMesh با تأکید بر قابلیت اطمینان، تغییرات مبتنی‌بر plan و سازگاری با پروژه‌های dbt گزینه‌ای برای حفظ انعطاف‌پذیری و اجرای موازی یا مسیرهای مهاجرتی هستند. در آینده باید انتظار یکپارچگی بیشتر پلتفرمی و استانداردهای در حال تغییر را داشت. تیم‌ها بهتر است وابستگی‌های خود به dbt Core در برابر قابلیت‌های مدیریت‌شده را بسنجند، اصول قابل‌حمل بودن (قراردادهای داده، استانداردهای lineage، چک‌های CI/CD) را تعریف کنند، لایه‌های ذخیره‌سازی/محاسبات را از ارکستراسیون جدا نگه دارند و با گزینه‌هایی مانند SQLMesh آزمایش‌های هدفمند انجام دهند تا برای تغییرات پیش‌رو آماده باشند.

#ModernDataStack #dbt #Fivetran #DataEngineering #OpenSource #SQLMesh #AnalyticsEngineering

🟣لینک مقاله:
https://smallbigdata.substack.com/p/sqlmesh-dbt-and-fivetran-whats-next?utm_source=tldrdata


👑 @Database_Academy