🔵 عنوان مقاله How hstore Can Beat jsonb for Audit Logs 🟢 خلاصه مقاله: در دنیای پایگاه‌های داده، اهمیت داشتن سیستم‌های جامع و کارآمد برای ضبط رخدادهای تغییر یافته در جداول بسیار بالا است. یکی از راهکارهای محبوب برای ردیابی تغییرات، استفاده از قابلیت‌های داخلی مانند jsonb و hstore در پایگاه‌ داده‌های PostgreSQL است. اخیراً، توصیف‌ها و آزمایش‌های متعددی نشان داده‌اند که نوع داده‌هایی که برای ثبت لاگ‌های تغییرات انتخاب می‌کنید، تأثیر قابل توجهی بر سرعت و کارایی سیستم دارد. در این میان، یک مشاهده جالب مطرح شده است؛ جایی که گفته می‌شود استفاده از تریگرهای نظارتی برای ثبت فقط ستون‌های تغییر یافته در لاگ، حجم لاگ را پنج برابر کاهش می‌دهد اما در عین حال باعث کندی فرآیند به‌روزرسانی می‌شود. این موضوع نشان‌دهنده تعادل حساسی است که باید بین کاهش حجم داده‌های لاگ و حفظ سرعت عملیات برقرار کرد. با این حال، تجربه‌های شخصی توسعه‌دهندگان می‌گویند که انتخاب نوع داده مناسب می‌تواند تأثیر قابل توجهی بر عملکرد داشته باشد. در آزمایش‌های شخصی یکی از توسعه‌دهندگان، که به جای jsonb از hstore بهره برده است، نشان داده شده است که استفاده از hstore برای ثبت تفاوت‌ها، سریع‌ترین حالت ممکن در مقایسه با سایر گزینه‌ها بوده است. این نتیجه نشان می‌دهد که نه تنها حجم لاگ کاهش یافته، بلکه سرعت پردازش تغییرات نیز به خوبی حفظ شده است. چنین یافته‌هایی می‌تواند راهنمای مهمی برای توسعه‌دهندگان و مدیران پایگاه‌ داده باشد تا در پیاده‌سازی سیستم‌های نظارتی و لاگینگ، بهترین تعادل ممکن را برقرار کنند. در نهایت، انتخاب بین jsonb و hstore باید بر اساس نیازهای خاص پروژه، میزان تغییرات، و سرعت عملیاتی صورت گیرد. اما تجربیات نگارنده نشان می‌دهد که هسته اصلی موفقیت در استفاده بهینه از امکانات پایگاه‌ داده و به‌کارگیری تکنیک‌های مناسب است، تا هم حجم داده‌ها کنترل شده و هم عملیات پایگاه‌ داده با سرعت مطلوب انجام پذیرد. #پایگاه_داده #پایش_سیستم #نظارت_سخت_افزار #بهینه‌سازی 🟣لینک مقاله: https://www.depesz.com/2026/10/16/old-tech-is-sometimes-better-a-case-study-based-on-blogpost-from-now-next/ ➖➖➖➖➖➖➖➖ 👑 @Database_Academy

🔵 عنوان مقاله Single-tenant Titus: VM-level isolation on a multi-tenant container platform (26 minute read) 🟢 خلاصه مقاله: در حال حاضر سرویس نتفلیکس در حال افزودن حالت تک‌مستأجر به پلتفرم Titus است تا بتواند بارهای حساس و حیاتی را در یک ماشین مجازی مستقل اجرا کند، بدون اینکه نیاز باشد از زیرساخت‌های کنترلی خود خارج شود. این رویکرد با هدف مقابله با مشکل تداخل همسایگان مزاحم در سطح سخت‌افزار صورت گرفته است، مشکلی که می‌تواند منجر به افزایش شدید تأخیرهای پایانی (tail-latency) در سیستم‌های حالت‌دار و حساس شود. برخلاف استفاده از چندمستأجر، تخصیص نودهای اختصاصی برای چنین وظایفی، ثبات سیستم را بهبود بخشیده و حتی ظرفیت‌های از دست رفته به دلیل سیاست‌های ضدهم‌نشینی (anti-affinity) را بازیابی کرده است، هرچند این راهکار نیازمند زمان بیشتر برای راه‌اندازی و برنامه‌ریزی دقیق‌تر ظرفیت‌های گرم است. این توسعه به تیم‌های عملیاتی و توسعه‌دهندگان امکان می‌دهد تا به راحتی بخش‌هایی از بار کاری حساس را به ماشین‌های مجازی خاص اختصاص دهند، به‌گونه‌ای که تداخل‌های معمول در محیط‌های چندمستأجر کاهش یافته و عملکرد سیستم به شدت بهبود یابد. در نتیجه، این اقدام علاوه بر افزایش امنیت و ثبات سیستم، به بهبود کارایی و اطمینان در اجرای وظایف بحرانی کمک می‌کند، هرچند که نیازمند برنامه‌ریزی دقیق‌تر نسبت به حالت‌های معمول است تا بتوان بهترین بهره‌وری را از منابع به دست آورد. با توجه به این امکانات جدید، انتظار می‌رود که دیگر چالش‌های مربوط به تأخیرهای شدید و نوسانات عملکرد که در نتیجه هم‌جواری مزاحم در سخت‌افزار ایجاد می‌شد، به‌طور قابل توجهی کاهش یابد و نتفلیکس بتواند سرویس‌های حساس‌تری را در قالب پلتفرم خود ارائه دهد، بدون اینکه از کارایی و پایداری سیستم خود بکاهد. #ابزارهای_پایدار #توسعه_پلتفرم #ماشین_مجازی #توسعه_مستدام 🟣لینک مقاله: https://netflixtechblog.com/single-tenant-titus-vm-level-isolation-on-a-multi-tenant-container-platform-6d8b1909d163?utm_source=tldrdata ➖➖➖➖➖➖➖➖ 👑 @Database_Academy

🔵 عنوان مقاله recovery_prefetch Considered Harmful and Causing Outages 🟢 خلاصه مقاله: در نسخه‌های جدید پایگاه داده پستگرس، ویژگی recovery_prefetch از نسخه ۱۵ به صورت پیش‌فرض فعال شده است. این قابلیت زمانی که سیستم با حجم بالای نوشتن مواجه می‌شود، به منظور بهبود عملکرد، داده‌هایی را که انتظار می‌رود در آینده مورد نیاز باشد، پیش‌بارگذاری می‌کند. اما مشکل زمانی ظاهر می‌شود که این فرآیند به شدت روی منابع استوریج نسخه پشتیبان تأثیر می‌گذارد، خصوصاً در حالت استندبای، جایی که منابع محدودتر است و روند به‌روزرسانی‌ها باید به صورت پیوسته انجام شود. در توضیحات جرمی، نشان داده شده است که استفاده از recovery_prefetch می‌تواند منجر به سیل درخواست‌های خواندن و نوشتن بیشتری شود که سیستم استندبای را بسیار تحت فشار قرار می‌دهد. نتیجه این است که پس از یک زمان نوشتن ناگهانی، فضای استوریج استندبای خیلی سریع اشباع می‌شود و باعث کاهش قابل توجه کارایی و در بعضی موارد، توقف کامل سرویس می‌گردد. این مشکل می‌تواند چندین ساعت به طول انجامد، که برای عملیات‌های سازمانی پیامدهای جدی در پایداری و قابلیت اطمینان سیستم به دنبال دارد. علاوه بر این، جرمی در آزمایش‌های خود نشان داده است که در مواقعی که از نسخه‌های با تکرار همزمان (synchronous replication) استفاده می‌شود، این مشکل بسیار بحرانی‌تر است. در این حالت، اگر اتصال بین سرور اصلی و استندبای قطع شود، فرآیند نوشتن‌های اصلی نیز مسدود می‌شود و این وضعیت تا ۳۵ دقیقه ادامه پیدا می‌کند. چنین تأخیری، باعث ایجاد وقفه‌های طولانی در دسترس بودن سرویس می‌شود و نگرانی‌هایی درباره اعتمادپذیری و پایداری سیستم به وجود می‌آورد. بنابراین، این تجربیات نشان می‌دهد که ویژگی recovery_prefetch، اگرچه در ظاهر مفید است، ولی در برخی سناریوها می‌تواند منجر به مسائلی جدی در کارایی و پایداری پایگاه داده‌ها شود. مدیران پایگاه داده باید با دقت این پارامتر را مدیریت کرده و در صورت نیاز، آن را غیرفعال یا تنظیم مجدد کنند تا از بروز چنین مشکلاتی جلوگیری شود. #پایگاه_داده #پستگرس #بهبود_کارایی #پایداری 🟣لینک مقاله: https://ardentperf.com/2026/10/20/postgres-recovery_prefetch-considered-harmful-and-causing-outages/ ➖➖➖➖➖➖➖➖ 👑 @Database_Academy