Журнал ВРМ World

30 марта 2000

Производительность систем Хранилищ данных (часть 2)

Тактические подходы к повышению производительности

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

Индексирование данных

Первый тактический подход - индексирование данных (см. рис. 1). Существует ряд нестандартных решений (вместо того, чтобы просто увеличивать число индексов):

• Создание "перевернутых" списков (inverted lists);
• Создание "перевернутых" списков, содержащих неиндексированные данные;
• Иерархические индексы;
• Создание небольшого количества индексов для данных, лишь некоторые экземпляры которых представляют интерес и т.д.

Рис. 1. Индексирование данных повышает эффективность; существует целый ряд подходов к добавлению индексов в Хранилище данных

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

Предварительные связи

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

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

Смежные массивы (physically juxtaposed arrays)

Добиться значительной экономии ресурсов можно путем создания физически смежных массивов данных (см. рис. 3).

Рис. 3. Использование массивов данных для физического объединения связанных между собой записей с целью минимизации величины ввода/вывода (I/O), необходимой для доступа к данным и их анализа

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

Кластеризация (выделение кластеров)

Следующая техника - использование системных особенностей, таких, как разбиение на кластеры. При этом различные единицы информации (например, строки данных) физически размещаются в один и тот же блок, как и другие связанные между собой элементы. Такой способ размещения данных может быть использован для оптимального доступа к данным. Возможности кластеризации целиком зависят от СУБД: некоторые СУБД обладают возможности кластеризации, другие - практически нет. Результат, полученный посредством применения кластеризации, показан на рис. 4. Этот прием хорошо подходит главным образом для "фермеров", но в некоторых случаях - и для "исследователей".

Рис. 4. Кластеризация данных для оптимизации доступа

Сжатие информации

Когда данные могут быть физически сжаты, возникает возможность загрузки большего количества данных в один блок. Таким образом можно оптимизировать количество информации, которая прорабатывается в процессе поиска. Иными словами, операция ввода/вывода позволяет "захватить" больше данных за 1 раз, если информация находится в сжатом виде. Процесс сжатия проиллюстрирован на рис. 5.

Рис. 5. Сжатие данных оптимизирует доступ таким образом, что за одну операцию ввода/вывода (I/O) происходит получение большего объема данных

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

Оптимизация физического размещения данных

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

Рис. 6. Физическая оптимизация размещения данных, осуществляемая программистом

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

Слияние таблиц

В результате объединения таблиц может потребоваться меньше операций ввода/вывода (I/O) для доступа к данным и их анализа (см. рис. 7).

Рис. 7. Слияние таблиц

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

Выборочная избыточность данных (selective redundancy of data)

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

Рис. 8. Выборочная избыточность данных

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

Скользящие таблицы итогов (rolling summary data)

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

Рис. 9. Скользящие таблицы агрегатов

Данный метод подходит как для "фермеров", так и для "исследователей".

Оперативная оптимизация производительности

Существует еще один уровень, на котором можно добиться повышения производительности DSS-среды. Если на стратегическом уровне можно добиться роста эффективности на несколько порядков, на тактическом - до одного порядка, то на оперативном уровне можно достичь примерно 50%-го роста. Рассмотрим некоторые наиболее распространенные оперативные методы повышения эффективности.

Вставка данных в нерабочее время

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

Рис. 10. Вставка данных в нерабочее время

Процесс загрузки

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

Рис. 11. Выполнение процесса первоначальной загрузки при помощи утилит третьей стороны

Отказ от загрузки индексов

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

Очистка данных хранилища

Удаление ненужной информации может положительно сказаться на эффективность осуществления всех других процессов (см. рис. 12).

Рис. 12. Регулярная очистка данных Хранилища

Текущий контроль Хранилища данных

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

Рис. 13. Текущий контроль за Хранилищем данных

Разделение "фермеров" и "исследователей"

Как нетрудно догадаться, достаточно важным моментом является разделение "фермеров" и "исследователей" (см. рис. 14). Первые могут использовать DSS-Хранилище во время обычного рабочего дня. Вторые должны дожидаться более низкой активности системы ближе к вечеру и лишь тогда приступить к своей деятельности. Конечно, данный подход основан на определенном допущении, что "исследователи" только того и ждут, чтобы им дали поработать вечером. Очевидно, данное предположение может далеко не всегда оказаться верным.

Рис. 14. Разделение на "фермеров" и "исследователей"

Комбинированные запросы

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

Рис. 15. Комбинированный доступ к составным запросам

Система chargeback

Еще одной полезной методикой управления использованием ресурсами DSS-среды может оказаться так называемая система chargeback. Эта система предназначена для того, чтобы сигнализировать организации о том, что используемые Хранилищем ресурсы в настоящий момент заняты. При правильном использовании данная система может помочь более "мудро" использовать имеющиеся ресурсы. Эффект использования системы chargeback приведен на рис. 16.

Рис. 16. Система chargeback позволяет DSS-аналитику быть в курсе того, какие ресурсы в данный момент используются

Регуляторы ресурсов

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

• установка лимитов использования ресурсов всегда чревато тем, что почти завершившаяся обработка запроса будет прервана регулятором;
• сохранение промежуточных результатов обработки представляется затруднительным. Но даже если результаты будут сохранены, а запрос начнет выполняться заново, итог может быть недостаточно точным.

Гораздо более эффективным способом контроля использования ресурсов является разделение работы "фермеров" и "исследователей". Иными словами, рассмотренный подход не является эффективным.

Кэширование данных

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

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