🔵 عنوان مقاله
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
Tiger Data 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.
🔵 عنوان مقاله
14x Faster with 12x Less Compute: Sometimes Postgres Really is All You Need
🟢 خلاصه مقاله:
تیم جیمز یک کلاستر ۱۲ سروره مبتنی بر HBase/OpenTSDB را که برای دادههای سریزمانی استفاده میشد، با سامانهای بسیار سادهتر بر پایه Postgres/Timescale جایگزین کرد. نتیجه: پرسوجوها تا ۱۴ برابر سریعتر، با ۱۲ برابر محاسبات کمتر، و ۱۰۰٪ دسترسپذیری پس از مهاجرت.
آنها با تکیه بر SQL و قابلیتهای Timescale مانند hypertable، فشردهسازی، continuous aggregates و خطمشیهای نگهداشت داده، هم کارایی پرسوجوها و هم پایداری ingestion را بهبود دادند. طرح مهاجرت شامل dual-write، backfill موازی و اعتبارسنجی دقیق بود و در نهایت کل سامانه روی دو سرور با replication و failover خودکار پایدار شد.
پیام اصلی: برای بسیاری از بارهای کاری سریزمانی، Postgres/Timescale با طراحی درستِ شِما، ایندکسهای هدفمند و ابزارهای استاندارد، هزینه و پیچیدگی عملیاتی را بهطور چشمگیری کاهش میدهد و کارایی را بالا میبرد—گرچه برای نرخنوشتن یا کاردینالیتهی بسیار شدید، پایگاههای تخصصی هنوز مزیت دارند.
#Postgres #TimescaleDB #TimeSeries #OpenTSDB #HBase #DatabaseMigration #PerformanceEngineering #DevOps
🟣لینک مقاله:
https://postgresweekly.com/link/176022/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
14x Faster with 12x Less Compute: Sometimes Postgres Really is All You Need
🟢 خلاصه مقاله:
تیم جیمز یک کلاستر ۱۲ سروره مبتنی بر HBase/OpenTSDB را که برای دادههای سریزمانی استفاده میشد، با سامانهای بسیار سادهتر بر پایه Postgres/Timescale جایگزین کرد. نتیجه: پرسوجوها تا ۱۴ برابر سریعتر، با ۱۲ برابر محاسبات کمتر، و ۱۰۰٪ دسترسپذیری پس از مهاجرت.
آنها با تکیه بر SQL و قابلیتهای Timescale مانند hypertable، فشردهسازی، continuous aggregates و خطمشیهای نگهداشت داده، هم کارایی پرسوجوها و هم پایداری ingestion را بهبود دادند. طرح مهاجرت شامل dual-write، backfill موازی و اعتبارسنجی دقیق بود و در نهایت کل سامانه روی دو سرور با replication و failover خودکار پایدار شد.
پیام اصلی: برای بسیاری از بارهای کاری سریزمانی، Postgres/Timescale با طراحی درستِ شِما، ایندکسهای هدفمند و ابزارهای استاندارد، هزینه و پیچیدگی عملیاتی را بهطور چشمگیری کاهش میدهد و کارایی را بالا میبرد—گرچه برای نرخنوشتن یا کاردینالیتهی بسیار شدید، پایگاههای تخصصی هنوز مزیت دارند.
#Postgres #TimescaleDB #TimeSeries #OpenTSDB #HBase #DatabaseMigration #PerformanceEngineering #DevOps
🟣لینک مقاله:
https://postgresweekly.com/link/176022/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
YouTube
James Udiljak - 14x Faster with 12x Less Compute: Sometimes Postgres Really Is All You Need
How big is ""Big Data"" really? The definition has changed drastically over time.
In this talk, James recounts building his own database on top of Postgres to replace a legacy HBase/OpenTSDB cluster. While once considered ""Big Data"", the real-time monitoring…
In this talk, James recounts building his own database on top of Postgres to replace a legacy HBase/OpenTSDB cluster. While once considered ""Big Data"", the real-time monitoring…