کش پایگاه داده 
فرآیندی است که در طراحی برنامه‌های کاربردی کامپیوتری گنجانده شده‌است که صفحات وب را بر اساس تقاضا (به صورت پویا) با دسترسی به پایگاه‌های داده پشتیبان تولید می‌کنند.

وقتی کع که برنامه‌ها در محیط‌ها چند لایه‌ای گسترش پیدا می‌کند که شامل کلاینت‌های مبتنی بر مرورگر، سرورهای برنامه‌های کاربردی وب و پایگاه داده‌های پشتیبانی می‌شوند، [1] [2] حافظه پنهان پایگاه داده سطح متوسط برای دستیابی به مقیاس‌پذیری و عملکرد بالا استفاده می‌شود

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

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

سودها 
در حافظه پنهان پایگاه داده‌ها با توضیع بار کاری پرس وجو از درون چندین سیستم ارزان فرانت‌اند مقیاس پذیر را بهبود می‌دهد. این انعطاف‌پذیری در پردازش داده‌ها پیروی می‌کند: برای مثال داده‌های مشتریان ویژه رامی‌شود در حافظه پنهان کرد در صورتی که داده‌های مشتریان عادی را نمی‌توان پنهان کرد. حافظه‌ی پنهان می‌تواند در دسترس بودن داده‌ها را با ارائه‌ی خدمات مستمر برای برنامه‌هایی که تنها جداول ذخیره شده در حافظه پنهان وابسته هستند. حتی اگر سرور پشتیبان در دسترس نباشد بهبود می‌دهد. مزیت دیگر بهبود سرعت دسترسی به داد‌ها است که به واسطه محلی بودن داده‌ها و هموارسازی پیک‌های بار با اجتناب از رفت و آمد بین سطح میانی و سطح داده ایجاد می‌شود.

عناصر بالقوه طراحی 

 قابلیت به روزرسانی جدول کش : بسیاری از سیستم‌های کش را فقط می‌توان خواند که استفاده از آن‌ها به بخش کوچکی از برنامه‌ها ،برنامه‌های غیر واقعی محدود می‌کند.
 به روز رسانی دو جهته : به روزرسانی‌های جدول کش باید در دو حالت به پایگاه داده هدف منتشر شوند و هر به روز رسانی که به صورت مستقیم در پایگاه داده هدف اتفاق می‌افتد باید به طور خودکار به حافظه‌ی پنهان بیاید.
 انتشار به روز رسانی همزمان و غیر همزمان : به روز رسانی‌های جدول حافظه‌ی پنهان باید در دو حالت در پایکاه داده هدف منتشر شوند. در حالت همزمان اطمینان می‌دهند که پس از تکمیل عملیات پایگاه داده، به روز رسانی ها در پایگاه داده هدف نیز اعمال می شود. در حالت Asynchronous، به‌روزرسانی‌ها به پایگاه داده هدف به تأخیر می‌افتد. حالت سنکرون قوام حافظه نهان بالا می دهد و برای برنامه های بلادرنگ مناسب است. حالت ناهمزمان توان عملیاتی بالایی دارد و برای برنامه های تقریباً واقعی مناسب است.
 ریزدانگی حافظه پنهان چندگانه - سطح پایگاه داده، سطح جدول و ذخیره‌سازی مجموعه نتایج: بخش‌های عمده پایگاه‌های داده شرکتی تاریخی هستند و به ندرت قابل دسترسی هستند. اما، برخی اطلاعات وجود دارد که باید فوراً در دسترس باشد، مانند داده‌های مشتری ممتاز و غیره.
 بازیابی جداول کش: در صورت قطع سیستم یا برق، در طول راه اندازی مجدد پلتفرم کش، تمامی تراکنش های تعهد شده روی جداول کش باید بازیابی شوند.
 ابزارهای اعتبارسنجی انسجام حافظه پنهان: در صورت انتشار غیرهمزمان به‌روزرسانی، حافظه پنهان در گره‌های کش مختلف و پایگاه داده هدف ممکن است از هم جدا شوند. این باید به صورت دستی حل شود، با شناسایی عدم تطابق و اقدامات اصلاحی در صورت لزوم.
 مقیاس پذیر به صورت افقی: محاسبات خوشه ای ممکن است دسترسی را افزایش دهد و به تعادل بار برسد. ذخیره سازی در یک محیط خوشه ای چندین گره را در بر می گیرد و داده های کش شده را در بین گره ها منسجم نگه می دارد.
 دسترسی شفاف به جداول غیر کش در پایگاه داده هدف وجود دارد: حافظه پنهان پایگاه داده باید پرس و جوها را پیگیری کند و باید بتواند به طور هوشمندانه به کش پایگاه داده یا پایگاه داده مبدا بر اساس محل داده ها بدون هیچ گونه تغییر کد برنامه ، مسیریابی کند.
 خراب شدن Transparent : در صورت خرابی پلتفرم حافظه پنهان نباید هیچ گونه قطعی در سرویس وجود داشته باشد. اتصالات کلاینت باید به پایگاه داده هدف هدایت شوند.
 بدون تغییر یا تغییرات بسیار کم در برنامه: پشتیبانی از رابط های استاندارد JDBC، ODBC و غیره که باعث می شود برنامه به طور یکپارچه بدون هیچ تغییری در کد برنامه کار کند. باید تمام فراخوان‌های رویه ذخیره‌شده را به پایگاه داده هدف هدایت کند تا نیازی به مهاجرت نداشته باشند.

مشکلات در پیاده سازی ها 

 راه رفتن در حافظه پنهان روی رویدادهای حذف یا باطل شدن: طرح‌های کش که از موتورهای کش خارجی مانند Redis یا Hazelcast استفاده می‌کنند، اغلب با صدور حذف در برابر اشیاء باطل شده، باعث بی‌اعتباری می‌شوند. این می تواند منجر به یک عملیات نوشتن شود که باعث هزاران حذف شده و بر عملکرد تأثیر می گذارد.
 عدم ردیابی کلید: باز هم، اگر از یک موتور کش خارجی استفاده کنید، هر درخواستی اغلب باعث جستجوی کلید در لایه کش می شود. اگر این اشتباه باشد، می‌تواند یک RTT اضافی ایجاد کند و به تأخیر کلی درخواست‌ها اضافه کند. موتورهایی مانند Redis و Hazelcast از اعلان تغییر کلید پشتیبانی می‌کنند، با این حال، به لایه‌های کش محلی اجازه می‌دهند زمانی که کلیدها در یک لایه کش راه دور تغییر می‌کنند، به‌روزرسانی شوند. با ردیابی این کلیدها به صورت محلی، می توان از جستجوی راه دور در حافظه پنهان جلوگیری کرد و از جریمه ضربه حافظه پنهان جلوگیری کرد.
 عدم اعتبار به عنوان یک رویداد فوری، نه یک محدوده زمانی: وقتی قرار است جدولی به عنوان بخشی از یک تراکنش تغییر کند، حالت SQL می‌تواند تأثیر بگذارد که آیا یک درخواست در یک اتصال دیگر باید تغییرات را ببیند یا خیر. به این ترتیب، در حالی که یک تراکنش هنوز انجام نشده یا به عقب بازگردانده نشده است، هر تغییری در برابر یک جدول در طول تراکنش باید باعث شود که جدول تا زمانی که تراکنش کامل شود، بی ثبات در نظر گرفته شود. اغلب، موتورهای کش فقط یک نتیجه را قبل یا بعد از اجرای کوئری باطل می کنند.
 حافظه پنهان توزیع شده بدون ارتباط: اگر طراحی کش از یک لایه ذخیره سازی زیرین استفاده می کند، هنگامی که به عنوان یک حافظه پنهان توزیع شده استفاده می شود، بر اساس جدول هایی که در یک زمان معین روی آن ها نوشته می شود، نامعتبرها به صورت محلی انجام می شود. متأسفانه، گره های دیگر ممکن است اشیاء کش را برای یک جدول نوشته باشند، و این اشیاء باطل نمی شوند. هنگامی که برای داده‌های جلسه محلی با تداوم مشتری بالادستی استفاده می‌شود، ممکن است قابل قبول باشد، اما برای داده‌های مشترکی که نیاز به حفظ ثبات در سراسر جلسات دارند، می‌تواند باعث ایجاد مشکلات سازگاری داده‌ها شود.

منابع 

 Larson, Per-ake; Goldstein, Jonathan (2004). "MTCache: Transparent mid-tier database caching". CiteSeerX
 Altinel, Mehmet; Luo, Qiong; Krishnamurthy, Sailesh; Mohan, C.; Pirahesh, Hamid; Lindsay, Bruce G.; Woo, Honguk; Brown, Larry 2002
 "Middle-tier Database Caching for e-Business”

لینک های خارجی 

 ذخیره سازی پایگاه داده سطح متوسط برای تجارت الکترونیک

الگو:Database [[رده:نهان‌سازی پایگاه داده]]