URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID3
Нить номер: 40330
[ Назад ]
Исходное сообщение
"OpenNews: Использование сырого (raw) дискового раздела для хранения базы Firebird"
Отправлено opennews , 23-Фев-08 10:03 
"Using raw device in Firebird (http://pmakowski.ibphoenix.fr/post/2008/02/15/Using-raw-device)" - использование сырого (raw) дискового раздела для хранения базы Firebird.

URL: http://pmakowski.ibphoenix.fr/post/2008/02/15/Using-raw-device
Новость: http://www.opennet.me/opennews/art.shtml?num=14372

Содержание
Сообщения в этом обсуждении
"Использование сырого (raw) дискового раздела для хранения базы Firebird"
Отправлено eplumber , 23-Фев-08 10:03 
Прикольно!
И насколько быстрее?
ИМХО, на файловой системе все же будет быстрее за счет кэширования ОС
Тобишь, одна база - один раздел?
Наверно, не очень удобно.
Вдруг база выростет?
Разделы двигать?
"Использование сырого (raw) дискового раздела для хранения ба..."
Отправлено vitek , 23-Фев-08 10:51 
> ИМХО, на файловой системе все же будет быстрее за счет кэширования ОС

наоборот. файловый кэш только мешает.
по крайней мере в oracle именно так.
то что сложнее - это правда, надо знать структуру б/д, ее прирост и т.д.
но в результате - выигрышь до 30 %. Плюс - экономия ОЗУ (той, что уходила на файловый кэш)

"Использование сырого (raw) дискового раздела для хранения базы Firebird"
Отправлено Legiar , 23-Фев-08 11:13 
Выигрыш действительно есть, и довольно существенный.
Уже около года лежит база на raw разделе - полет нормальный.
Кстати, если располагать на томе LVM - можно и размер тома увеличивать. А потом backup/restore - и поехали дальше.
"Использование сырого (raw) дискового раздела для хранения базы Firebird"
Отправлено vadiml , 25-Фев-08 10:16 
Я сомневаюсь что для FB от этого будет прок, лучше вместо этого использовать xfs, да и надёжность гораздо выше будет

Вот у Oracle выигрыш действительно будет, там всё своё есть

"Использование сырого (raw) дискового раздела для хранения ба..."
Отправлено Legiar , 25-Фев-08 13:20 
>Я сомневаюсь что для FB от этого будет прок, лучше вместо этого
>использовать xfs, да и надёжность гораздо выше будет

Спорить не буду - достаточно просто провести несколько тестов.
По поводу доступа к файлу БД - имхо (и не только мое) - сырой раздел будет существенно быстрее.
1. Кеширование файловых операций не нужно.
2. Доступ к файлу осуществляеться только одним процессом - соответственно не требуется "прокладка" между процессом (фаер) и файлом БД.
3. Если у вас нет упса (странно, кто гоняеть БД без нормального питания, но всякое бывает) - вероятность потерять БД на файловой системе - выше. Да и в принципе даже если есть усп - просто какие-либо сбои. При использовании сырого раздела - вероятность восстановления БД выше - лично в этом убедился.

>Вот у Oracle выигрыш действительно будет, там всё своё есть

Ну давайте не будет сравнивать Оракл и мааааааленький Файр - у каждого своя ниша применения.