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

 

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

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

Тоу Д. Настройка SQL. Для профессионалов — СПб.: Питер, 2004. — 333 c.
ISBN 5-94723-959-0
Скачать (прямая ссылка): nastroykasqldlyaprof2004.djvu
Предыдущая << 1 .. 130 131 132 133 134 135 < 136 > 137 138 139 140 141 142 .. 161 >> Следующая


¦ Объедините повторяющиеся запросы в единственный новый запрос.

¦ Слейте повторяющиеся запросы в соединения, которые добавляются к единственному запросу, который уже выполняется приложением.

Перед тем как я рассмотрю эти три решения, возьмем типичный повторяющийся запрос, который получает ценовую историю для данного продукта:

SELECT Product_Price FROM Pnce_List WHERE Product_ID = :1 AND Effective_Date <= : today ORDER BY Effective_Date DESC:

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

¦ Сколько раз подряд приложению необходимо запустить запрос, чтобы выполнить задачу?

¦ Откуда параметры : 1 и : today, на основе которых выполняется запрос, получают свои значения?

¦ Сколько строк нужно будет предварительно считать и кэшировать, чтобы все данные, которые могут понадобиться приложению, могли быть получены из кэша? Насколько часто этот кэш будет использоваться в будущем?

¦ Каков диапазон количества строк и среднее количество строк, возвращаемое запросом? Какую часть этих строк приложение в действительности использует?

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

Как избежать повторяющихся запросов при помощи кэширования

Если набор возможных значений Product_ID невелик по сравнению с тем, сколько раз выполняется запрос в нашем примере, то зто именно тот случай, когда нужно кэшировать весь набор. Например, у нас может быть 10 различных значений Product_ID, а запрос повторяется 1000 раз. В этом случае имеет смысл предварительно кэшировать результаты для всего набора и считывать их из кэша, вместо того, чтобы повторно выполнять запросы к базе данных. Например, вы могли бы использовать такой запрос:

SELECT Product_Price FROM Price_List

WHERE Effective Date <- :today

DRDER BY ProductJD ASC. Effecti ve_Date DESC:

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

10. Решения сложных проблем

тывания в первом варианте превышает количество значений Product ID, второй вариант предлагает два преимущества в терминах стоимости доступа к базе данных.

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

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

КЭШИРОВАНИЕ В ПРИЛОЖЕНИИ И КЭШИРОВАНИЕ В БАЗЕ ДАННЫХ --------------------------------

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

Прежде всего при доступе к нему приложение не генерирует сетевой трафик. Он максимально близок к самому приложению.

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

Цена, которую приходится платить за быстрый кэш приложения, — это увеличенная сложность приложения. Несколько простых статических кэшей для повторно считываемых наборов строк достаточно легко поддерживать, но если вы увлечетесь, то воссоздадите функциональность программного обеспечения базы данных в собственном приложении. В экстремальном случае окажется, что вы используете Oracle, SQL Server или DB2 как простой файловый сервер, хоть и со звучным именем, а ваше приложение будет ответственно за всю работу, которую обычно делает база данных, имея за спиной на порядок меньше разработок, чем в этих базах данных.
Предыдущая << 1 .. 130 131 132 133 134 135 < 136 > 137 138 139 140 141 142 .. 161 >> Следующая
Реклама
Авторские права © 2009 AdsNet. Все права защищены.
Rambler's Top100