🔵 عنوان مقاله
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
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
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.
🔵 عنوان مقاله
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
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
TigerData Blog
SkipScan in TimescaleDB: Why DISTINCT Was Slow, How We Built It, and How You Can Use It
Learn how TimescaleDB's SkipScan transforms DISTINCT queries from multi-second waits to milliseconds by jumping between values instead of scanning every row.