حافظه پنهان پایگاه داده

از ویکی‌پدیا، دانشنامهٔ آزاد

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

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

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

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

سودها[ویرایش]

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

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

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

مشکلات در پیاده‌سازی‌ها[ویرایش]

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

منابع[ویرایش]

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