вторник, 26 октября 2010 г.

Скажи нет JFS и RAID5 для файлов баз данных

No JFS, no RAID5 ?


Интересная заметка в блоге Art Kagel на тему использования журналируемых ФС для файлов баз данных. Вообще я давно подозревал что дополнительное журналирование на уровне файловой системы (ФС) ухудшает производительность СУБД. Во первых СУБД и так обеспечивает журналирование и восстановление данных, это заложено в ее архитектуру. Может быть журналирование на уровне ФС обеспечит дополнительную защиту? Но оказывается что это не так. Дополнительный слой в виде журналирования ФС может снизить надежность хранения данных. Даже если производится только журналирование метаданных - результат скажется на производительности базы, поскольку на уровне ФС блоки файлов данных базы могут оказатся в разных местах диска и возрастет фрагментация.
Автор заметки предлагает использовать для хранения файлов базы либо сырые устройства, что логично, или старую добрую ext2 которая не имеет журналирования.
Вот что касается опции журналирования - ее что, совсем нельзя отключить на ext4 например? А JFS в AIX, у нее как обстоят с этим дела?

5 комментариев:

Иван комментирует...

В своё время я работал системным администратором AIX на сервере IBM RS6000.

Понятно, что техника эта на данный момент уже морально устарела да и AIX был версии 3.2.5. Но дело не в этом.

На этом "деле" работал IDS 7.1 и его базы хранились в физических разделах(Phisical Partitions -- PP) AIX-а, которые можно было перемещать по пяти логическим цилиндрам диска (т.е. можно было ближе к шпинделю их переместить, или ближе к краю). Кстати максимальная скорость обращения к таким разделам была когда они были в среднем цилиндре, а не как принято считать у пользователей PC, что максимальная скорость обращения к разделам на краю диска.

Т.е. AIX управляет как JFS, которая и сама "стоит" на PP-сах, так и самими PP-сами. И что самое интересное, я как администратор AIX-а не имел никакого доступа к базам (поскольку я видел только то, что было в JFS): c ними работали только программисты и DBA, Самое "страшное", что я мог сделать так это переместить физические разделы базы в другое место на диске, насколько помню даже удалить их нельзя было.

Может быть поэтому "проблемы с производительностью" был непонятный нам термин? )))

Кстати IDS у нас работал ещё и под SCO UnixWare 7.1.1 с RAID 1+0 и под SCO OpenServer на БЭСТе и по-моему наш DBA и тут использовал физические разделы диска для баз данных.

Вот так! А вообще хотелось вспомнить, как я в течение 4-5 лет со стороны наблюдал эффективность работы программистов IDS и Oracle: наши 2 программиста на 4GL управлялись с большим объёмом работ и гараздо быстрее, чем группа из 10 программистов -- подрядчиков, работающих в связке Delphi-Oracle. )))

Alex aka Andron комментирует...

Физические разделы это все таки не файлы на файловой системе, для них не применяется журналирование уровня ФС, нет дополнительного кэширования. Думаю в этом дело. По сути это ведь обычные сырые устройства, управляемые через слой LVM ?

Иван комментирует...

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

В описанном случае это делал AIX (управление разделами через LVM). Для Informix-а это уже были физические разделы, точнее логические, так как к физическим разделам имеет доступ только LVM AIX-а.

Я не знаю, есть ли у Informix-a возможность использовать неразмеченные диски или их части под базы данных.

В DB2 по-моему можно выбрать сырое устройство для базы данных, а готовый раздел уж точно можно. Но я уже давно с AIX не работаю. Могу сейчас только о DB2 для Linux/Widows что-то говорить и то для обычной персоналки )))

Иван комментирует...

Да, в DB2 можно создавать контейнеры для хранения данных и в неформатированных разделах и в не разбитых на разделы (сырых) дисках.

http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/topic/com.ibm.db2.udb.cc.doc/db2_udb/containersdefinedialog1.htm?noframes=true

Alex aka Andron комментирует...

Informix тоже умеет использовать raw device.