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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Запросы, возвращающие небольшое количество строк, которые выполняются медленно даже после их настройки, могут иметь важные фильтры, все из которых невозможно использовать до того, как по мере выполнения запроса будет достигнута, по меньшей мере, одна большая таблица. Возьмем, например, рис. 10.1. Если в корневой детальной таблице М находится 50 ООО ООО строк, то детальные коэффициенты соединения показывают, что в А1 и А2 по 10 ООО ООО строк, а в В1 и В2 по 100 ООО строк. Надежные и основанные на индексном доступе планы выполнения с порядком соединения (В1. А1. М. А2. В2) и (В2. А2. М. А1. В1) симметричны и одинаково привлекательны. Для определенности будем рассматривать только первый порядок соединения. В этом плане мы получаем 100 строк из 81,10 ООО строк из А1 и 50 ООО строк из М, А2 и В2 перед тем, как отбросить все, кроме 50 строк, удовлетворяющих условию фильтрации для В2.

5/\5

А1 А2

В1 0001 82 0.001

Рис. 10.1. Медленный запрос, возвращающий несколько строк

Если вы ослабите требование надежности, то сможете предварительно считать 100 строк, удовлетворяющих фильтру для 62 и соединить их с ранее считанными строками путем хэширования. Можно даже предварительно соединить эти 100 строк с А2 при помощи вложенных циклов и выполнить соединение хэшированием между строками, ползенными при помощи метода вложенных циклов из (В1. А1. М) и строками, считанными методом вложенных циклов, которые соединяют комбинацию (82. А2). Это позволит сократить количество строк, которое нужно считать из А2, до 10 ООО, и сохранить количество строк из 82 равным 100. Однако ни одна из этих стратегий не устраняет необходимости считать 50 ООО строк из самой большой и хуже всех кэшированной таблицы М, и это определенно потребует больше времени, чем вам бы хотелось для запроса, возвращающего всего 50 строк.

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

Оптимизация запросов

с распределенными фильтрами

Чтобы оптимально использовать распределенные фильтры, вам необходимо каким-то образом сблизить их на диаграмме запроса, лучше всего - в одной таблице. Еще раз обратимся к рис. 10.1. Предположим, что оба фильтра для 81 и 82 представляют собой условие равенства для некоторого столбца таблицы, соответствующей данному фильтру. Нормализовангштй дизайн базы данных предполагает размещение фильтрованного столбца из 81 там, где он есть, так как он кодирует свойство, которое вам нужно указать только один раз для каждой сущности 81. Более того, это свойство, о котором вы не можете узнать исходя из сущностей любой главной таблицы, которая соединяется методом один ко многим с В1. Если вы поместите этот столбец в А1, то это уже будет денормализация, определенная как свойство, о котором можно узнать исходя из соответствующей главной сущности А1, хранящейся в В1. Такая денормализация потребует, чтобы в таблице А1 хранились избыточные данные, так как все 100 (в среднем) сущностей А1, которые соединяются с любой данной строкой 81, должны иметь одинаковое значение в этом наследованном столбце. Однако в принципе все свойства сущностей главной таблицы являются наследовагшыми свойствами детальных сущностей, соответствующих этим сущностям главной таблицы.

ПРИМЕЧАНИЕ

Форма денормализации, которую я описываю, - не ед1[нственная существующая форма денормализации. Написаны целые книги, посвященные нормализации баз данных, но эта простейшая форма денормализации - единственная, подходящая для нашего обсуждения.