тормоза BLOB в GDB

← →
Maxim______ (2004-09-21 01:10) [0]

Прошу совета.
За основу проекта взята firebird(также пробовал Yaffil)
Для доступа к базе использую tIBtable из ibx. Потому что все базы локальные. и получаю дикие тормоза с сохранением и чтением блобов. Pagesize пробовал разный. Сохранение 30 метров идёт 20-30 секу! За это время я успеваю скопировать всю gdb базу размером 150 MB.
Второй вопрос. Как программно сжать GDB базу так чтобы она не просто перестала расти а именно стала занимать меньше места на диске?

← →
P.N.P. © (2004-09-21 03:08) [1]

1) http://www.ibase.ru/devinfo/dontdoit.htm (см. пункт 16)
2) откуда такая потребность (если не секрет) - >Сохранение 30 метров?

← →
Maxim____ (2004-09-21 03:56) [2]

P.N.P. © (21.09.04 03:08) [1]
tibtable неприемлема для сетевых задач или многопользовательского доступа. Но на самом деле она генерирует тот же sql. там ещё написано про то что если я буду пользоваться ttable, то не буду знать sql. это не есть причина не пользоваться ttable.

Иногда есть потребность созранения и 50 метров. Сохраняются большие объёмы графики.

← →
Sergey_Masloff (2004-09-21 06:52) [3]

Maxim____ (21.09.04 03:56) [2]
>Но на самом деле она генерирует тот же sql.
На самом деле она ТОЖЕ генерирует SQL но СОВСЕМ не ТОТ ЖЕ. Уверен что после ее SQL она тебе перед записью не плодит версии твоего 30 Мб рекорда? Уверен что тоже самое не делает при UPDATE который не затрагивает самого BLOB? Я делал некое хранилище, 30 Мб объектов там конечно не было типичный размер 2-10 Мб по сети все было мгновенно. Ну, секунда может. Скорее всего меньше. Вобщем, у пользователей раздражения не вызывало.

По пп.2 -> Backup + Restore со сборкой мусора.

← →
sniknik © (2004-09-21 08:28) [4]

> Потому что все базы локальные.
только потому что они на этом же компе? но работа то с SQL сервером, доступ аналогичен через его ядро как и для лежащей в сети. (т.е. твоя программа не обращается непосредственно к файлу базы)

> то не буду знать sql. это не есть причина не пользоваться ttable.
а тормоза на открытии причина? хотя и этого может не быть при серверном курсоре (который в компонентах TIBxxxx и используется похоже ;), поэтому этого и не видно, но только потому что это время "размазывается" по общему в работе с таблицей при докачке слудующих порций т.е. стоит дойти до конца таблици и все записи выкачаются на клиента... а это часто. любители table например простую сумму поля получают сканированием таблици...).

table оправдан в единственном случае, данные из таблици нужны всегда полностью, на каждом открытии. (такого почти не бывает)

← →
Maxim____ (2004-09-24 02:42) [5]

По пп.2 -> Backup + Restore со сборкой мусора.

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

← →
Sergey_Masloff (2004-09-24 07:00) [6]

Maxim____ (24.09.04 02:42) [5]
>сделать программно,
1) Что мешает запустить программно gbak?
2) Есть еще services API. Не знаю что понимается под стандартными, но видимо все распространенные компоненты его поддерживают.

P.S Я бы все же так не делал. Лучше положить на сервере 2 *.bat файла для backup и restore (или 1 общий) которые будут запускать gbak с соотв. опциями. *.bat запускать планировщиком по ночам или вручную.

← →
сергей1 (2004-09-24 08:06) [7]

>Иногда есть потребность созранения и 50 метров. Сохраняются большие объёмы графики.

существует рекомендация, что при необходимость сохранения в BLOB данных > 64 кб, от BLOB надо отказаться и хранить все в отдельных файлах, а в базе держать только ссылку на файл. А когда потребуется извлечь данные - извлекать их напрямую из файловой системы. Такой подход должен работать раза в 3 быстрее BLOB. Эта рекомендация для MSSQL, но думаю для IB тоже актуально.

>table оправдан в единственном случае, данные из таблици нужны всегда полностью, на каждом открытии

query с запросом select * справиться ничуть не хуже, так что отпадает последний довод в пользу table"ов

← →
Sergey_Masloff (2004-09-24 08:24) [8]

сергей1 (24.09.04 08:06) [7]
>существует рекомендация, что при необходимость сохранения в >BLOB данных > 64 кб, от BLOB надо отказаться и хранить все в >отдельных файлах, а в базе держать только ссылку на файл.
И соответственно отказаться от контроля целостности, единой схемы резервного копирования и так далее. Не самый лучший совет.
К тому же придется реализовать сервер приложений (ну не давать же юзеру права на файловую систему сервера? Это вообще ни в какие ворота не лезет).

Рекомендация дана, видимо для MSSQL6.5 и связана с работой его механизма блокировок. В ORACLE и в INTERBASE особых проблем хранения БЛОБов нет и не было, на то он и БЛОБ чтобы хранить БОЛЬШИЕ объекты.

← →
сергей1 (2004-09-24 08:59) [9]

все верно, падает безопасность (эти файлы оказываются вне контроля SQL server"a), юзеру необходим доступ к определенной папке не сервере (ну либо сервер приложений), неудобно backup"ить, но если необходима скорость - нужно идти на жертвы. Рекомендация для MSSQL 2000.

тормоза BLOB в GDB Найти похожие ветки