معمولا برای افزایش سرعت کوئری ها(هر جایی که قراره دیتایی به کاربر نشون بدیم) ، کش استفاده می شود ولی مشکل از جایی شروع خواهد شد که دیتای اصلی آپدیت شود ولی کش آپدیت نشود .
افزایش سرعت الزاما همیشه با استفاده از کش در رم (مثل Redis) نخواهد بود و ممکن است افزایش سرعت با استفاده از رویکرد CQRS و جداسازی Read Model ها باشد که همچنان دغدغه های بروزرسانی Read Model مطرح خواهد بود
۱- تعیین زمان انقضا
یک رویکرد مرسوم و ساده در پیاده سازی کش ، تعیین زمان انقضا برای کش می باشد . در این روش خروجی کوئری ها در کش قرار می گیرد و یک زمان قطعی / شناور برای کش تعیین خواهد شد که تا پایان آن زمان دیتا مستقیم از کش خوانده می شود و بعد از آن دیتای کش حذف خواهد شد و کوئری های بعدی از دیتابیس گرفته شده و وارد کش می شود .
احتمالا در یک سری نرم افزارها رد پای این رویکرد رو دیدید به اینصورت که وقتی دیتایی رو تغییر می دید با تاخیر در خروجی تاثیرش رو می بینید .
مزایا :
معایب :
مناسب برای :
۲- آپدیت / حذف کش هنگام بروزرسانی دیتا
در این روش با هر تغییری که در دیتای اصلی اتفاق بیفتد کش هم بروزرسانی می شود
انواع بروزرسانی :
اشکال اول این روش زمانی هست که تغییر در دیتابیس انجام شود ولی کش با موفقیت تغییر نکند
اشکال دوم کاهش سرعت بروزرسانی دیتا هستش چون ممکن است ساختن دوباره دیتای کش نیاز به دیتای زیادی داشته باشد و یا تعداد کش های وابسته به این دیتا زیاد باشد
دراین روش می توانیم قبل از بروزرسانی دیتابیس ، کش رو حذف کنیم و در صورت وجود خطا در حذف کش ، عملیات متوقف خواهد شد . منتها در فاصله زمانی بین حذف کش تا آپدیت دیتابیس بایستی از رویکردهای lock برای نوشتن دیتا در کش استفاده کنیم
مشکل دوم حل شده است اما مشکل جدید اینه که اولین کوئری زمان زیادی برای پردازش خواهد داشت
در این روش معمولا بروزرسانی دیتای کش در ترد جداگانه و یا با استفاده از Message Broker ها انجام خواهد شد و مشکل کاهش سرعت اولین کوئری نیز حل خواهد شد .