СЕКРЕТЫ OPENEDGE: УПРАВЛЕНИЕ БАЗАМИ ДАННЫХ OPENEDGE ПРИ ПОМОЩИ 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»)

РАЗМЕР БЛОКА

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

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

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

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

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

ОПРЕДЕЛЯЕМ КОЛИЧЕСТВО ЗАПИСЕЙ В БЛОКЕ

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

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

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

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

РАСПРЕДЕЛЕНИЕ ТАБЛИЦ МЕЖДУ ОБЛАСТЯМИ ХРАНЕНИЯ

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

• возможность управлять операциями ввода/вывода (т.е. нагрузкой на дисковую подсистему)
• соответствовать требованиям приложения
• желание ускорить «тяжелые» оффлайновые утилиты для обслуживания БД

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

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

Улучшения производительности мы добиваемся по двум причинам:

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

И последнее — данные в базе неоднородны с точки зрения требований к производительности. Например, доступ к данным о складских запасах происходит очень часто и критичен по времени, а записи, содержащие комментарии пользователей к каким-либо сущностям — обновляются или читаются из базы относительно редко.  Мы можем поместить области с критичными таблицами на «быстрые» дисковые устройства. Для такого подхода требуется исследование работы приложения. Увидеть активности таблиц можно в OpenEdge Management или в виртуальных системных таблицах (VST — Virtual System Tables). В OE Management активности видно по временной оси — это позволяет лучше всего вникнуть в происходящее.

Целями сбора такой информации являются:

• Больший контроль над данными
• Ускорение оффлайновых утилит
• Максимальная эффективность по размещению записей без каких-либо серьезных затрат

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

Рассмотрим такую ситуацию на примере.

ПРИМЕР

Допустим, у нас есть таблица в БД, в таблице — 1 миллион записей. Средний размер записи — 41 байт.

1. Добавим служебную информацию к этому числу (примерно 20 байт)
2. Разделим размер блока БД на полученное число

Теперь необходимо принять решение. Нам надо выбрать число от 1 до 256, являющееся степенью двойки. Получившееся значение 134 предполагает выбор между 128 и 256. Если мы выберем 128, то исчерпаем слоты для записей прежде, чем закончится место в блоке. То есть, в каждом блоке у нас будет неиспользуемое пространство.  При выборе 256 мы рискуем тем, что записи будут фрагментированы. Присмотримся к записям в таблице пристальней. Если записи в таблице активно изменяются, то мы должны выбрать меньшее число для RPB (128) — тем самым мы  избегнем фрагментации. Если же записи только добавляются в таблицу и не меняются с течением времени, то нужно выбрать больший номер (256), ведь OpenEdge, как правило, не разбивает запись на фрагменты при добавлении её в БД. Фрагментация записи происходит при дальнейшем обновлении, поэтому надо быть внимательным с такими записями — как правило, их размер при этом увеличивается.

Если мы выбрали меньшее число RPB, то мы можем определить, сколько места на диске не будет использовано (wasted space):

1. для этого мы возьмем число записей в таблице и разделим на значение RPB. Мы определим число блоков, которые будут выделены для хранения записей.
2. умножим фактический размер записи на RPB. Из размера блока базы данных вычтем полученное значение. Мы определим количество неиспользуемых байт в блоке.
3. общее число блоков умножим на неиспользуемое пространство в блоке

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

НЕИСПОЛЬЗУЕМЫЕ СЛОТЫ

Есть и другая сторона медали — если у нас есть неиспользуемые слоты для записей в блоке, то максимальное количество записей в области хранения будет меньше, чем могло бы быть. С введением 64-битного recid в 10.1B ситуация стала не такой сложной, как в предыдущих версиях. Написанное выше не означает, что необходимо стремиться сделать RPB всех областей равным 256 для максимальной плотности записей. Просто необходимо знать, что существуют определенные лимиты, и они представлены в таблице ниже. Кроме того, существует способ определить идеальное значение RPB и BPC (blocks per cluster) для области и он будет описан ниже в главе «Определение размера блока».

Таблица приблизительно показывает максимальное количество записей на область хранения

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

---