Обзор буферного кэша

Оценить
(0 голоса)

Является одним из основных инструментов, используемых системами баз данных для сокращения дискового ввода/вывода. СУБД получает сегмент памяти совместного использования и обычно оставляет в стороне большую его часть, чтобы произвести размещение блоков базы данных (также называемых страницами БД). Если для транзакции необходим блок, он будет считан с диска и сохранен в буферном кэше; последующие транзакции, которым будет необходим этот блок, смогут получить его из памяти быстрее, чем с диска.

На практ ике для размещения каждого блока базы данных, необходимого для транзакций. редко бывает достаточно памяти в буферном кэше, поэтому блоки не могут содержаться в памяти неограниченно долго. СУБД используют алгоритм замещения наиболее давней по использованию страницы для сохранения тех блоков, к которым наиболее часто происходит обращение, и замены тех блоков, к которым оно происходит реже всего.

В некоторых СУБД предусмотрены также альтернативные стратегии для дискриминации или предпочтения блоков в выбранных таблицах. Нет смысла, например, в кэшировании блоков из редко используемых таблиц; и наоборот, некоторые небольшие таблицы используются чаще, поэтому они будут надолго помещены в кэш.

Несмотря на то, что буферные кэши баз данных решительным образом влияют на эффективность функционирования приложений OLTP, не все операции баз данных используют буферные кэши при запросах больших таблиц. В средах DSS, например, Oracle и Informix XPS не используют кэш при параллельных запросах больших таблиц. Это объясняется тем, что размеры таблиц часто оказываются слишком большими по сравнению с размером кэша, и в процессе сканирования таблицы происходит переполнение кэша, что не приносит никаких преимуществ. DB2 для Solaris использует буферный кэш для сканирования таблиц DSS, хотя буферные кэши необязательно должны иметь большой объем, поскольку блоки очень быстро сбрасываются.

Более всего эффективность буферного кэша проявляется тогда, когда при доступе к данным наблюдаются отклонения, то есть, к одним данным обращение происходит чаще, чем к другим. Проиллюстрировать обращения с отклонениями можно на конкретном примере, Обыкновенно по субботам автор и его супруга должны произвести некоторое количество финансовых транзакций. Они оплачивают счета за продукты, газ и прочие расходы, пересылают деньги по счетам и изымают наличность из банковского кассового автомата. Поскольку они являются такими активными покупателями, то детали их счетов будут по несколько раз оказываться в буферном кэше БД кредитного союза. Обращение к счету кредитной карточки будет происходить несколько раз, проверка их счета может осуществляться множество раз, а доступ к депозитным счетам супругов, возможно, вообще пе будет осуществляться. Счет, который вероятнее всего останется в буферном кэше базы данных, является счетом кредитной карточки, поскольку обращение к нему происходит чаще всего. На практике, естественно, объем субботних финансовых транзакций таков, что ни один из индивидуальных счетов не будет, вероятно, оставаться в кэше очень долго, однако этот пример иллюстрирует доступ с отклонениями, или неоднородный доступ, к трем счетам супругов.

Подобным образом и в бизнесе часто оказывается, что 80% деловых связей приходится на 20% заказчиков, поэтому доступ к отдельным строкам базы данных происходит чаще, чем к другим. Этот же принцип используется во множестве сред баз данных,

Если доступ к данным однороден (обращение ко всем строкам осуществляется практически равномерно), то кэширование принесет мало пользы. При доступе к данным с отклонением кэширование может значительно сократить процент операций чтения, которые необходимы для операций ввода/вывода на физическом диске. Отклонение данных - обычное явление в приложениях OLTP; менее всего встречается в приложениях DSS.

Мониторинг буферного кэша
Руководство по частоте успешных обращений к буферному кэшу
Рабочий пример
Большинство рабочих нагрузок
Задание размера буферного кэша

Добавить комментарий


Защитный код
Обновить