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

В предыдущей статье были рассмотрены административные и два аппаратных способа повышения производительности хранилища данных. Сегодня рассмотрим другие способы.

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

Балансировка системы. Строго говоря, нельзя сказать, что это только аппаратный способ. И этот способ сильно перекликается с предыдущим (добавлением “железа”). Просто здесь хочется сделать упор на то, что добавлять нужно именно того, что требуется, чтобы сделать систему сбалансированной путём расширения узкого места. Ну, например, в случае, если высобираете массивно-параллельную систему (MPP) сами, то может получиться, что проблема с производительностью может возникать из-за того, что не хватает пропускной способности сети, и решить её можно добавлением дополнительных сетевых карт в узлы системы. Ещё одним примером может стать перераспределение дисков между пространством пользовательских данных, пространством для индексов и пространством для временного хранения промежуточных результатов запросов.

Для повышения производительности дисковой подсистемы можно использовать RAID-массив (RAID (definition)) в режиме RAID 1. В этом случае операции чтения будут выполняться быстрее.

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

Аппаратное кэширование (cache) (например, кэш на уровне контроллера дисков). Может повысить скорость выполнения тактических запросов (tactical query) к СУБД. Для сложных запросов, требующих сканирования больших объёмов данных менее действенно, поскольку количество попаданий в кэш стремится к нулю.

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

Программные способы

Здесь довольно большое разнообразие. Начнём, пожалуй с того, что можно поменять программную платформу, например на специализированную. Это перекликается с темой смены платформы в аппаратных способах. Но, замена программной платформы может быть произведена и без замены аппаратной. Например, если вы меняете СУБД хранилища, которая не предназначена для этого, на специализированную СУБД, например, на колоночную (columnar database), или (весьма экзотический случай для России) меняете одну СУБД архитектуры MPP, работающую на общедоступных компонентах, на другую.

Специализированные СУБД используют различные методы для повышения производительности. Среди них (только обозначу, не буду обсуждать детали, это делается во многих статьях нашего сайта):

  • хранение данных по столбцам (columnar database)
  • параллелизм (например, архитектура MPP)
  • обработка данных в памяти (IMDB)
  • сжатие данных (data compression)
  • последовательное хранение данных для более быстрого выполнения операций сканирования таблиц (full table scan)
  • продвинутые методы оптимизации запросов (query optimization)
  • специальные методы индексации (indexing)
  • избыточное хранение (data redundancy) и предварительная агрегация данных (data aggregation)

Кроме СУБД хранилища можно можно поменять любую программную компоненту (ETL-сервер, OLAP-сервер, инструмент data mining и т.д).

К программным методам, естественно, относится и изменение конфигурационных параметров и настроек. Некоторые СУБД имеют сотни или даже тысячи различных параметров, изменяя которые можно добиваться улучшений в производительности. Для примера приведу возможность синхронного сканирования одной и той же таблицы для выполнения нескольких различных запросов (syncronized table scan). Другой параметр - размер блока данных таблицы или индекса. Как правило, для хранилищ данных выбирают бальшие размеры блока, поскольку характер запросов таков, что приходится делать большое количество операций сканирования таблиц (full table scan) и в случае больших блоков она будет выполняться быстрее. Можно менять параметры утилит, которые загружают данные в хранилище чтобы добиться ускорения загруки (например, если загрузка происходит в режиме, близком к реальному времени, то можно изменять такие параметры, как размеры пакетов, частота их направления в СУБД, количество одновременно открытых сессий программы-загрузчика и т.д.). Нельзя не вспомнить и о хинтах оптимизатору - в случае, если оптимизатор не очень зрелый и генерирует неэффективные планы запросов, ему можно помочь. Кстати, некоторые инструменты для репортинга позволяют генерировать хинты оптимизатору автоматически.

На уровне СУБД можно включить сжатие данных. В некоторых СУБД компрессия работает автоматически, в других - придётся включать вручную на уровне отдельных столбцов. Поставщики предлагают специальные утилиты, которые помогут оценить, какие столбцы стоит сжимать, а какие - нет.

Программное кэширование на уровне OLAP-сервера или сервера отчётности может помочь повысить скорость выполнения отчётов за счёт их кэширования.

Проанализировав код SQL, например, который выполняет процедуры трансформации данных (data transformation) или код аналитических приложений (analytical application), его можно переписать, оптимизировав для повышения быстродействия.

Добавление (активация) агрегатного навигатора (aggregate navigator) совместно с созданием агрегатов позволит повысить выполнение запросов, на которые можно ответить с помощью сводных (summarized data) данных. Агрегатные навигаторы встроены в некоторые инструменты репортинга.

Динамическая виртуализация (virtualization) - динамическое добавление и удаление единиц параллелизма в виде виртуальных машин для борьбы с пиковыми нагрузками, снижающими производительность. Актуально, если СУБД позволяет это делать. С СУБД архитектуры MPP это сложнее, поскольку в MPP-системах каждая единица параллелизма отвечает за обработку своего фрагмента данных, и при добавлении или удалении единиц параллелизма необходимо перераспределять данные между ними. В архитектуре shared disk виртуализацию применить легче.

Оптимизация процедур выгрузки данных (data extraction) за счёт изменения способов захвата изменившихся данных (CDC) может сократить время, необходимое для полного цикла выгрузки и загрузки данных, что может сократить время, когда параллельно с загрузкой данных пользователи выполняют к нему запросы. Что, опять-таки, должно положительно отразиться на производительности.

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

На сегодня пока всё. Далее рассмотрим архитектурные способы, проектирование и администрирование.

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


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

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