К тактическим можно отнести те подходы, которые как бы вносят "последний штрих" в изменения, произведенные с помощью стратегических решений. Тактические подходы экономят ресурсы. Использование только этих подходов будет ошибкой; наиболее ощутимый результат можно получить, используя тактические приемы в дополнение к стратегическим.
Первый тактический подход - индексирование данных (см. рис. 1). Существует ряд нестандартных решений (вместо того, чтобы просто увеличивать число индексов):
Рис. 1. Индексирование данных повышает эффективность; существует целый ряд подходов к добавлению индексов в Хранилище данных
Использование индексов - это просто еще один способ, с помощью которого можно хранить данные для оптимального использования, а не оптимального хранения.
Конечно, если вы хотите наиболее эффективно использовать индексы, вам необходимо заранее знать, по какой схеме используются данные. Как уже говорилось, "фермеры" обладают таким знанием, "исследователи" - нет.Другой метод - создание предварительных связей. В этом случае системный администратор отводит значительную часть ресурсов для соединения во время процесса загрузки, а не в процессе осуществления рабочего доступа к данным и анализа. Однако создание предварительных связей вовсе не приводит к снижению загруженности системных ресурсов. Вместо этого происходит перераспределение времени их использования. Предварительные связи создаются во нерабочие часы, то есть высвобождают ресурсы для анализа, проводимого в "часы пик". Примеры таких связей показаны на рис. 2. Метод предварительного создания связей дает больший эффект том в случае, если данные обрабатываются "фермерами", что вполне логично.
Рис. 2. Создание предварительных связей при наличии образца
совместного доступа к одинаковым данным
Добиться значительной экономии ресурсов можно путем создания физически смежных массивов данных (см. рис. 3).
Рис. 3. Использование массивов данных для физического объединения связанных
между собой записей с целью минимизации величины ввода/вывода (I/O),
необходимой для доступа к данным и их анализа
Например, если аналитик желает просмотреть данные об операциях по счету за год, ему потребуются данные за январь, февраль, март и т.д. Если эти данные были бы записаны в один массив, доступ к ним был бы более легким, чем в случае, если данные по каждому месяцу были бы бессистемно разбросаны по всей базе данных.
Данный прием подходит как для "фермеров", так и для "исследователей". Первые регулярно используют преимущества смежных массивов, вторые - от случая к случаю.Следующая техника - использование системных особенностей, таких, как разбиение на кластеры. При этом различные единицы информации (например, строки данных) физически размещаются в один и тот же блок, как и другие связанные между собой элементы. Такой способ размещения данных может быть использован для оптимального доступа к данным. Возможности кластеризации целиком зависят от СУБД: некоторые СУБД обладают возможности кластеризации, другие - практически нет. Результат, полученный посредством применения кластеризации, показан на рис. 4. Этот прием хорошо подходит главным образом для "фермеров", но в некоторых случаях - и для "исследователей".
Рис. 4. Кластеризация данных для оптимизации доступа
Когда данные могут быть физически сжаты, возникает возможность загрузки большего количества данных в один блок. Таким образом можно оптимизировать количество информации, которая прорабатывается в процессе поиска. Иными словами, операция ввода/вывода позволяет "захватить" больше данных за 1 раз, если информация находится в сжатом виде. Процесс сжатия проиллюстрирован на рис. 5.
Рис. 5. Сжатие данных оптимизирует доступ таким образом, что за одну
операцию ввода/вывода (I/O) происходит получение большего объема
данных
Метод сжатия особенно хорошо подходит для работы в среде Хранилищ данных, поскольку они не поддерживают обновление информации (т.е. будучи единожды записанными, данные уже не изменяются). Это особенно важно, так как процесс обновления сжатой информации чрезвычайно сложен и дорог.
Для эффективного использования сжатия данных необходимо знать, как они используются. Именно по этой причине данный метод больше подходит для "фермеров".Данная методика отличается от кластеризации лишь тем, что в первом случае данные распределяются системным администратором или программистом, а во втором - самой СУБД. Типичная предварительно форматированная таблица приведена на рис. 6. Эффективность применения данной методики зависит от способности администратора или программиста контролировать перераспределение данных. Поскольку программист получает возможность повлиять на размещение информации лишь в процессе первоначальной загрузки, в дальнейшем сама СУБД снижает эффективность его действий.
Рис. 6. Физическая оптимизация размещения данных, осуществляемая программистом
Как и в случае с кластеризацией, программист должен иметь предварительное представление о том, как будут использоваться данные. К сожаление, подобный подход полезен лишь в случае с "фермерами".
В результате объединения таблиц может потребоваться меньше операций
ввода/вывода (I/O) для доступа к данным и их анализа (см. рис. 7).
Рис. 7. Слияние таблиц
Для эффективного объединения таблиц необходимо сформировать общую ключевую структуру. Не имеет смысла объединять таблицы, которые никогда не используются вместе. Поэтому требуется специальный образец, или шаблон доступа и использования, и поэтому данный метод более подходит для "фермеров", а не для "исследователей".
Когда данные находятся в нормализованном виде, избыточность отсутствует. Это состояние оптимально для целей хранения и обновления данных. Однако иногда имеет смысл оптимизировать доступ и использование информации вместо ее обновления. В этом случае можно создать некоторые элементы избыточности на выборочной основе. Избыточность может быть полезна, когда известно, что два элемента информации должны быть использованы вместе, и не существуют по отдельности. Конечно, создавать избыточность нужно в меру (хотя избыточность может существенно повысить производительность доступа). Различие между использованием данных с нулевой избыточность и выборочно избыточной информации показано на рис. 8.
Рис. 8. Выборочная избыточность данных
Как и большинство предыдущих, данная техника рассчитана прежде всего на "фермеров", поскольку опять же требуется знание об наиболее вероятном использовании информации.
Скользящие таблицы итогов содержат свежие детализированные данные. По мере устаревания, уровень агрегирования данных увеличивается (см. рис. 9). Например, данные за последний час могут храниться вместе со всеми операциями за текущий день. Данные за день хранятся вместе с данными за другие дни в течение всей недели. Наконец, данные за месяц хранятся вместе с данными за последний год и т.д.
Рис. 9. Скользящие таблицы агрегатов
Данный метод подходит как для "фермеров", так и для "исследователей".
Существует еще один уровень, на котором можно добиться повышения производительности DSS-среды. Если на стратегическом уровне можно добиться роста эффективности на несколько порядков, на тактическом - до одного порядка, то на оперативном уровне можно достичь примерно 50%-го роста. Рассмотрим некоторые наиболее распространенные оперативные методы повышения эффективности.
Данный подход заключается в том, чтобы производить вставку данных и их обновление по ночам или в другое время, когда база данных не используется. Простой пример приведен на рис. 10.
Рис. 10. Вставка данных в нерабочее время
Значительный объем ресурсов можно сэкономить, возложив обязанности по загрузке базы на продавца программного продукта или третью сторону. Во многих случаях наиболее дорогой и продолжительный способ - обращаться к базе данных из программы приложения. Более сложный метод - создать логический файл загрузки из приложения, а затем запустить этот загрузочный файл с помощью утилиты, оптимизированной для загрузки базы данных. Пример работы подобной схемы показан на рис. 11.
Рис. 11. Выполнение процесса первоначальной загрузки при помощи
утилит третьей стороны
Если отказаться от создания индексов в момент загрузки базы данных, можно также сэкономить значительный объем системных ресурсов. При этом просто происходит загрузка записей в Хранилище. После этого отдельно происходит создание и обновление индексов.
Удаление ненужной информации может положительно сказаться на эффективность осуществления всех других процессов (см. рис. 12).
Рис. 12. Регулярная очистка данных Хранилища
Чтобы можно было очистить Хранилище данных от ненужной информации, необходимо осуществлять текущий контроль за использованием данных и изменением объема информации. При этом должны создаваться отчеты по каждому из этих показателей, а также в разрезе всех отделов и департаментов. Схема регулярного контроля за Хранилищем данных отражен на рис. 13.
Рис. 13. Текущий контроль за Хранилищем данных
Как нетрудно догадаться, достаточно важным моментом является разделение "фермеров" и "исследователей" (см. рис. 14). Первые могут использовать DSS-Хранилище во время обычного рабочего дня. Вторые должны дожидаться более низкой активности системы ближе к вечеру и лишь тогда приступить к своей деятельности. Конечно, данный подход основан на определенном допущении, что "исследователи" только того и ждут, чтобы им дали поработать вечером. Очевидно, данное предположение может далеко не всегда оказаться верным.
Рис. 14. Разделение на "фермеров" и "исследователей"
Можно добиться незначительного улучшения производительности путем комбинирования нескольких запросов в один, и лишь после этого направления его в Хранилище. Вместо того, чтобы выполнять множество запросов к одним и тем же данным, достаточно составить один запрос таблице данных Хранилища - это позволит сэкономить часть ресурсов (см. рис. 15).
Рис. 15. Комбинированный доступ к составным запросам
Еще одной полезной методикой управления использованием ресурсами DSS-среды может оказаться так называемая система chargeback. Эта система предназначена для того, чтобы сигнализировать организации о том, что используемые Хранилищем ресурсы в настоящий момент заняты. При правильном использовании данная система может помочь более "мудро" использовать имеющиеся ресурсы. Эффект использования системы chargeback приведен на рис. 16.
Рис. 16. Система chargeback позволяет DSS-аналитику быть в курсе того,
какие ресурсы в данный момент используются
Регуляторы ресурсов предназначены для того, чтобы автоматически ограничивать объем задействованных для обработки запроса системных ресурсов. Как правило, данный инструмент является наименее действенным для оптимизации производительности. Кроме того, существует целый ряд проблем, связанных с регуляторами ресурсов:
Гораздо более эффективным способом контроля использования ресурсов является разделение работы "фермеров" и "исследователей". Иными словами, рассмотренный подход не является эффективным.
Под кэшированием подразумевается хранение данных в памяти, чтобы при повторном обращении к ним сэкономить определенной количество процессов ввода/вывода, требуемых для осуществления данной операции. К сожалению, влияние кэширования на производительность незначительно. Кроме того, существует две основные причины, почему кэширование в среде Хранилищ данных менее популярно и действенно, нежели в других средах: