Информационный сайт

 

Реклама
bulletinsite.net -> Книги на сайте -> Программисту -> Тоу Д. -> "Настройка SQL. Для профессионалов" -> 14

Настройка SQL. Для профессионалов - Тоу Д.

Тоу Д. Настройка SQL. Для профессионалов — СПб.: Питер, 2004. — 333 c.
ISBN 5-94723-959-0
Скачать (прямая ссылка): nastroykasqldlyaprof2004.djvu
Предыдущая << 1 .. 8 9 10 11 12 13 < 14 > 15 16 17 18 19 20 .. 161 >> Следующая


С небольшими изменениями кэш заполняется и поддерживается достаточно простым способом. Каждый раз, когда базе данных необходимо обратиться к блоку данных, еще не скопированному в кэш, она запрашивает операцию чтения с диска (физический ввод-вывод) и помещает только что полученный блок в голову буферного списка. Так как длина списка во время работы базы данных остается
Кэширование в базе данных

31

фиксированной, добавление блока со стороны головы приводит к тому, что блок в хвосте списка удаляется (то есть более не является кэшированным).

ПРИМЕЧАНИЕ-----------------------------------------------------------------------

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

Когда база данных обнаруживает, что нужный блок данных уже находится в списке (что требует строго логического ввода-вывода), она перемещает этот блок из текущего положения в голову списка. Так как блок, участвующий в логическом вводе-выводе, всего лишь перемещается, а не добавляется в список, никакие блоки из хвоста списка не выталкиваются. И снова база данных обрабатывает перемещение логического блока при помощи указателей; на физическом уровне данные в памяти не копируются.

Так как при выполнении каждого логического ввода-вывода блоки перемещаются обратно в сторону головы списка, в итоге кэш становится отсортированным: последние по времени использования {most recently used, MRU) блоки находятся ближе к голове, а блоки с наиболее давним использованием (least recently used, LRU) — к концу списка. Обычно блоки, к которым обращение производится часто, называются горячими, а редко используемые блоки — холодными. Однако насколько блок является горячим или холодным, зависит от того, имеете ли вы в виду обращение при помощи логического или физического ввода-вывода. Наиболее часто используемые блоки моїут быть горячими с точки зрения логического ввода-вывода, но, в то же время, с точки зрения физического ввода-вывода они холодные, так как никогда не покидают кэша.

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

ПРИМЕЧАНИЕ ----------------------------------------------------------------------

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

У схемы кэширования LRU есть несколько важных для настройки следствий.

¦ Быстрее всего осуществляется доступ к MRU-блокам, так как они находятся в кэше. Ho ошибочным будет считать, что кэшированный доступ практически
32

2. Основы доступа к данным

ничего не стоит. Если вы подсчитаете полные затраты времени обработки для логического ввода-вывода, то они будут в 30-200 раз меньше, чем для физического ввода-вывода. Однако, это значение не настолько мало, чтобы полностью игнорировать логический ввод-вывод, ведь кэширование так хорошо работает потому, что логический ввод-вывод выполняется приблизительно в сто раз чаще, чем физический. Даже если вы исключите все операции физического ввода-вывода, производительность все же может серьезно страдать из-за затрат на обработку процессором ненужных операций логического ввода-вывода. Если же вы поработаете над сокращением количества операций логического ввода-вывода, необходимость в физическом вводе-выводе в большинстве случаев отпадет сама — конечно же, если у вас есть кэш разумного размера.

¦ Если к блоку не обращаются операции логического ввода-вывода, то в обычной хорошо настроенной системе он перейдет из головы списка к хвосту и будет удален через несколько минут. Поэтому блок может быть самым горячим в терминах физического ввода-вывода, если одна операция ввода-вывода совершается для него каждые несколько минут. Если же обращения к этому блоку производятся чаще, то блок становится хорошо кэшированным и требует меньше физических операций ввода-вывода.
Предыдущая << 1 .. 8 9 10 11 12 13 < 14 > 15 16 17 18 19 20 .. 161 >> Следующая
Реклама
Авторские права © 2009 AdsNet. Все права защищены.
Rambler's Top100