‍ معماری‌های مدرن؛ زمان بازنگری در نقش لایه‌ کش فرا رسیده است؟

برای سال‌ها، Redis سلطان بی‌رقیب کش کردن داده در حافظه است.

تقریباً هر معماری استانداردی یک «لایه کش» دارد:

✨ درخواست می‌آید → اول سراغ Redis → اگر نبود → می‌رود سراغ دیتابیس → و نتیجه دوباره در Redis ذخیره می‌شود.

این الگو آن‌قدر جا افتاده است که کمتر کسی جرئت می‌کند بپرسد:

«آیا واقعاً همیشه به Redis نیاز داریم؟»

اما با پیشرفت‌های اخیر دیتابیس‌ها - مخصوصاً #PostgreSQL - حالا این سؤال دوباره ارزش پرسیدن دارد.

و داستان تیمی که اخیراً توانست کل لایه Redis خود را حذف کند، یک نمونه جذاب برای ما مهندسین داده است.

👉 https://freedium-mirror.cfd/https://medium.com/@ArkProtocol1/why-postgres-18-let-me-delete-a-whole-cache-tier-bba2b4f1c742

🔹 بیایید داستان را با هم مرور کنیم…

یک تیم محصول، مثل بسیاری از ما، سال‌ها بود که برای پاسخ‌های سریع از Redis استفاده می‌کرد. اما در روزهای پر ترافیک، خود Redis یک پای داستان بود:

⚠️بار CPU بالا

⚠️ تاخیرهای عجیب

⚠️شبکه تحت فشار

درحالی‌که دیتابیس… نسبتاً آرام و بی‌کار نشسته!

نقطه عطف زمانی بود که آن‌ها PostgreSQL 18 را تست کردند، نسخه‌ای با تغییرات جدی:

⚡️امکان I/O ناهمگام واقعی

⚡️بهبودهای چشمگیر در استفاده از ایندکس‌ها

⚡️امکان virtual generated columns برای محاسبات سریع‌تر و بدون لایه جانبی

این‌ها فقط «بهبود» نبود؛ بازی را عوض کرد.

تیم تصمیم گرفت یک آزمایش مخفیانه انجام دهد:

یک endpoint بسیار شلوغ را مستقیم روی #PostgreSQL بگذارد، بدون #Redis.

انتظار داشتند کندتر شود.

اما نتیجه دقیقاً برعکس بود:

🔰 معیار p95 از ۷۲ میلی‌ثانیه → رسید به ۵۴ میلی‌ثانیه

🔰 نرخ hit rate از ۹۱٪ → شد ۱۰۰٪

🔰 و دیگر خبری از فشار شبکه و CPU نبود.

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

در نهایت، آن‌ها با خیال راحت Redis را کنار گذاشتند.

معماری ساده‌تر شد، پایش آسان‌تر شد، و منبع داده از دوگانگی خارج شد.

از آن مهم‌تر: عملکرد بهتر شد.

رد پای یک روند بزرگ‌تر: تجربه #ScyllaDB

سال گذشته هم در وبلاگ ScyllaDB نمونه مشابهی دیدم: جایی که تیم SecurityScorecard به این نتیجه رسیده بود که با توجه به سرعت بالا، معماری توزیع‌شده و کش داخلی ScyllaDB، دیگر نیازی به یک لایه Redis جداگانه ندارند. آن‌ها نیز مانند مثال بالا دریافتند که پیچیدگی همگام‌سازی دیتابیس و کش، در برابر توان پردازشی دیتابیس‌های مدرن، برای برخی سناریوها توجیه خود را از دست داده است.
https://www.scylladb.com/compare/scylladb-vs-cache

✅ بنابراین اگر در پروژه‌های خود به‌صورت پیش‌فرض همه‌چیز را به Redis می‌سپارید، شاید وقت آن رسیده باشد که امکانات دیتابیس‌های جدید، یا حتی توان واقعی دیتابیس اصلی‌تان، را دوباره بررسی کنید. گاهی پاسخ سریع‌تر و ساده‌تر، همان‌جایی است که سال‌ها از آن عبور کرده‌ایم.

🔹 درس ماجرا چیست؟

این داستان نمی‌گوید «Redis را حذف کنید».

ردیس همچنان یک ابزار قدرتمند و ضروری برای بسیاری از سناریوهاست.

اما یک نکته مهم را روشن می‌کند:

گاهی فناوری‌های پایه آن‌قدر جلو می‌روند که معماری‌های کهنه دیگر بهترین انتخاب نیستند.

💡شاید وقت آن باشد که به جای تکرار الگوهای سال‌های گذشته، دوباره از خود بپرسیم:

⚡️ آیا دیتابیس ما امروز آن‌قدر قدرتمند شده که خودش نقش کش را بازی کند؟

⚡️ آیا لایه کش واقعاً سرعت‌دهنده است یا ناخواسته گره اضافه کرده‌ایم؟

⚡️ آیا پیچیدگی اضافه همیشه ارزشش را دارد؟

ابزار ClickGraph v0.5.2 ؛ وقتی ClickHouse به یک موتور گراف تحلیلی تبدیل می‌شود:

تحلیل گرافی سال‌ها در قلمرو دیتابیس‌هایی مثل Neo4j بود؛ اما در سازمان‌هایی که همه‌چیز روی ClickHouse متمرکز است، انتقال داده به یک موتور جداگانه هزینه و ریسک بالایی دارد. ClickGraph برای همین متولد شده است: یک لایه تحلیلی گراف، سبک و stateless که روی ClickHouse سوار می‌شود، کوئری‌های Cypher را به SQL بهینه ترجمه می‌کند و آن‌ها را مستقیماً روی همان داده‌های موجود اجرا می‌کند؛ یعنی بدون مهاجرت داده، می‌توان یک دید گرافی قدرتمند از داده‌های ستونی ساخت و از اکوسیستم Neo4j مثل درایورها، cypher-shell، Browser و Bolt 5.8 استفاده کرد، در حالی که اجرا روی ClickHouse می‌ماند.
نسخه 0.5.2 روی همین ایده سوار است و آن را به بلوغ اینترپرایزی نزدیک کرده: پشتیبانی از الگوهای پیچیدهٔ اسکیمای گراف از پلی‌مورفیک تا denormalized و coupled edges، بهینه‌سازی مسیرهای چندمرحله‌ای و حفظ هم‌خوانی با ابزارهای Neo4j در کنار معماری سبک و تست‌شده، با تمرکز بر انعطاف در مدل‌سازی گراف و پرفورمنس قابل‌اتکا روی دیتاست‌های بزرگ.
@BIMining

‍ چگونه داده‌های تاریخی را در PostgreSQL آرشیو کنیم؟ و همچنان به تمام داده‌ها دسترسی داشته باشیم

داده‌ها هر روز بزرگ‌تر و پیچیده‌تر می‌شوند و مدیریت آن‌ها بدون افت عملکرد، یکی از چالش‌های بزرگ مهندسان داده است. در این ویدئو و کارگاه عملی، ما به شما نشان می‌دهیم چگونه با Foreign Data Wrapper (#FDW) و جداول پارتیشن‌بندی شده #PostgreSQL داده‌های قدیمی و تاریخی را آرشیو کنید، بدون اینکه عملکرد دیتابیس اصلی کاهش یابد و همزمان کاربر بتواند روی تمام داده‌ها، کوئری اجرا کند.

⚡️نگاهی به قابلیت FDW‌ در پستگرس

در این آموزش ابتدا مفهوم #FDW را بررسی می‌کنیم؛ یک مکانیزم قدرتمند اتصال به سایر دیتابیس‌ها در پستگرس. Foreign Data Wrapper مثل یک مترجم میان‌سیستمی عمل می‌کند؛ ابزاری که به #PostgreSQL یاد می‌دهد با دیتابیس‌های دیگر حرف بزند، آن‌ها را بفهمد و حتی با آن‌ها کار کند، درست مثل اینکه جزیی از خودِ سیستم باشند.

با FDW، مفهوم «دادهٔ خارجی» عملاً از بین می‌رود. کوئری‌ای که روی یک جدول محلی اجرا می‌کنید، می‌تواند بی‌صدا و هوشمندانه به سراغ یک جدول دوردست در سروری دیگر برود، نتایج را برگرداند و همه‌چیز را طوری نمایش دهد که انگار محلی بوده است. این یعنی یکپارچگی در دسترسی، بدون تغییر کدهای برنامه، بدون اتصال‌های اضافی و بدون مدیریت پیچیدگی‌های پشت‌صحنه.

قابلیت FDW جوهرهٔ یک ایده‌ی ساده اما قدرتمند است: داده می‌تواند هرجایی باشد، اما تجربهٔ کار با آن باید یکپارچه باقی بماند.

💡 آنچه در این کارگاه یک‌ساعته می‌بینید
در این کارگاه، یک راهکار عملی برای آرشیو داده‌ها با استفاده از پارتیشن‌بندی PostgreSQL و Postgres_FDW بررسی می‌شود تا بتوانید داده‌های تاریخی را شفاف، مقیاس‌پذیر و قابل‌مدیریت نگه دارید.

ایده بسیار ساده اما قدرتمند است:
ابتدا داده‌ها را در یک جدول پارتیشن‌بندی‌شده (مثلاً سالانه یا ماهانه) نگه می‌داریم. سپس یک دیتابیس جداگانه برای آرشیو می‌سازیم و پارتیشن‌های قدیمی را به آن منتقل می‌کنیم. پس از حذف پارتیشن محلی، همان پارتیشن را به‌صورت یک foreign table و همچنان به‌عنوان پارتیشنی از جدول اصلی تعریف می‌کنیم.

نتیجه:

✨ داده‌های جدید روی سرور اصلی و با سرعت بالا بازیابی می‌شوند ⚡️

✨داده‌های قدیمی بی‌صدا از سرور آرشیو خوانده می‌شوند 🔗

✨سرور اصلی سبک و سریع باقی می‌ماند، درحالی‌که دسترسی به کل تاریخچه حفظ می‌شود 📉✨

ترکیب پارتیشن‌بندی و FDW یک معماری تمیز و قدرتمند برای آرشیو داده در PostgreSQL ایجاد می‌کند.


این آموزش شامل موارد زیر است:

🔰 ساخت جداول پارتیشن‌بندی شده برای مدیریت داده‌ها بر اساس تاریخ

🔰 ایجاد اتصال با FDW به یک دیتابیس آرشیو جداگانه

🔰 تبدیل جدول محلی به پارتیشن خارجی و مدیریت داده‌ها بین سرور اصلی و آرشیو

🔰 اجرای کوئری‌ها روی داده‌های توزیع‌شده بدون نیاز به تغییر در اپلیکیشن

🔰 مهاجرت و نگهداری داده‌های تاریخی به شکلی شفاف و قابل کنترل

با مشاهده این کارگاه، شما قادر خواهید بود داده‌های آرشیوی را به صورت امن، مقیاس‌پذیر و یکپارچه مدیریت کنید و تجربه‌ای عملی از استفاده‌ی FDW در سناریوهای واقعی آرشیو داده‌ها به دست آورید.

🎥 تماشای ویدئو:
YouTube - https://youtu.be/RdGUIbNzNH4

💻 کدهای ورکشاپ:

Workshop Codes - https://github.com/sepahram-school/workshops/tree/main/3-Postgres-Data-Archiving-With-FDW