اینکه کش کنیم یا نکنیم، اینکه چیو کش کنیم و کجا بخونیم کاااملا به بیزینسمون، روند کارمون و نیازمندیهامون
بستگی داره. در نتیجه ممکنه مسائلی که من اینجا مطرح میکنم به نظر شما اصلا کاربردی نیاد... شایدم بیاد خدا میدونه.
از طرفی خوندن از دیتا و پالسی های دسترسی و پرمیشنهایی که هر پروژه و بیزینس داره، به خودش مربوطه و از موضوع بحث ما خارجه :)
تاجایی که من میدونم، کش کردن، فرایند نگهداری یه دسته از اطلاعاته به صورت دم دستی که گردآوریش به روش فرمال و کلاسیک یه مقدار از لحاظ منابع، هزینه بردار باشه(معمولا زمان!). در این حالت ما دیتایی که ریفرنس بهش زیاده رو یه جایی همین اطراف نگه میداریم که بتونیم به سرعت بهش دسترسی داشته باشیم. این نکته رو باید عرض کنم که هر دیتایی ارزش و امکان کش کردن نداره. دیتایی که عموما درخواست خوندنش بالاست و معمولا سخت گردآوری میشه رو معمولا کش میکنیم. لازم به ذکره که دیتایی که نرخ بروزرسانیش هم بالاست رو خیلی نمیشه،،،، نمیشه که نه، به صرفه نیست که کش کنیم. مگر اینکه ترید آف (مصالحه)ی که بین دسترسی و آپدیت کردنش توی سیستم ما هست، کفه ی ترازو رو به سمت کش کردن سنگین تر کنه. و در نهایت همونطور که قبل تر عرض کردم، کل این فرایند به ما، بیزینس ما، نیاز مندی های ما و نوع پیاده سازیمون برمیگرده.
برای درک بهتر نیاز به کشینگ، من یه مثال میزنم. فرض کنین ما توی یه سامانه ای هستیم که اطلاعات یه کاربر رو که جنبه های مختلفی داره، توی دیتابیس های مختلفی نگه میداره ( خواهشا به کانسپت و اینکه دلیل این کار چیه گیر ندین، مثاله آقا). فرضا توی میکروسرویس های مختلف که هرکدوم دیتابیس مستقل خودشون رو دارن.
در این حالت، هربار که کلاینت بخواد دیتای کاربر رو جمع کنه، باید به همه ی این سرویس ها درخواست بده تا بتونه این دیتا رو جمع آوری کنه. حالا این موضوع رو بزارین کنار اینکه اگر کاربر دیتایی داشته باشه که نیاز باشه براسا پارامترهای مختلف، توسط سیستم محاسبه بشه. پس هربار درخواستهای متعدد و محاسبات متعدد. دیگه بیاین به این فکر نکنیم که ممکنه توی شبکه ارتباطی بین این میکرو سرویس ها، هزار و یک اتفاق بیوفته و ... .
در این حالت چقدر کاربردیه که ما بیایم یه فرمت دیتا برای این اطلاعات کاربری بسازیم و اونو کش کنیم. اینطوری روی هربار درخواست فقط از یه منبع با سرعت خیلی بالاتر میتونیم دیتارو بخونیم.
این نکاتیه که درمورد کش عمومیه و چیزی که من میخواستم بهش بپردازم بحث hot cache و cold cache هستش.
در این ساختار hot cache در واقع اون منبعیه که ما دیتارو داغ داغ توش سرو میکنیم (مثلا یه دیتابیس redis ) و البته خیلی از بزرگان معتقد هستن که کش یه امکان cross cutting platform هستش. یعنی جدا از لایه بندی پروژه و این داستانا، هرجا که احتیاجش داشتیم، میتونینم ازش استفاده کنیم. البته در این مورد و مثال، ما تو همون لایه ی بالایی که به presentation ، controller و ... معروفه میخوایم ازش بخونیم.
در طرف دیگه ماجرا cold cache وجود داره که درواقه یه دیتابیس با خاصیت stability بالاتره (مثل postgres یا couch base ) که دیتارو باهمون فرمت تو خودش نگه میداره و پشتوانه hot cache مون هست. این فرمت دیتا میتونه تو لایه های بالایی ساخته بشه و روی هر آپدیتی که رو ی دیتا صورت میگیره، اونم متعاقبا بروزرسانی بشه که همیشه دیتای صحیح رو تو خودش نگهداره( اگر دیتابیس های جدایی ندارین، اکیدا پیشنهاد میکنم که برای cold cache از materialized view استفاده کنین... خیلی جوابه).
حالا فرایند رو عرض میکنم. وقتی که درخواستی میاد که اطلاعات کاربر رو بخونه، ابتدا تو hot cache رو چک میکنیم، اگه دیتا رو پیدا نکردیم(که خب قاعدتا تو درخواست اول به این صورته) میریم دیتا رو از cold cache میخونیم و هم به درخواست دهنده میدیم و هم تو hot cache ذخیره میکنیم. تبریک میگم، اولین کشمون رو انجام دادیم!
حالا سوال شاید پیش بیاد که cold cache دیتا رو از کجا آورده؟ خب همونطور که عرض کردم، یک سری رفتار توی لایه های بالایی (یا شایدم تو دیتابیس) باید پیاده کنیم، که روی اکشن هایی که دیتا رو ایجاد میکنن یا تغییر میدن، اصطلاحا trigger بشن و دیتای مورد نیاز رو توی cold cache برامون ثبت کنن. به این صورت روی ایجاد کاربر یا آپدیتش، این دیتا ایجاد یا بروز رسانی میشه.
یه نکته رو نباید فراموش کنیم. مکانیزمی که هر از چندگاهی ورزن دیتای hot cache رو با cold cache تطبیق بده و دیتای hot cache رو بروزرسانی کنه. پس باید توجه داشت که این پترن، روی دیتایی بیشتر کاربردیه که availability ش مهم تر از consistency ش باشه.
#programming
