Учебники

Хранилище данных — стратегия разделения

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

Почему необходимо разделить?

Разделение важно по следующим причинам —

  • Для легкого управления,
  • Чтобы помочь резервному копированию / восстановлению,
  • Для повышения производительности.

Для легкого управления

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

Помочь Резервному копированию / Восстановлению

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

Примечание — Для того, чтобы сократить размер резервной копии, все , кроме текущего раздела разделы могут быть помечены как только для чтения. Затем мы можем поместить эти разделы в состояние, в котором они не могут быть изменены. Тогда они могут быть сохранены. Это означает, что для резервного копирования требуется только текущий раздел.

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

Разделив таблицу фактов на наборы данных, можно улучшить процедуры запроса. Повышена производительность запроса, поскольку теперь запрос сканирует только те релевантные разделы. Не нужно сканировать все данные.

Горизонтальное разбиение

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

Разбиение по времени на равные отрезки

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

Разделение по времени на сегменты разных размеров

Этот тип раздела выполняется там, где к устаревшим данным обращаются редко. Он реализован в виде набора небольших разделов для относительно текущих данных, большего раздела для неактивных данных.

Разбиение по времени на сегменты разных размеров

Указывает на заметку

  • Подробная информация остается доступной онлайн.

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

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

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

Подробная информация остается доступной онлайн.

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

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

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

Перегородка в другом измерении

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

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

Указывает на заметку

  • Запрос не должен сканировать нерелевантные данные, что ускоряет процесс запроса.

  • Этот метод не подходит, если размеры в будущем вряд ли изменятся. Таким образом, стоит определить, что измерение не изменится в будущем.

  • Если измерение изменится, тогда всю таблицу фактов придется перераспределить.

Запрос не должен сканировать нерелевантные данные, что ускоряет процесс запроса.

Этот метод не подходит, если размеры в будущем вряд ли изменятся. Таким образом, стоит определить, что измерение не изменится в будущем.

Если измерение изменится, тогда всю таблицу фактов придется перераспределить.

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

Разделение по размеру таблицы

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

Указывает на заметку

  • Это разделение сложно управлять.

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

Это разделение сложно управлять.

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

Размеры разделов

Если измерение содержит большое количество записей, необходимо разделить измерения. Здесь мы должны проверить размер измерения.

Рассмотрим большой дизайн, который меняется со временем. Если нам нужно сохранить все варианты, чтобы применить сравнения, это измерение может быть очень большим. Это определенно повлияет на время отклика.

Круглые Робиновые Перегородки

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

Этот метод позволяет легко автоматизировать средства управления таблицами в хранилище данных.

Вертикальная перегородка

Вертикальное разбиение, разбивает данные по вертикали. На следующих рисунках показано, как выполняется вертикальное разбиение.

Вертикальное разделение

Вертикальное разбиение может быть выполнено следующими двумя способами:

  • нормализация
  • Разделение строк

нормализация

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

Таблица до нормализации

Код товара Кол-во Значение sales_date store_id Название магазина Место нахождения Область, край
30 5 3,67 3-августа-13 16 солнечно Бангалор S
35 4 5,33 3-Sep-13 16 солнечно Бангалор S
40 5 2,50 3-Sep-13 64 Сан — Mumbai W
45 7 5,66 3-Sep-13 16 солнечно Бангалор S

Таблица после нормализации

store_id Название магазина Место нахождения Область, край
16 солнечно Бангалор W
64 Сан — Mumbai S
Код товара Количество Значение sales_date store_id
30 5 3,67 3-августа-13 16
35 4 5,33 3-Sep-13 16
40 5 2,50 3-Sep-13 64
45 7 5,66 3-Sep-13 16

Разделение строк

Разделение строк приводит к тому, что между разделами остается однозначная карта. Мотивом разделения строк является ускорение доступа к большому столу за счет уменьшения его размера.

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

Определить ключ к разделу

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

Account_Txn_Table
transaction_id
account_id
transaction_type
value
transaction_date
region
branch_name

Мы можем выбрать раздел на любой ключ. Два возможных ключа могут быть

  • область, край
  • Дата сделки

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

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

Следовательно, стоит определить правильный ключ разделения.