Данный раздел посвящен оптимизации расположения ваших данных на дисковом пространстве. Для существующих баз данных перемещение или выгрузка и последующая загрузка больших объемов данных потребует длительного времени, что на практике может оказаться неприемлемым. Но при создании новой базы данных это не должно вызвать затруднений.
Один диск может одновременно осуществлять одну передачу данных. Два диска могут вести две передачи данных одновременно. Чем больше дисков вы будете использовать, тем выше может быть производительность. Скорость передачи данных не зависит от размера диска и несколько дисков меньшей емкости дадут большую производительность, чем один диск большой емкости.
Для увеличения производительности, желательно иметь сбалансированную нагрузку ввода-вывода для имеющихся дисков, чтобы каждый из них вносил равный вклад в общий объем работы. Если один из дисков выполняет намного больше работы, чем другие, и он не в состоянии справиться с такой нагрузкой, то тем самым он замедлит работу всей системы.
Самый эффективный способ балансировки нагрузки между несколькими дисками – создать страйпинг, объединяющий все физические диски в один логический диск с равномерным распределением данных по нему. Использование одного только страйпинга имеет существенный недостаток: если из-за сбоя вы потеряете один из дисков, то вы потеряете данные на всех дисках. Для получения достаточной надежности, страйпинг следует объединить с зеркалированием. Вы должны использовать пары (или даже тройки) зеркальных дисков, а затем использовать страйпинг для этих пар. Это надежнее, чем наоборот, потому что подобная конфигурация более устойчива к сбоям дисков.
В тестах проведенных на Linux и Windows мы обнаружили, что чем больше размер страйпинга, тем большую производительность он обеспечивает. Максимальный размер stripe, который вы можете использовать, зависит от используемой операционной системы или дисковой подсистемы.
Мы не проводили тестирования страйпинга размером более 256 КБ, т.к. это был максимально возможный для нас размер.
При использовании вместо страйпинга и зеркалирования дискового массива RAID-5, вы потеряете при нормальной работе около 45 % производительности6 и еще больше – при выполнении операций обслуживания и восстановления. Потеря производительности объясняется дополнительными служебными операциями записи, заложенным в работу RAID-5 – каждый блок должен быть записан на два диска, один для данных, второй для восстановления данных. В массиве с четырьмя дисками процесс записи всегда занимает 50 % общей пропускной способности диска по записи. Потеря производительности тем меньше, чем больше число дисков в массиве. В массиве RAID-5 с 20 дисками, дополнительный объем операций записи может составлять всего 5 %.
Однако если вам потребуется заменить отказавший диск, придется считывать все данные со всех остальных дисков, пока происходит восстановление отказавшего диска. Это требует длительного времени и вызывает очень значительную потерю производительности до тех пор, пока не будет завершено восстановление работоспособности массива.
Блоки большего размера обеспечивают бoльшую производительность ввода-вывода и делают хранение базы данных более эффективным. Во многих файловых системах UNIX заложен размер блока или размер страницы равным 4 или 8 КБ. Наилучшую производительность можно получить, если размер блока базы данных совпадает или кратен размеру страницы файловой системы.
Размер блока данных выбирается в момент создания новой базы, когда вы копируете пустую базу данных желаемого размера блока. После создания базы в нее нужно загрузить данные. Размер блока существующей базы данных изменить нельзя.
Если размер блока данных больше, чем размер страницы файловой системы, существует небольшая вероятность того, что запись блока данных в случае сбоя системы, например, при выключения электропитания, будет выполнена только частично. В большинстве случаев запись блока данных в две непрерывные страницы файловой системы будет выполнена за одну операцию записи на диск и обе страницы будут записаны вместе. Однако если две страницы файловой системы находятся на разных дорожках, то для их записи может потребоваться операция поиска. Если сбой питания произойдет в начале передачи первой страницы, диск может отключиться до того, как будет записана вторая страница. В этом случае на диск будет записана только половина блока данных, что приведет появлению оборванной страницы. Операция восстановления после сбоев не распознает подобную ситуацию и не сможет ее исправить.
На Linux-системах для соответствия размеру страницы файловой системы для базы данных следует использовать размер блока равный 4 КБ. Существующая архитектура виртуальной памяти на Linux’е не позволяет использовать страницы большего размера. В будущих версиях Linux это может измениться.На Windows-системах следует использовать размер блока данных в 4 КБ или установить размер кластера NTFS 8 КБ, после чего можно использовать размер блока базы данных в 8 КБ.
Для областей данных II-го типа для блоков вычисляются контрольные суммы, которые хранятся в заголовке блока, что позволяет обнаружить оборванные страницы. Если все ваши данные находятся в областях данных II-го типа, вы можете использовать размер блока, кратный размеру страницы файловой системы. (Примечание комментатора – в текущих версиях Progress’а проверка контрольных сумм блоков осуществляется только утилитой dbrpr. При работе базы такие проверки не проводятся. Но даже в случае обнаружения разорванной страницы восстановление потерянных данных будет невозможно.)
Для областей данных II-го типа, установите размер блока данных 8 КБ. Будущие версии OpenEdge RDBMS будут поддерживать бoльшие размеры блока данных.
Области данных II-го типа в сравнении с областями данных I-го типа обеспечивают более высокую производительность и лучшее использование дискового пространства с более низкой степенью фрагментации записей. Большинство утилит будут работать существенно быстрее с данными, хранящимися в областях этого типа. По этим причинам следует всегда использовать области данных II-го типа.
Тома фиксированной длины форматируются во время их создания. Тома переменной длины форматируются динамически, т.к. они расширяются во время работы, когда базе требуется больше места для хранения данных. Тома фиксированной длины обеспечивают несколько более высокую производительность потому, что не требуется расширения томов во время выделения места для индекса или данных в базе. Разница в производительности может существенно различаться в зависимости от конкретных операционной и файловой систем и от того, как сильно и как часто увеличивается ваша база данных. Разница максимальна при размере блока данных меньше чем 4096 байт. Разница в производительности по чтению между томами фиксированной и переменной длины отсутствует.
Разместите тома с журналами before-image на других дисках, отдельно от томов данных.
Вы ведь хотите, чтобы запись журнала before-image была как можно более эффективной и не конфликтовала с другой деятельностью.
Если на одной и тоже машине работают несколько баз, то следует разместить их журналы before-image вместе с томами данных. Вы ведь используете страйпинг для экстентов с данными, не так ли?
На рынке имеется большое разнообразие подсистем дискового хранения, начиная от различных типов контроллеров дисков, например, предлагаемых 3Ware, до крупных систем хранения, предлагаемых EMC, IBM и другими фирмами. Большинство из них может успешно использоваться с OpenEdge RDBMS.
6 данные получены при тестировании 6 дисками