Определение размера области хранения
Определение размера области хранения
Следует определить количество дискового пространства, которое необходимо будет отдать под размещение области хранения. OpenEdge размещает данные и индексы с хорошим уровнем уплотнения. В самом лучшем случае большинство областей, содержащих данные используются с эффективностью 90 — 95%, а эффективность использования индексных областей лежит всегда около 95%. Для планирования желательно использовать показатель 85%. Это разумное решение. Используя пример из предыдущей главы мы рассчитаем действительный объем данных — 61 миллион байт.
Это — фактический объем данных. Теперь разделим его на ожидаемый процент заполнения. Чем ниже этот процент, тем больше будет занимаемый объем.
Теперь определим размер в килобайтах — поделим полученное значение на 1024. Этот шаг — необходим, так как при описании структуры БД в st-файле размер областей указывается всегда в килобайтах (независимо от размерности блока БД).
Итак — в st-файл мы поместим число 70083.
Если в области есть еще несколько объектов, то те же самые вычисления следует сделать для каждого объекта и определить общий размер для области хранения.
Использование томов (экстентов)
Большинство администраторов предпочитает использовать для задания размера тома «двоичные» номера — числа таких размерностей проще всего контроллировать из операционной системы. Например, будет сразу видно, что экстент начал расти. Для нашей таблицы-примера можно отвести один экстент постоянного размера в 102400KB (сюда заложено и место для роста таблицы) и один экстент переменной длины (variable extent). Такой том переменной длины должен быть у каждой области — это позволит области расти, если свободное место в фиксированном экстенте закончится. Экстент такого типа лучше не использовать (из-за производительности), но быть он должен всегда. Если такого тома не будет, то области некуда будет расширяться. (кстати, у меня была один раз такая ситуация с 10.1C и неправильным лимитом filesize в операционной системе для пользователя, под которым запускалась БД. База не остановилась, писала в логе, что не может расширить экстент — /dmi).
Экстенты позволяют распределять данные по разным физическим томам (если вы не используете stripe). Например, мы можем разделить 70Mb данных на несколько физических томов. Разделим область на 8 фиксированных экстентов по 10Mb плюс один переменный и распределим чередуя на три разных дисковых устройства.
Как показано на рисунке первый, четвертый и седьмой тома находятся на первом диске, на втором диске — тома номер пять, два и восемь и на третьем — третий, шестой и переменный том с номером девять. OpenEdge заполняет тома по порядку (сначала 10 Mb первого тома, затем 10 Mb второго итд). При использовании такого чередования на каждом дисковом устройстве будет смесь из «старых» и «новых» данных. Такой способ не так хорош, как аппаратное чередование со страйпом размера 128K, но все равно он позволяет более-менее размазать нагрузку на дисковые устройства.
Даже при использовании аппаратного чередования может возникнуть необходимость деления области на экстенты. Только лишь в версии 9.1C Progress сделал возможным поддержку больших файлов для базы данных (да и то — в этой версии не для всех операционных систем — /dmi). Это позволило использовать экстенты размером до 16Gb. Для включения данной возможности необходимо было исполнить утилиту proutil для базы данных с определенным параметром , который включал поддержку больших файлов (см. документацию OpenEdge Data Management: Database Administration). Обычный же лимит — 2GB (и по умолчанию БД не использует файлы больше, чем 2Gb). Если необходимо место для данных, большее, чем 2Gb — необходимо делить область на тома (или включать поддержку).
И еще одна причина — косвенная адресация (indirection). Косвенная адресация начинается тогда, когда одна inode-таблица не может адресовать все физические адреса в файле. Таблица inode хранит данные о содержимом диска и используется для трансляции логических адресов в физические. Если возникает необходимость во второй таблице — то на каждое обращение к БД у нас происходит дополнительное чтение с диска. Это не самым лучшим образом сказывается на производительности системы. Большинство ОС заявляют, что при определенных вариантах могут напрямую адресовать файлы в 4GB. Было проведено тестирование большинства операционных систем и выяснилось, что 1GB — самый безопасный вариант на большинстве современных файловых систем. На серверных версиях Windows следует использовать файловую систему NTFS.
Размещение индексов.
До сих пор мы обсуждали только хранение записей. Его очень просто рассчитать, в то время как хранение индексов — нет. Индексное сжатие делает такие расчеты непростыми, а алгоритм сжатия меняется с каждой версией, что еще больше усложняет задачу. Для того, чтобы все упростить — можно проанализировать вывод утилиты dbanalys и использовать ее информацию. Совершенно похожим образом (как и у данных) следует предусмотреть пространство для накладных расходов и роста.
Если база уже есть — статистика и dbanalys даст ответы на все вопросы. Если базы нет — остаётся делать одни прогнозы. Количество и природа индексных областей различно у каждого приложения. Word-индексы и индексы символных полей используют больше пространства,чем индексы числовых полей. Кроме того, индексы числовых полей более эффективно хранятся. Существуют базы, где индексы занимают больше места, чем данные, но такие базы — исключение.
В общих чертах — индексы занимают, как правило 30% от всего размера хранимых данных. Поэтому, для определения размера индексных областей достаточно заложиться на 50% от размера данных. Помните, что этот процент может различаться в зависимости от схемы данных. Таким образом, эту оценку следует рассматривать только лишь как начальную точку в расчетах.
Пример ниже рассматривает часть вывода утилиты dbanalys, которая показывает пропорциональное отношение между данными и индексами в существующей БД. Эту информацию можно использовать для определения выделяемого пространства под области данных и индексов.
