Кэширование в базе данных 31

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

ПРИМЕЧАНИЕ

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

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

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

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

ПРИМЕЧАНИЕ

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

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

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

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

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

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

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

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

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

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

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

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

Таблицы

Таблицы представляют собой основу реляционной базы данных. Реляционная теория описывает таблицы как абстрактные объекты, не придавая значения порядку составляющих их строк и столбцов. Однако таблицы также существуют в физической форме на диске сервера баз данных, причем здесь порядок следования элементов уже ощутимо влияет на производительность. Если приложение запрашивает байты, физически хранящиеся на диске или в кэше в памяти, серверные процессы должны уметь обращаться к ним.

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

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