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

 

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

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

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


¦ Пользователя интересует поднабор данных.

Просто отбросьте лишнюю часть набора данных.

Решения

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

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

¦ Исключите из данных отчета ненужные блоки данных. Удостоверьтесь, что эти ненужные данные не только не выводятся в отчете, но и не запрашиваются из базы данных. Есть несколько приемлемых решений.

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

? Выдавайте в отчете только исключения, удаляя ненужные строки.

? Замените отчет с первыми несколькими строками на отсортированный список исключений.

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

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

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

¦ Распараллельте обработку отчетов с высоким приоритетом, которые нужно получить срочно.

¦ Обеспечьте последовательную обработку отчетов с низким приоритетом и передвиньте обработку на свободные часы. Также стоит уменьшить частоту выдачи отчетов. Нередко самая правильная частота выдачи низкоприоритетных отчетов — никогда.

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

Агрегационные данные многих детальных записей

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

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

291

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

¦ Когда необходимо, заранее агрегируйте данные на стороне сервера, и выдавайте отчет об итогах, не затрагивая подробности.

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

Промежуточные процессы обрабатывают слишком много строк

Предыдущая << 1 .. 137 138 139 140 141 142 < 143 > 144 145 146 147 148 149 .. 161 >> Следующая
Реклама
Авторские права © 2009 AdsNet. Все права защищены.
Rambler's Top100