Оптимизируем структуру данных.

Продолжение перевода Adam Backman «OpenEdge Revealed:Mastering the OpenEdge Database with OpenEdge Management».
Перевод публикуется в виде статей и постоянно редактируется

Оптимизируем структуру данных.

В этом разделе представлен общий обзор структуры базы данных и подчеркивается важность грамотного подхода к проектированию физической структуры базы данных. База данных состоит из областей хранения (storage area), каждая из которых может содержать от одного до множества объектов. Под объектами в данном случае понимаются таблицы или индексы. Кроме них есть и другие объекты, такие как последовательности (sequences) и схема БД (schema). На текущий момент мы не можем управлять размещением этих двух последних объектов.

Каждая область хранения при размещении на диске делится на один или несколько экстентов (extent) (иногда их называют томами (volume)). Экстент – это обычный файл. Каждый экстент состоит из блоков и системный администратор определяет размер блока. Выбрать размер можно их следующих величин – 1KB, 2KB, 4KB и 8KB. Выбранное значение распостраняется на всю базу данных, но каждая область хранения может иметь свое значение количества записей на блок (records per block, RPB).

Правильное проектирование базы данных несомненно важно – ведь при проектировании определяются характеристики областей хранения.  При проектировании базы данных надо учитывать ряд факторов, самый важный из которых – размер записи в базе данных. Это очень легко, если у нас уже есть база данных – необходимо запустить процедуру dbanalys и просмотреть ее вывод. Другие же факторы, которые надо учитывать не так легко увидеть администратору БД, так как необходимо знать – каким образом работает приложение. Это могут знать только разработчики. Например, важно знать ответы –  к каким таблицам происходит последовательный доступ, а к каким – случайный. Какие таблицы используются постоянно, а какие таблицы являются хранилищами архивной информации? Какие таблицы используются большинство времени суток, а какие редко? Обновляются ли существующие записи в таблице или они статичны? Ответы на такие вопросы помогают определить размер и расположение базы данных на дисках. Кроме всего прочего станет ясно как наилучшим образом утилизировать производительность дисковой подсистемы.

Вычисление размера областей БД

При определении размера области хранения необходимо узнать, какая информация размещена или будет размещаться в этой области. Как было пояснено выше – область может состоять из таблиц и/или индексов. Область по умолчанию (область с номером 6) должна хранить в себе только определения схемы и последовательностей.  Другие данные хранить в этой области можно, но это не рекомендуется – такой подход позволить сэкономить много времени в дальнейшем при работах с базой данных. Если мы говорим о существующей базе данных – первым шагом будет запуск утилиты tabanalys. Всю необходимую для этого информацию можно найти в руководстве OpenEdge Data Management: Database Administration.

На иллюстрации изображена часть вывода данной утилиты:

После запуска утилиты анализа  таблиц необходимо обратить внимание на количество записей в таблице (Records) и на средний размер записи (Mean). Просмотрите результаты каждой таблицы и упорядочите их по среднему размеру записи.

В большинстве случаев значения размера блока в 8KB является наиболее соответствующим значением для оптимальной работы в операционной системе. Практически единственным исключением является операционная система Windows, где размер блока в 4KB будет являться наилучшим значением. Каждая запись при физическом размещении в базе данных использует еще порядка 20 байт для служебной информации, поэтому при любых расчетах к среднему размеру записи необходимо добавить число 20. Как объяснялось выше – эти 20 байт используются для описания записи и для заголовка RM-блока (подробнее см “Внутренняя структура OpenEdge стр 49”)

Размер блока

Почему блок размером 8KB лучше использовать на одной операционной системе, а на другой нет? Ответ кроется в том, каким образом операционная система работает с файлами и памятью. ОС Windows управляет файлами и памятью при помощи блоков в 4KB. Иными словами говоря – обмен данными между памятью и дисками происходит блоками по 4KB.

Хорошим тоном является использование такого размера блока, который равен или кратен размеру блока операционной системы. Это означает, что Windows будет так же эффективно работать с блоком 8KB? Нет, это не так. Хотя это и кратный размер блока, но в большинстве случаев скорость работы будет ниже, так как Windows оптимизирована для работы с блоками 4KB. На большинстве UNIX-систем размер блока ОС будет равен 8KB или кратным 8KB. Размер блока ОС – настраиваемая величина.

В общих случаях, для UNIX-систем размер блока БД стоит выбирать как 8KB, но и тут не обойдется без исключений.

Суть действий по выбору размера блока БД – максимальным образом утилизировать возможности операционной системы для более эффективной работы OpenEdge. В большинстве случаев работает правило – для Windows размер блока равен 4KB, для UNIX – 8KB

Единственный способ проверить свои настройки – это провести тесты. Только в этом случае можно получить точные данные о наиболее подходящем размере блока БД.

Определяем количество записей в блоке

Для определения количества записей в блоке используют следующую формулу:

  1. Определить средний размер записи
  2. Добавить 20 байт к среднему размеру записи
  3. Разделить размер блока БД 8192 (для размера блока 8KB) или 4096(4KB) на полученный результат в предыдущем пункте.

OpenEdge позволяет иметь от 1 до 256 записей в блоке в каждой области хранения. Количество записей в блоке является степенью двойки (1,2,4,8,16,32,64,128,256)

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

Leave a Reply

You must be logged in to post a comment.