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

 

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

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

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


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

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

283

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

Иногда невозможно заранее угадать, насколько селективным будет поиск, если не выполнить его. Селективность часто зависит от конкретных данных приложения. Например, с большой вероятностью приложение вернет больше соответствий для фамилии «Smith», чем для «Kmetec», но вы совершенно не хотите жестко кодировать список частот, с которыми встречаются различные имена, в приложении. В таких случаях вам нужен способ убедиться, что список слишком длинный, при этом не тратясь на считывание полного списка. Решение состоит из нескольких шагов.

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

2. В обращении к базе данных запросите на одну строку больше, чем выбранная максимальная длина (501 строка для нашего примера).

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

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

5. Отсортируйте результаты, как необходимо, на уровне приложения, если результат не вызвал ошибку, перейдя за установленный порог (501 строка для нашего примера).

6. Отмените запрос и возвратите сообщение об ошибке с просьбой указать более селективный критерий поиска, если количество строк достигло максимального значения (501 строка для нашего примера).

На моем прежнем месте работы в качестве настройщика производительности, в TenFold Corporation, эта техника оказалась так полезна, что мы внедрили ее в платформу приложения EnterpriseTenFold, добавив возможность изменять максимальное количество строк.

Итак, предотвращайте объемные оперативные запросы при помощи трехстороннего подхода.

¦ Обучайте конечных пользователей, чтобы они указывали достаточно узкие критерии поиска, и не получали слишком много данных.

¦ Возвращайте сообщения об ошибках, когда конечные пользователи пытаются выполнить явно неселективные запросы, особенно слепые запросы, основанные на больших корневых детальных таблицах.
284

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

¦ Запускайте потенциально объемные запросы так, чтобы получать первые строки быстро, и возвращайте сообщение об ошибке, как только количество возвращенных строк перейдет выбранный порог.

Объемные пакетные отчеты

Медленные действия приложений так неприятны для пользователей, что они не остаются неисправленными. Испытавшие их на себе конечные пользователи либо меняют свое поведение, либо достаточно громко жалуются, чтобы проблема была вскоре решена. Пакетная загрузка может нести скрытую опасность, так как зачастую проблемы с пакетной производительностью остаются незамеченными, создавая огромную нагрузку и понижая пропускную способность системы, но никак не проявляя себя в явном виде. Когда общая загрузка слишком высока, замедляются все составляющие приложения, но пакетные процессы, потребляющие слишком много системных ресурсов, могут все также работать достаточно хорошо, чтобы оставаться незамеченными, особенно если это низкоприоритетные процессы, завершения которых никто не ждет с нетерпением. Периодические пакетные процессы с автоматическим расписанием особенно опасны. Они могут запускаться намного чаще, чем это необходимо, и никто этого не заметит. Может отпасть необходимость использовать их так же часто, как и раньше, или они могут стать вовсе ненужными, но все так же выполняться, незаметно ухудшая работу системы.
Предыдущая << 1 .. 133 134 135 136 137 138 < 139 > 140 141 142 143 144 145 .. 161 >> Следующая
Реклама
Авторские права © 2009 AdsNet. Все права защищены.
Rambler's Top100