СЕКРЕТЫ OPENEDGE: УПРАВЛЕНИЕ БАЗАМИ ДАННЫХ OPENEDGE ПРИ ПОМОЩИ OPENEDGE MANAGEMENT

ОПТИМИЗИРУЕМ ОБЛАСТИ БД

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

Цель оптимизации — получить максимальную производительность, используя все возможные решения архитектуры операционной системы и OpenEdge RDBMS.

ОПТИМИЗАЦИЯ ОБЛАСТЕЙ ХРАНЕНИЯ ДАННЫХ

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

ОБЛАСТИ ХРАНЕНИЯ

Основные причины для распределения данных по различным областям хранения:

• Управление размером отдельных областей хранения
• Уменьшение фрагментации

Распределение данных по разным физическим устройствам (размещение областей хранения на разных устройствах)

В прошлых версиях Progress записи таблиц, находящихся в одной области, перемешивались между собой. С течением времени данные размазывались по области, поскольку содержимое таблиц постоянно изменяется. В OpenEdge появились средства для минимизации такой фрагментации, кроме того у базы данных появилась возможность быстрого удаления данных. Если нам необходимо удалить таблицу из области хранения Типа I, то OpenEdge должен обработать отдельно каждую запись в том порядке, в каком задано условие для удаления. В области хранения Типа II возможно выполнение команды «drop table». Таблица удаляется при этом в одну операцию: первый кластер объекта маркируется как свободный. Поскольку кластеры соединены в цепочку, то все остальные кластеры в цепочке также станут свободными. Это довольно редкая операция,  но она демонстрирует возможности областей Типа II.

ОТДЕЛЕНИЕ МЕТАСХЕМЫ БАЗЫ ОТ ДАННЫХ ПОЛЬЗОВАТЕЛЕЙ

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

УСТРАНЕНИЕ ФРАГМЕНТАЦИИ ДАННЫХ

Фрагментацию данных можно разделить на два типа — физическую и логическую. Физическая фрагментация данных (Physical scatter) происходит тогда, когда записи одной таблицы распространяются по всей области хранения и перемешиваются с записями других таблиц. Единственным способом избежать такого развития событий в версии 9 был вынос таблицы в отдельную область хранения. Такое решение делает сопровождение базы данных администратором очень сложным — ведь условие одной таблицы на область резко увеличивала бы количество областей базы данных. Такую структуру базы данных сложно сопровождать.

В OpenEdge 10 была представлена концепция кластеризованных областей хранения (области хранения Типа II — Type II storage area). Области Типа II группируют внутри себя объекты данных. Размер кластера настраивается для каждой области. Размеры кластера могут быть 8, 64 или 512 блоков. Для примера, область Типа II размером 512 блоков для базы данных с блоком 8Kb группирует в кластере почти 4Mb данных или индексов. Такая группировка данных уменьшает физическую фрагментацию записей и увеличивает эффективность работы с данными. Особенно ярко это проявляется при построении отчетов, однако тесты подтверждают ускорение и для остальных типов операций. Следовательно, необходимо использовать области Типа II везде, где это необходимо. Использование областей такого типа уменьшает физическую фрагментацию данных, но от риска логической фрагментации данных не спасает.

Логическая фрагментация возникает тогда, когда записи сохранены в другом порядке, чем они обычно запрашиваются приложением. Записи сохраняются в базе в том порядке, в каком они были введены или же сохраняются в тех местах, где записи были ранее удалены. Обычно с течением времени ваши данные становятся все более логически фрагментированными. Единственное лекарство — это выгрузка и загрузка (dump and load) данных. Для тех приложений, где возможен простой базы данных — это нормальный вариант, но для систем, которые работают в режиме 24×7 это либо невозможно, либо сопряжено с определенной дополнительной работой. Операции выгрузки и загрузки данных рассматриваются ниже. Самое главное — необходимо выгрузить и загрузить данные ровно в том порядке, в котором они чаще всего используются. В большинстве случаев — в порядке, определяемом первичным ключом. Для того, чтобы узнать наиболее используемый индекс при чтении записей в таблице необходимо просмотреть VST-таблицу _IndexStat.

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

КРИТЕРИИ РАСПРЕДЕЛЕНИЯ ДАННЫХ ПО ОБЛАСТЯМ ХРАНЕНИЯ

Существует ряд способов для определения наилучшего распределения данных между областями хранения. Самое первое, что необходимо сделать — это попытаться выделить большие таблицы. Если есть таблицы, которые имеют размер в несколько гигабайт, то они должны быть помещены в отдельные области. Затем надо сгруппировать таблицы с похожими средними размерами записей. Другой, не менее важный фактор — это понимание того, как и когда используются данные таблиц. Если можно четко выделить таблицы, к которым осуществляется круглосуточный доступ и таблицы, которые используются, к примеру, для закрытия дня вечером, то самый лучший выход — это разделение таких таблиц между разными областями для достижения лучшей масштабируемости вашего приложения. Размер таблиц — относителен. Например, таблицу размером 1Gb нельзя считать большой кроме тех случаев, когда база данных имеет сравнимый размер. Необходимо выработать свой критерий для определения того, является ли таблица большой или нет. Пример такого критерия — считать таблицу большой, если её объем превышает 10% от объема вашей базы данных. Для маленьких или средних баз данных количество областей хранения должно быть около десяти. Необходимо отталкиваться от числа 10, увеличивая количество областей после анализа данных для больших баз и уменьшая для маленьких. Это число является хорошей отправной точкой.

КАК ПОСТУПИТЬ С ИНДЕКСАМИ?

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