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

 

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

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

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

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

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

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

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

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

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

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

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

Кроме этих уже знакомых вам методов есть и еще несколько способов, хорошо

работающих именно с промежуточным программным обеспечением.

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

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

¦ Удалите интерфейс.

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

¦ Передвиньте разделительную линию между приложениями.

Например, вы работаете с двумя комбинированными приложениями, одно из которых ответственно за поступление заказов (Order Entry), а другое за выполнение заказов (Order Fulfillment) и счета к получению (Accounts Receivable). Интерфейс между Order Entry и Order Fulfillment, вероятно, будет передавать практически совпадающие данные. Если вы реорганизуете системы, чтобы скомбинировать Order Entry и Order Fulfillment, то получите намного более тонкий интерфейс с перемещением меньших объемов данных в Accounts Receivable.

¦ Сделайте интерфейс быстрее.

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

293

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

Настроенные запросы, которые медленно возвращают несколько строк

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

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

Запросы, возвращающие небольшое количество строк, которые выполняются медленно даже после их настройки, могут иметь важные фильтры, все из которых невозможно использовать до того, как по мере выполнения запроса будет достигнута, по меньшей мере, одна большая таблица. Возьмем, например, рис. 10.1. Если в корневой детальной таблице И находится 50 ООО ООО строк, то детальные коэффициенты соединения показывают, что в Al и А2 по 10 ООО ООО строк, а в BI и В2 по 100 000 строк. Надежные и основанные на индексном доступе планы выполнения с порядком соединения (BI. Al. М. А2. В2) и (В2, А2. М, Al. BI) симметричны и одинаково привлекательны. Для определенности будем рассматривать только первый порядок соединения. В этом плане мы получаем 100 строк из BI, 10 000 строк из Al и 50 000 строк из М, А2 и В2 перед тем, как отбросить все, кроме 50 строк, удовлетворяющих условию фильтрации для В2.
Предыдущая << 1 .. 138 139 140 141 142 143 < 144 > 145 146 147 148 149 150 .. 161 >> Следующая
Реклама
Авторские права © 2009 AdsNet. Все права защищены.
Rambler's Top100