اهمیت حافظه نهان در پایگاه داده و برنامه های سازمانی
انواع حافظه کش
حافظه نهان در همه جا وجود دارد. به عنوان مثال، CPU دارای چندین لایه کش برای کاهش تأخیر مرتبط با دسترسی به داده ها از حافظه اصلی است. با نزدیک شدن به واحد پردازش، حافظه نهان CPU بسیار سریع است. با این حال، در مقایسه با حافظه اصلی، حافظه نهان CPU بسیار کوچک است و فقط می‌تواند داده‌هایی را که اغلب به آنها دسترسی پیدا می‌کند، ذخیره کند.
برای سرعت بخشیدن به خواندن و نوشتن در درایو دیسک زیربنایی ، سیستم عامل از حافظه نهان نیز استفاده می کند. داده ها در صفحاتی خوانده می شوند که در حافظه اصلی ذخیره می شوند، بنابراین داده های دسترسی مکرر از بافرهای سیستم عامل به جای درایو دیسک ارائه می شوند. حافظه پنهان دیسک عملیات نوشتن را نیز بهبود می بخشد، زیرا تغییرات را می توان به یکباره بافر و تخلیه کرد، در نتیجه توان نوشتن را بهبود می بخشد.
از آنجایی که نمایه ها و بلوک های داده بهتر است از حافظه ارائه شوند، اکثر سیستم های پایگاه داده رابطه ای از یک لایه کش داخلی استفاده می کنند.
بنابراین حتی بدون راه‌اندازی صریح راه‌حل حافظه نهان، پیش از این یک برنامه سازمانی از چندین لایه حافظه نهان استفاده می‌کند. با این وجود، کش سازمانی اغلب یک ضرورت است و راه حل های مختلفی برای این منظور وجود دارد.
همانطور که در نمودار بالا نشان داده شده است، کش کردن مستلزم یک تبادل است. از یک طرف، دور زدن لایه دسترسی به داده های زیرین می تواند خواندن و نوشتن را سرعت بخشد. با این حال، هرچه راه‌حل ذخیره‌سازی دورتر باشد، حفظ سازگاری با سیستم پایگاه داده زیربنایی برای آن دشوارتر است.
به دلیل تضمین تراکنش های ACID، حافظه نهان پایگاه داده بسیار سازگار است، بنابراین، از منظر یکپارچگی داده، هیچ خطری برای خواندن داده های قدیمی ندارد. با این حال، موتور پایگاه داده تنها می‌تواند دسترسی به دیسک را حفظ کند، و بنابراین نمی‌تواند سربار شبکه را کاهش دهد. علاوه بر این، اگر لایه دسترسی به داده‌ها نیاز به واکشی تجمعی داشته باشد که در چندین جداول پایگاه داده قرار دارد، مجموعه نتایج یا شامل بسیاری از اتصال‌ها می‌شود، یا به چندین کوئری ثانویه نیاز دارد. هرچه الگوی دسترسی به داده پیچیده تر باشد، سرور پایگاه داده باید کار بیشتری انجام دهد و به همین دلیل، استفاده از حافظه نهان در سطح برنامه نیز رایج است.
اغلب، حافظه نهان در سطح برنامه، ذخیره‌های ارزش کلیدی هستند. هنگامی که یک مجموعه از پایگاه داده واکشی شد، می توان آن را در حافظه نهان برنامه ذخیره کرد تا هر درخواست متوالی بتواند پایگاه داده را به طور کامل دور بزند. حافظه نهان سطح برنامه می تواند از موتور پایگاه داده بهتر عمل کند زیرا می تواند سربار شبکه مرتبط با واکشی مجموعه های نتایج را دور بزند.
یکی دیگر از دلایل بسیار مهم برای استفاده از یک راه حل حافظه نهان در سطح برنامه این است که می تواند یک قلاب ایمنی برای زمانی که پایگاه داده برای تعمیر و نگهداری حذف شود، فراهم کند. اگر کش جلویی مقدار کافی داده را ذخیره کند، می‌تواند به عنوان جایگزینی موقت برای سیستم پایگاه داده عمل کند و به عملیات‌های فقط خواندنی اجازه ارائه از حافظه پنهان را بدهد. حتی اگر در حالی که سیستم پایگاه داده در دسترس نیست از عملیات نوشتن جلوگیری شود، حالت فقط خواندنی دسترسی کلی سیستم را افزایش می دهد.
با این حال، حافظه نهان در سطح برنامه دارای هزینه است، و اطمینان از خواندن مداوم دیگر یک کار بی اهمیت نیست. به دلیل ادغام شدید آن با Hibernate، کش سطح دوم می تواند از بسیاری از مسائل مربوط به سازگاری مرتبط با حافظه نهان سطح برنامه جلوگیری کند. کش سطح دوم Hibernate یک راه حل ذخیره سازی دسترسی به داده است که هدف آن کاهش بار پایگاه داده در هنگام واکشی موجودیت ها است. همراه با مولفه کش مجموعه، کش سطح دوم امکان بازیابی کل گراف موجودیت را بدون دسترسی واحد به پایگاه داده را فراهم می کند.
واکشی موجودیت ها معمولاً با انتقال حالت موجودیت در حال انتشار همراه است. بنابراین، حافظه نهان سطح دوم می تواند زمان پاسخگویی برای تراکنش های خواندن و نوشتن را بدون به خطر انداختن ثبات داده ها بهبود بخشد.
حافظه نهان سطح برنامه برای سناریوهای خواندن مفید است، در حالی که ضمانت سازگاری حافظه نهان سطح دوم برای بارگیری ترافیک نوشتن مناسب تر است.
استراتژی های همگام سازی حافظه کش
در اصطلاحات پایگاه داده، سیستم ثبت، منبع حقیقت را هنگامی که اطلاعات در میان ارائه دهندگان مختلف داده پراکنده می شود، نشان می دهد. کپی کردن داده ها، به طوری که آنها به لایه های برنامه نزدیک تر باشند، می تواند زمان پاسخگویی را بهبود بخشد و بهای همگام سازی دو کپی داده را دشوارتر کند. برای جلوگیری از خواندن متناقض و مشکلات یکپارچگی داده ها، هر زمان که تغییری در سیستم رخ می دهد، همگام سازی پایگاه داده و حافظه نهان بسیار مهم است. راه های مختلفی برای همگام نگه داشتن حافظه نهان و پایگاه داده زیربنایی وجود دارد، و در این بخش برخی از رایج ترین استراتژی های همگام سازی کش ارائه می شود.
Cache-aside
قبل از ضربه زدن به پایگاه داده، منطق برنامه، حافظه نهان را بررسی می کند تا ببیند آیا موجودیت درخواستی قبلاً بارگذاری شده است یا خیر. هر زمان که یک موجودیت تغییر کند، برنامه باید هم پایگاه داده و هم حافظه پنهان را به روز کند.
اختلاط منطق برنامه با مفاهیم مدیریت حافظه نهان، اصل مسئولیت واحد را می شکند. به همین دلیل، انتقال منطق کش به یک رهگیر AOP (برنامه نویسی جنبه گرا) عمل خوبی است، بنابراین منطق مدیریت کش را از کد منطق تجاری جدا می کنیم.
Read-through
به جای مدیریت هر دو پایگاه داده و کش، لایه برنامه تنها با سیستم کش تعامل دارد. منطق مدیریت پایگاه داده در پشت API ذخیره سازی پنهان است.
در مقایسه با استفاده از حافظه نهان، منطق دسترسی به داده ها ساده شده است زیرا تنها یک منبع داده برای برقراری ارتباط وجود دارد.
هنگام واکشی یک موجودیت، کش بررسی می‌کند که آیا موجودیت درخواستی قبلاً در حافظه نهان موجود است یا خیر، و در صورت از دست دادن حافظه نهان، موجودیت از پایگاه داده بارگیری می‌شود.
Write-invalidate
اگر موجودیت اصلاح شود، حافظه نهان تغییر را در پایگاه داده اصلی منتشر می کند و ورودی مرتبط را از حافظه نهان حذف می کند. دفعه بعد که این موجودیت درخواست شد، سیستم کش قرار است آخرین نسخه را از پایگاه داده بارگیری کند.
Write-through
اگر موجودیت اصلاح شود، تغییر به پایگاه داده اصلی و حافظه نهان نیز منتشر می شود.
اگر لایه کش از تراکنش‌های JTA پشتیبانی کند، حافظه نهان و پایگاه داده می‌توانند به یکباره متعهد شوند. اگرچه تراکنش‌های XA می‌توانند توسعه را ساده‌تر کنند، پروتکل تعهد دو فازی سربار کارایی قابل توجهی را متحمل می‌شود.
یک جایگزین این است که از قفل های نرم در سمت حافظه نهان استفاده کنید تا تغییرات ورودی حافظه نهان را تا زمانی که تراکنش پایگاه داده متعهد شود پنهان کنید، به طوری که تا زمانی که قفل آزاد نشود، سایر تراکنش های همزمان باید موجودیت را از پایگاه داده بارگیری کنند.
Write-behind
اگر سازگاری قوی اجباری نباشد، درخواست‌های تغییر را می‌توان در نوبت قرار داد و به یکباره در پایگاه داده ریخت.
این استراتژی توسط زمینه پایداری JPA استفاده می‌شود، تمام انتقال‌های حالت موجودیت به سمت پایان تراکنش در حال اجرا یا قبل از اجرای یک پرس و جو انجام می‌شود.
حافظه نهان پایگاه داده
اکثر موتورهای پایگاه داده از مکانیسم های کش داخلی برای سرعت بخشیدن به عملیات خواندن و نوشتن استفاده می کنند. رایج‌ترین مؤلفه کش پایگاه داده، بافرهای درون حافظه است، اما ممکن است مؤلفه‌های دیگری مانند کش طرح اجرا یا بافر نتیجه پرس و جو نیز وجود داشته باشد. حتی بدون حافظه نهان پایگاه داده، سیستم عامل اصلی ممکن است برای صفحات داده ذخیره سازی کند. برخلاف کش های سطح برنامه، کش پایگاه داده سازگاری داده ها را به خطر نمی اندازد.
حافظه نهان پایگاه داده به دلیل خواندن و نوشتن، برای لایه دسترسی به داده شفاف است. حتی با ظهور SSD (درایو حالت جامد)، دیسک ها هنوز تاخیر بسیار بالاتری نسبت به RAM دارند. برای این منظور، به جای رفتن به دیسک، بسیار منطقی است که داده هایی را که اغلب به آنها دسترسی پیدا می کنید از حافظه بارگیری کنید.
اوراکل
اوراکل مکانیسم های متعددی برای ذخیره سازی دارد، مانند:
Buffer pool: ذخیره بلوک های داده ای که از درایو دیسک زیرین بارگیری می شوند.
Shared pool: ذخیره عبارات SQL تفسیر شده، ابرداده های شی طرحواره، اعداد دنباله.
Large pool: نتایج را برای پرس‌و‌جوهای موازی، بافرهای بزرگ ورودی/خروجی که برای مدیریت بازیابی و پشتیبان‌گیری یا رویه‌های بازیابی استفاده می‌شوند، ذخیره می‌کند.
Result cache: نتایج را برای پرس و جوهای SQL (هنگام استفاده از راهنمایی پرس و جو RESULT_CACHE) و توابع PL/SQL (هنگام استفاده از دستورالعمل RESULT_CACHE) ذخیره می کند.
در سیستم های یونیکس، تمام ورودی/خروجی ها از حافظه نهان صفحه سیستم عامل عبور می کنند. با این حال، همان داده‌ها در مخزن بافر ذخیره می‌شوند، بنابراین بلوک‌های داده دو بار کش می‌شوند. به همین دلیل، I/O مستقیم مطلوب است زیرا می تواند کش فایل سیستم را دور بزند و کش صفحه سیستم عامل می تواند برای سایر فرآیندهای سیستم استفاده شود.
در سیستم های یونیکس، تمام ورودی/خروجی ها از حافظه نهان صفحه سیستم عامل عبور می کنند. با این حال، همان داده‌ها در مخزن بافر ذخیره می‌شوند، بنابراین بلوک‌های داده دو بار کش می‌شوند. به همین دلیل، ورودی/خروجی مستقیم مطلوب است زیرا می‌تواند حافظه نهان سیستم فایل را دور بزند و کش صفحه سیستم عامل برای سایر فرآیندهای سیستم مورد استفاده قرار گیرد.
همچنین مواردی وجود دارد که اوراکل از مخزن بافر برای ذخیره کردن بلوک‌های داده استفاده نمی‌کند (مانند عملیات فضای جدول TEMP، ستون‌های LOB با استفاده از گزینه ذخیره‌سازی NOCACHE)، در این صورت حافظه نهان سیستم عامل ممکن است برای افزایش سرعت عملیات خواندن و نوشتن مناسب باشد.
اگرچه هر ساختار کش را می توان به صورت دستی پیکربندی کرد، اغلب ایده خوبی است که این مسئولیت را به مکانیزم مدیریت حافظه خودکار که به طور پیش فرض فعال است، بسپارید.
SQL SERVER
برای ارائه زمان پاسخ بسیار کم به تراکنش، SQL Server برای کاهش عملیات I/O (که منبع مسائل مربوط به کارایی در بسیاری از سیستم های پایگاه داده هستند) تلاش می کند. به همین دلیل، موتور پایگاه داده سعی می‌کند تا حد امکان از حافظه سیستم استفاده کند تا داده‌ها و صفحات دیسک فهرستی با دسترسی مکرر به جای درایو دیسک، از RAM ارائه شوند.
پس از راه اندازی، SQL Server بخشی از حافظه سیستم را اختصاص می دهد و از آن به عنوان یک مخزن بافر استفاده می کند. مخزن بافر به چندین صفحه 8 کیلوبایتی تقسیم شده است. هم صفحات داده و هم صفحات فهرست از دیسک به صفحات بافر خوانده می شوند و هنگامی که صفحات درون حافظه اصلاح می شوند، بر روی دیسک نوشته می شوند.
SQL Server 2014 از افزونه های بافر pool پشتیبانی می کند که به آن اجازه می دهد از درایوهای SSD برای افزایش اندازه حافظه نهان بافر فراتر از قابلیت های حافظه موجود سیستم فعلی استفاده کند.
PostgreSQL
برای بهبود عملکرد عملیات خواندن و نوشتن، PostgreSQL به شدت به قابلیت‌های ذخیره‌سازی سیستم عامل اساسی متکی است. با این حال، اکثر سیستم‌عامل‌ها از سیاست جایگزینی صفحه LRU (که اخیراً استفاده شده است) استفاده می‌کنند که از الگوهای دسترسی به داده‌ها یا سایر ملاحظات مرتبط با پایگاه داده بی‌اطلاع است. به همین دلیل، PostgreSQL یک ساختار بافر مشترک تعریف می‌کند که صفحات دیسک را در ورودی‌های کش صفحه درون حافظه ۸ کیلوبایتی ذخیره می‌کند. اندازه بافر مشترک از طریق ویژگی پیکربندی shared_buffers کنترل می شود. برخلاف کش سیستم عامل، بافرهای مشترک از یک الگوریتم LFU (کمترین استفاده از آن) به نام Clock Sweep استفاده می کنند که تعداد دفعات استفاده از صفحه دیسک را شمارش می کند.
هرچه بیشتر از یک صفحه دیسک استفاده شود، مدت بیشتری در حافظه نهان داخلی پایگاه داده بافر مشترک باقی می ماند. همانطور که گفته شد، ساختار بافر مشترک برای ذخیره بلوک های داده ای که اغلب به آنها دسترسی دارند مفیدتر است، در حالی که کش سیستم عامل را می توان برای هر چیز دیگری استفاده کرد. حافظه نهان بافر مشترک نباید خیلی بالا تنظیم شود زیرا موتور پایگاه داده برای سایر عملیات نیز به حافظه نیاز دارد (مرتب سازی، هش کردن، ایجاد نمایه ها، جاروکردن). اگرچه ساختار بافرهای مشترک برای سرعت بخشیدن به خواندن و نوشتن بسیار مهم است، تمرین خوبی است که اندازه بافر مشترک را به اندازه مجموعه کاری فعلی محدود کنید، بنابراین حافظه کافی برای سایر کارهای مرتبط با پایگاه داده باقی می ماند.
MySQL
MySQL از بافر داخلی خود برای کش کردن داده ها و ایندکس ها استفاده می کند. مخزن بافر به عنوان یک لیست پیوندی از صفحات حافظه پیاده سازی می شود. اگر اندازه pool بافر کوچکتر از اندازه کلی فضای جدول InnoDB باشد، یک الگوریتم مبتنی بر LRU برای توزیع ورودی های صفحه قدیمی تر استفاده می شود.
اندازه pool توسط ویژگی پیکربندی innodb_buffer_pool_size داده می‌شود که در حالت ایده‌آل باید طوری تنظیم شود که بتواند تمام داده‌ها و فهرست‌ها را در حافظه نگه دارد. باید دقت شود که حافظه کافی برای سیستم عامل و همچنین سایر ساختارها و فرآیندهای MySQL (به عنوان مثال رشته های تخصیص داده شده برای هر اتصال جداگانه، بافرهای مرتب سازی، کش کوئری) وجود داشته باشد.
در لینوکس، برای جلوگیری از بافر مضاعف ناشی از مکانیسم کش سیستم عامل، ویژگی پیکربندی innodb_flush_methoda باید روی O_DIRECT تنظیم شود. با این وجود، حافظه نهان سیستم عامل برای ذخیره گزارش تراکنش InnoDB (برای اطمینان از تراکنش‌های ACID استفاده می‌شود)، گزارش باینری (که برای تکثیر پایگاه داده استفاده می‌شود) و دیگر ساختارهای MySQL که توسط مخزن بافر InnoDB پوشش داده نمی‌شوند، مفید است.
ضروری است، اما کافی نیست
حافظه نهان پایگاه داده برای یک برنامه سازمانی با کارایی بالا بسیار مهم است. با این حال، حافظه نهان پایگاه داده فقط برای یک گره اعمال می شود، و اگر اندازه پایگاه داده بزرگتر از ظرفیت یک گره باشد، این راه حل به تنهایی دیگر کافی نیست. یک راه حل، استفاده از اشتراک گذاری پایگاه داده است، اما این کار بدون چالش نیست. حتی اگر حافظه نهان پایگاه داده عملکرد را به طور قابل توجهی بهبود بخشد، سربار شبکه همچنان نقش مهمی در زمان پاسخ کلی تراکنش ایفا می کند. اگر برنامه از نمودارهای موجودات استفاده می کند، واکشی یک نمودار کامل ممکن است به تعداد زیادی اتصال یا بسیاری از دستورات انتخابی ثانویه نیاز داشته باشد. به همین دلیل منطقی است که کل مجموعه موجودیت را کش کنیم و آن را به لایه برنامه نزدیکتر کنیم. اگر سیستم سازمانی تنها به سیستم پایگاه داده برای ارائه درخواست های خواندن متکی باشد، پایگاه داده به یک نقطه شکست تبدیل می شود. این در دسترس بودن را می توان با استفاده از تکرار پایگاه داده افزایش داد. با این حال، اگر همه گره های پایگاه داده با هم قرار گیرند (برای کاهش سربار همگام سازی ناشی از تأخیر شبکه)، اگر مرکز داده با قطع برق ناگهانی مواجه شود، سیستم پایگاه داده همچنان می تواند در دسترس نباشد. به همه این دلایل، استفاده از راه حل ذخیره سازی لایه کاربردی برای رفع محدودیت های حافظه پنهان پایگاه داده، تمرین خوبی است.
حافظه نهان در سطح برنامه
ذخیره سازی در سطح برنامه حافظه نهان برنامه یک ضرورت برای برنامه های کاربردی سازمانی با کارایی بالا است و این بخش قصد دارد این موضوع را با جزئیات بیشتری بررسی کند. مهم نیست که موتور پایگاه داده چقدر خوب تنظیم شده است، زمان پاسخ عبارت ها به شدت به بارگذاری پایگاه داده ورودی بستگی دارد. افزایش ترافیک منجر به مناقشه زیادی در منابع سیستم پایگاه داده می شود که می تواند منجر به زمان پاسخ بیشتر شود.
به عنوان مثال، اکثر برنامه های کاربردی اینترنتی نقشه سایت را نشان می دهند که توسط ربات های موتور جستجو برای فهرست بندی محتوای سایت مورد نظر و در دسترس قرار دادن آن برای جستجو استفاده می شود. از منظر تجاری، داشتن رتبه صفحه بالا بسیار مطلوب است زیرا می تواند به درآمد بیشتر تبدیل شود. با این حال، ربات موتور جستجو می تواند یک افزایش ناگهانی ترافیک ایجاد کند، که به نوبه خود می تواند منجر به افزایش زمان پاسخ به تراکنش شود. متأسفانه زمان پاسخ دهی بالا می تواند بر رتبه صفحه سایت تأثیر بگذارد. همانطور که گفته شد، زمان پاسخ ترجمه باید نسبتاً کم باشد حتی در هنگام بارهای ترافیکی بالا.
بنابراین، حافظه نهان در سطح برنامه می‌تواند جهش‌های ترافیک را افزایش دهد زیرا پیچیدگی واکشی کش (1) Oاست. علاوه بر این، اگر حافظه نهان در سطح برنامه بخش قابل توجهی از کل مجموعه داده را در خود نگه دارد، برنامه همچنان می تواند کار کند (حتی اگر در حالت فقط خواندنی باشد) زمانی که پایگاه داده برای تعمیر و نگهداری یا به دلیل یک رویداد فاجعه بار خاموش می شود.
شرکت مهندس پیشگان آزمون افزار یاس، خدمات زیر را در حوزه ارزیابی و پایش کارایی نرم افزار ارائه می دهد:
آموزش روشهای ارزیابی کارایی سامانه های نرم افزاری از طریق آزمون‌های بار و فشار
اجرای آزمون‌های بار و فشار برروی سامانه های نرم افزاری
تهیه و آموزش ابزارهای تست پرفورمنس (تست بار و فشار) همچون WPLT و LoadTest
پایش و مانیتورینگ شاخص های کارایی سامانه های نرم افزاری از طریق ابزارهای مدیریت کارایی همچون AppDynamicsو DynaTrace
نویسنده : شرکت مهندس پیشگان آزمون افزار یاس
مراجع
[1]-http://docs.oracle.com/database/121/TGDBA/pfgrf_os.htm#TGDBA94410
[2]-https://docs.oracle.com/database/121/TGDBA/memory.htm#TGDBA505
[3]-https://msdn.microsoft.com/en-us/library/dn133176.aspx
[4]-http://www.postgresql.org/docs/current/static/runtime-config-resource.html
[5]-http://dev.mysql.com/doc/refman/5.7/en/innodb-parameters.html#sysvar_innodb_flush_method
[6]-http://www.oracle.com/us/products/middleware/data-integration/goldengate/overview/index.html
[7]-https://github.com/linkedin/databus
[8]-https://msdn.microsoft.com/en-us/library/cc627369.aspx
[9]-http://www.postgresql.org/docs/current/static/logicaldecoding.html