УДК 004.65 УВЕЛИЧЕНИЕ СКОРОСТИ ВЫПОЛНЕНИЯ ЗАПРОСОВ К БАЗЕ ДАННЫХ

УДК 004.65
А.В. КАМЕНЕВ, Д.В. КАМЕНЕВ
A.V. KAMENEV, D.V. KAMENEV
УВЕЛИЧЕНИЕ СКОРОСТИ ВЫПОЛНЕНИЯ ЗАПРОСОВ К БАЗЕ ДАННЫХ
ПУТЕМ ИСПОЛЬЗОВАНИЯ УСОВЕРШЕНСТВОВАННОЙ ТЕХНОЛОГИИ
КЭШИРОВАНИЯ SQL-ЗАПРОСОВ
INCREASE THE EXECUTION SPEED OF QUERIES TO THE DATABASE BY
USING IMPROVED CACHING SQL-QURIES TECHNOLOGY
Аннотация. В статье рассматривается один из способов усовершенствования механизма
кэширования результатов выполнения SQL-запросов. Технология основывается на анализе запроса и разбиении
его на составные части, а так же на выявлении наиболее часто встречающихся запросов.
Ключевые слова: кэширование, база данных, СУБД, запрос выборки, приложение, анализ.
Abstract. In this article considered one of the ways to improve the mechanism of caching the results of
execution of SQL-queries. The technology is based on an analysis of the request and splitting it into component parts
and on identifying the most popular queries.
Keywords: caching, database, DBMS, query, application, analysis.
Введение
Современные тенденции развития информационных технологий требуют постоянного
внимания к повышению производительности. Всё чаще начинают применяться специальные
механизмы, направленные на ускорение доступа к памяти посредством специального
буфера, содержащего информацию, которая может быть запрошена с наибольшей
вероятностью, называемые механизмами кэширования. Особенно актуально их применение
при многочисленных обращениях к системе управления базами данных (СУБД), на
взаимодействии с которой основано значительное число современных информационных
систем и приложений. Грамотная реализация механизмов кэширования позволит снизить
нагрузку на СУБД.
Механизм кэширования на основе анализа запросов
В настоящее время в некоторых СУБД (например, MySql), реализован механизм
кэширования запросов, однако он заключается в сохранении результатов выполнения SQLзапроса без какого-либо анализа. Эффективность такого метода будет ощутима лишь в тех
случаях, когда одни и те же запросы повторяются довольно часто, а при этом раздел WHERE
в них содержит условия, позволяющие значительно сократить объем информации,
хранящейся в таблице. То есть, например, если в таблице имеется около ста записей, а
запросом выбирается девяносто семь, то применение механизма кэширования только
усложнит работу СУБД.
Нередко встречаются случаи, когда несколько раз поступает запрос одной и той же
структуры, но значения параметров различаются в зависимости от потребностей
пользователя (например, в системе электронного расписания ВУЗа студенты хотят видеть
занятия только своей группы). Тогда нет необходимости сохранять результат каждого такого
запроса, ведь повторение сводится к минимуму.
Помимо СУБД, кэширование запросов активно внедряется во многие популярные
web-фреймворки. Но в большинстве случаев механизм требует явного указания того,
результаты каких запросов должны быть подвергнуты записи в кэш, что создает
дополнительные трудности для программиста при создании приложений. Помимо этого,
существует дополнительная проблема хранения выбранных данных. Гораздо проще
организовать этот процесс посредством СУБД, чем определять под него дополнительное
место на дисковом пространстве сервера приложения.
Таким образом, необходимо из всех запросов выборки, поступающих к базе данных,
выявлять наиболее часто повторяющиеся, записывать их результаты в кэш и проделывать
последующие выборки (если они подходят под условия запроса, результаты выполнения
которого были занесены в кэш) на основе этих данных. Стоит отметить, что подобный
механизм следует применять лишь для таблиц, содержащих достаточно большое количество
данных, иначе эффективность его значительно снижается.
Вся работа с кэшем включает в себя три составляющие:
– запись данных в кэш;
– извлечение данных из кэша;
– удаление данных из кэша.
– изменение содержимого кэша.
На рисунке 1 представлена общая схема организации работы с кэшем.
Рисунок 1 - Общая схема работы механизма
Запись данных в кэш
Запись в кэш осуществляется по следующему принципу. Существует определенное
количество запросов, которые одновременно могут находиться в кэше. Это число должно
быть задано статически, чтобы избежать переполнения, либо динамически, но в таком случае
необходимо при каждом обращении к СУБД получать количество находящихся в кэше
результатов и вычислять, достаточно ли места для осуществления записи, ведь под кэш
выделяется заранее определенный объем дискового пространства.
На этом же этапе необходимо проводить анализ поступающих запросов. Для того
чтобы в кэш не попадали редко встречающиеся запросы, может быть реализован следующий
механизм. Для каждого приложения понятие о частоте может значительно различаться.
Следовательно, необходимо вычислять коэффициент, который бы показывал, как часто тот
или иной запрос повторяется по отношению к общему числу запросов. Данный коэффициент
может быть вычислен по следующей формуле:
K = M/N
(1),
где K – коэффициент, показывающий, как часто встречается определенный запрос, M –
число, показывающее, сколько раз встречался этот запрос, N – общее число запросов. Так
как в зависимости от времени ситуация может меняться, необходимо вычислять числа M и N
на заранее определенном промежутке времени.
Таким образом, чем меньше значение коэффициента для запроса, тем ниже будет
приоритет записи его результатов в кэш.
Однако недостаточно вычислять данный коэффициент для всего запроса. С целью
повышения эффективности работы механизма раздел WHERE необходимо разбивать на
части с учетом следующих основных критериев:
1) Если раздел содержит один или несколько логических операторов AND,
соединяющих условия, необходимо выделить каждое из них в отдельный запрос и
аналогичным образом вычислить коэффициент для всех из полученный запросов.
2) Если в условии содержится оператор сравнения, выбирать для кэширования
диапазон между наименьшим и наибольшим значениями, удовлетворяющими этому
условию, которые достаточно часто встречались за определенный промежуток времени.
3) Если в условии находится проверка на равенство/неравенство, коэффициент
вычисляется для этого условия.
4) При использовании логического оператора OR, необходимо для каждого из
условий, которые он объединяет, применить описанные правила, а в кэш записать
объединение двух результатов.
В случаях, когда запрос состоит из нескольких условий, объединенных логическим
оператором AND, целесообразно записывать в кэш возможные их комбинации (декартово
произведение). Например, если запрос состоит из трех условий, в кэш попадут семь
запросов.
Извлечение данных из кэша
Извлечение данных из кэша так же будет иметь непривычный вид.
Каждый поступающий запрос должен проходить проверку на наличие его результатов
в кэше. Для этого должен существовать список активных запросов, по которому и будет
производиться поиск. В случае, если запроса в этом списке нет, он проходит ранее
описанную процедуру анализа и подсчета коэффициентов. При этом, общее число запросов
должно увеличиваться на единицу. Если же запрос (или часть запроса) найден в списке или
подходит под условия более обширного запроса, то выборка производится уже по тем
данным, которые находятся в кэше.
Удаление данных из кэша
Удаление из кэша результатов выборки для определенного запроса происходит лишь
в случае, когда он вытесняется другим запросом.
Изменение данных в кэше
В случае, если любая таблица базы данных была каким-либо образом
модифицирована (добавлены новые данные, удалены или изменены существующие),
необходимо проверить, не находятся ли в кэше результаты выполнения запросов, связанные
с ней. Если такие записи будут найдены, необходимо заменить все данные кэша, в запросах
которых фигурирует эта таблица, на новые.
Организация кэша
Сам кэш представляет собой временные таблицы, которые находятся на том же
сервере, где и база данных. Список запросов представляет собой либо список строк,
содержащих запросы, либо список вычисленных хэш-сумм, сравнение с которыми
производится для каждого приходящего от системы или приложения запроса выборки (или
его части, если условий в разделе WHERE несколько).
Кроме того, существует необходимость в хранении списка таблиц, результаты
выборки из которых находятся в кэше, с помощью чего значительно упрощается задача
определения, какие данные кэша должны быть подвергнуты изменениям вследствие
модификации исходной таблицы.
В ряде случаев запрос не подлежит кэшированию:
1) В случае, если пользователь имеет права не на всю таблицу, а только на
определенные поля таблицы. Это исключение – следствие того, что кэш запросов один для
всех пользователей, а права доступа проверяются лишь на уровне таблиц.
2) Не кэшируются запросы, содержащие функции, возвращающие результат, который
изменяется с течением времени, например, запросы, получающие в качестве результата или
использующие в условии текущую дату.
Заключение
Конечно, данный механизм не гарантирует значительного увеличения скорости
выполнения SQL-запросов абсолютно для всех систем или приложений, ведь условия работы
от системы к системе могут сильно различаться. Стоит учитывать, что подобный подход
может быть неэффективен для приложений и систем с большим количеством запросов на
изменение данных. Однако в подавляющем большинстве случаев эффект от применения
подобного механизма кэширования будет достаточно ощутимым.
СПИСОК ЛИТЕРАТУРЫ
1. Дэвидсон Л. Проектирование баз данных на SQL Server 2000. – Бином, 2009. –
631 c.
2. Бейли Л. Изучаем SQL. – СПб: Питер, 2012.
3. Наумов А.Н., Вендров А.М., Иванов В.К. Системы управления базами данных и
знаний. – М.: Финансы и статистика, 2010. – 352 c.
4. Редько В.Н., Бассараб И.А. Базы данных и информационные системы. – М.:
Знание, 2011. – 602 c.
5. Аткинсон Л. MySQL. Библиотека профессионала. – М.: Вильямс, 2010. – 624 c.
Каменев Александр Владимирович
ФГБОУ ВПО Госуниверситет-УНПК, г. Орел
студент кафедры «Информационные системы»
Тел.: +7 (910) 208-64-88
E-mail: alex57_95@mail.ru
Каменев Дмитрий Владимирович
ФГБОУ ВПО Госуниверситет-УНПК, г. Орел
Ведущий инженер ИВЦ
Тел.: +7 (910) 308-34-24
E-mail: dim_2789@mail.ru