Автор: Константин Лисянский

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

Готовых советов о том, что делать, в этой статье не будет, я просто попытался вспомнить обо всех известных мне способах. Замечу также, что речь пойдёт и о способах ускорения, изначально заложенных в соответствующие программные продукты. Таким образом, я уделю немного внимания “встроенным” в разные СУБД средствам ускорения.

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

Итак, я бы разделил способы ускорения на следующие:

  • аппаратные (архитектура, специализация)
  • программные (архитектура, настройки)
  • общая архитектура
  • проектирование
  • администрирование
  • административные

А, вот, где можно ускорять:

  • выгрузка данных из источников (data extraction)
  • преобразование данных (data transformation)
  • загрузка данных в хранилище (data loading)
  • расчёт агрегатов (data aggregation)
  • построение индексов (indexing)
  • пакетные расчёты (batch calculation)
  • выгрузки из хранилища (data export)
  • анализ данных по заранее подготовленным структурам данных с использованием инструментов BI
  • запросы ad hoc (ad hoc query)
  • интеллектуальный анализ данных (data mining)

Что касается самой СУБД хранилища данных, то имеет смысл рассматривать её оптимизацию в рамках различных видов нагрузки на неё. В идеале, хочется разогнать все виды запросов, образующих смешанную нагрузку (mixed workload).

Далее по тексту способы ускорения я буду обозначать жирным шрифтом. Хотелось бы начать с конца списка способов ускорения.

Административные способы

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

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

Отделение сред разработки (development system) и тестирования (test system) от среды промышленной эксплуатации (production system). Это очевидный способ, но, всё равно, мне показалось, что о нём нужно написать.

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

Своевременное информирование пользователей о более эффективных способах решения их задач. Например, можно проинформировать пользователей о том, что вместо детальных данных для выполнения их запросов можно использовать сводные данные (summarized data), после того, как эти сводные данные стали доступны.

Аппаратные способы повышения производительности

К данным способам стоит причислить использование специализированного оборудования. Речь, в основном, идёт об использовании комплексов для хранилищ данных (data warehouse appliance), использующих аппаратные ускорители, например программируемые матрицы, как в продукте компании Netezza. Доступен этот, способ, естественно, при приобретении соответствующей платформы.

Добавление “железа”. Это из серии того, что мы можем контролировать. Как правило, речь идёт о добавлении (или замене на более скоростные) компонентов аппаратного обеспечения - процессоров, узлов, оперативной памяти, сетевых устройств, дисков. В большинстве случаев, такой способ будет гарантированно работать. Однако придётся потратится на приобретение дополнительных аппаратных средств.

Продолжение здесь…


Для удобства отслеживания новых публикаций рекомендуем подписаться на рассылку или на канал RSS.

Читайте также: