OpenEdge 11.4: как выбрать таблицу для Table Partitioning?

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

Этой статьёй я начинаю рассказывать о, наверное, самой долгожданной функции в OpenEdge 11.4 – Table Partitioning.

Ну что ж, устраивайтесь так, чтобы было удобнее читать. Предмет достаточно серьезный, поэтому сначала будет много букв, и только потом практические занятия ;-)».

Валерий Башкатов

 

Вы когда-нибудь задавали себе следующие вопросы?

• Поможет ли табличное секционирование в улучшении управляемости и повышении производительности моих приложений?
• У меня несколько тысяч таблиц в базе данных. Какие из них наилучшим образом подходят для табличного секционирования?
• Как выбрать столбцы и тип партиции при секционировании таблицы?

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

---

Основными причинами реализации секционирования таблиц (Table Partitioning) конечно же, является повышение их управляемости, производительности и доступности благодаря расширению параллелизма и возможностей обслуживания. Есть несколько моментов, которые следует учитывать при идентификации таблицы в качестве кандидата на секционирование, и здесь очень важно сразу сформировать правильную архитектуру. Стратегия миграции на табличное секционирование в OpenEdge позволяет применять табличное секционирование к существующим таблицам без необходимости перемещения данных. Тем не менее, для изменения схемы секционирования секционированной таблицы потребуется выполнить перезагрузку данных (Dump & Load).

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

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

Можно ли логически сгруппировать данные в таблице?

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

Есть ли в данных историческая составляющая?

Иными словами, становятся ли данные со временем менее востребованными в операционной деятельности вашего приложения? Если так, то такая таблица хороший кандидат для секционирования, так как благодаря секционированию исторические данные могут быть помечены «только для чтения», стать легко удаляемыми, архивируемыми или перемещаемыми в другую систему хранения. Исторические данные могут быть перемещены в менее дорогие системы хранения. Кроме того, исторические данные могут стареть вместе с существующими устройствами хранения, на которых они размещены, в то время как новые могут быть легко размещены на новых устройствах хранения. В любом случае, секционирование позволит контролировать размещение каждой группы данных (партиции).

Является ли стоимость обслуживания таблицы, например, из-за долгого времени простоя, слишком высокой?

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

Есть ли в данных организационный аспект?

Например, это данные с разбивкой по регионам или какие-то другие относительно статичные группы?

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

Упорядочены ли данные: имеют числовой порядок или временную метку, подразумевающие возможность логической группировки?

Например, можно ли рассматривать данные, как организованные на квартальной или ежегодной основе?

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

Хотите выполнять запросы к логически сгруппированным данным без использования индекса?

Если так, то такая таблица – это хороший кандидат для секционирования. Когда таблица не секционирована, при сканировании таблицы (table scan) необходимо прочитать всю таблицу чтобы получить требуемые данные, так как не используется никакой индекс для ограничения возвращаемых данных. Тем не менее, в секционированной таблице сканирование секций и возвращаемые данные ограничиваются одной или несколькими секциями в зависимости от условий запроса.

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

Запросы приложения обычно используют столбцы из состава секций?

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

В таблице имеется более одного столбца, которые можно использовать для уникальной идентификации группы данных?

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

Значение столбцов, описывающих секцию, остаются неизменными в течение долгого времени?

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

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

Столбцы, которые будут выбраны для секционирования, должны быть ведущими компонентами индекса. Это называется секционно-ориентированный локальный индекс, который требуется при активации секционирования в таблице. Понимание ответов на этот вопрос определяет, является ли таблица хорошим кандидатом для секционирования.

Вы обычно выполняете поиск и сортировку по не секционированным полям?

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

Значения столбцов, определяющих секцию, известны в момент создания записи?

Секционные столбцы не поддерживают значение «UNKNOWN» или «?». Если значение поля, определяющего секцию, неизвестно в момент создания записи, то такое поле является плохим кандидатом для секционирования.

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

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

Заключение

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