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

ш Переформатирование данных. Формат поступающих данных может сильно отличаться от формата, используемого в базе данных хранилища. Например, если текстовые данные переносятся с мэйнфреймов, их нужно транслировать из кодировки EBCDIC в ASCII. Еще один распространенный источник расхождений - форматы дат и времени. Кроме этих очевидных отличий .могут быть и более серьезные: информашгя из одной таблицы OLTP-источника может разделяться на части, помещаемые в несколько таблиц хранилища, и наоборот, raiформация из нескольких таблиц источника может сливаться для помещения в одну таблицу хранилища.

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

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

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

Производительность запросов

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

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

Специализированные схемы индексации. Типичные аналитические запросы извлекают из хранилища некоторое подмножество данных, отбираемых по указанным

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

Технологии параллельной обработки. Запросы, связанные с деловым анализом, нередко разделяются на части, которые могут выполняться параллельно, что сокращает общее время выполнения запроса. Например, если требуется объединить четыре таблицы базы данных, можно воспользоваться преимуществами двухпроцессорной системы, объединяя две таблицы в одном процессе, а две другие - в другом. Затем результаты этих промежуточных операций объединяются в общий набор записей. Аналогичным образом может быть распределена между двумя процессорами и обработка данных одной таблицы: например, заказы за первое полугодие могут обрабатываться в одном процессе, а заказы за второе полугодие - в другом. Мультипроцессорные системы используются хранилищами данных не так, как в OLTP-системах. Оперативная обработка транзакций - это обычно множество одновременно выполняющихся небольших запросов, которые можно динамически распределять между процессорами, чтобы увеличить общую пропускную способность системы, в то время как бизнес-анализ - это последовательно поступающие запросы на обработку огромного количества данных, и выполнение каждого такого запроса может быть ускорено за счет распределения между процессорами его составляющих.

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

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

Резюме

Хранилища данных представляют собой одну из самых быстрорастущих частей рынка реляционных СУБД, и к ним предъявляется ряд специальных требований:

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

для наполнения хранилищ требуются специализированные утилиты, обеспечивающие высокую скорость зафузки данных;

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

м при работе с хранилищами часто используются расщирения SQL, позволяющие анализировать скрытые тенденции роста, фуппировать данные по диапазонам, сравнивать данные за разные периоды времени и многое другое;

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