Совет №27
Находимся в режиме off-line как можно меньше

Материал опубликован с разрешения компании Ralph Kimball Associates
Автор оригинала: Ральф Кимбалл (все статьи)
Перевод на русский язык: Константин Лисянский
Оригинальный документ располагается здесь.

Если вы обновляете ваше хранилище каждый день, у вас имеется характерная свалка, когда вы переводите вчерашние данные в off-line, а сегодняшние - в on-line. Во время этой свалки ваше хранилище данных, возможно, становится недоступным. Если все ваши пользователи находятся в одном часовом поясе, вы можете и не испытывать сильного давления до тех пор пока вы выполняете обновление между тремя и пятью часами утра. Но, что более вероятно, если ваши пользователи разбросаны по стране или по всему миру, вы хотите находиться в режиме off-line как можно меньше, поскольку в вашем случае для хранилища данных солнце никогда не садится. Так как же сократить время простоя до самого минимума?

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

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

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

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

Если ваша таблица фактов называется FACT, вам также понадобится не проиндексированная таблица LOADFACT. На самом деле, на всех последующих шагах мы говорим только о самой свежей секции, а не обо всей таблице фактов! Вот шаги, позволяющие сократить пребывание в режиме off-line. Мы идём в off-line на шаге 4 и возвращамся назад в on-line на шаге 7.

1. Загрузите ваши вчерашние данные в секцию LOADFACT. Выполните проверку качества данных.
2. После окончания загрузки сделайте копию LOADFACT и назовите её COPYLOADFACT.
3. Постройте индексы по таблице LOADFACT.
4. Переведите FACT в off-line (на самом деле, только наиболее свежую секцию).
5. Переименуйте наиболее свежую секцию FACT в SAVEFACT.
6. Переименуйте LOADFACT (секцию) в самую свежую секцию FACT.
7. Переведите FACT в on-line.
8. Теперь проведите чистку путём переименования COPYLOADFACT в новую LOADFACT. Вы можете продолжить загонять новые входящие данные в эту новую секцию LOADFACT.
9. Если всё в порядке, можно удалить SAVEFACT.

Таким образом, мы уменьшили интервал пребывания в состоянии off-line всего к двум оставшимся операциям в шагах 5 и 6. Почти наверняка, эти операции переименования будут быстрее, если физический размер наиболее свежей секции мал, насколько это возможно.

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

• ограничения на размер секции вашей СУБД
• необходимость загрузить старые, несвежие данные в вашу таблицу фактов, что сорвет предположение о «свежести»
• обработка соответствующих агрегированных таблиц фактов

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

Ralph Kimball (ralph@ralphkimball.com)

• Следующий совет
• Предыдущий совет
• Другие советы

По этой теме можно также почитать:

• Совет №31. Проектируем партицию реального времени
• Порядок разработки ETL-процессов

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

Если вы нашли в сети интересные ссылки на ресурсы по технологиям хранилищ данных, OLAP, CRM или data mining, и хотите поделиться ими с другими, присылайте их. Я с удовольствием размещу их на этом сайте.