Имеется система многоканальной записи речи. В настоящий момент в базу складывается вся служебная информация, а сами аудиоданные хранятся в отдельных файлах. Есть желание писать их в виде BLOB полей (Соображения безопасности, удобства удаленного доступа и администрирования). Потенциально сеанс может занимать и 20MB.
Интересует мнение уважаемых форумчан по перечисленным вопросам.
1. Как ведут себя сервера FB1.5 и FB2.0 c большими BLOB полями? Есть ли у кого-нибудь опыт эксплуатации таких систем? Интересует именно вопрос полей BLOB большого размера, а не большого количества записей.
Как поведет себя сервер если ему одновременно будут «наливаться», скажем, 32 BLOBа?
2. Какие будут соображения по способу «наливания» таких BLOB полей?
Имеется в виду следующее:
Цитата из FAQ ( http://www.ibase.ru/ibfaq.htm#blob )
Очевидно, что во всех этих случаях требуется чтобы значение будущего поля BLOB находилось в памяти, что неприемлемо в случае больших полей. Работать через TIBBlobStream напрямую также не получается. В нем есть метод Write, однако анализ исходного текста показал, что он также собирает все в памяти, а физически записывает в методе TIBBlobStream.Finalize.....делать это можно двумя вариантами:
1. передача blob через параметр. IBQuery1.ParamByName('blb').asBlob:=blobvar;
2. 2. изменение столбца "редактируемого" DataSet - запись blob из файла в столбец:
IBDataSet1.Edit;
(IBDataSet1.FieldByName('BLB') as TBlobField).LoadFromFile('c:\blob.bin');
IBDataSet1.Post;
function TIBBlobStream.Write(const Buffer; Count: Longint): Longint;
begin
CheckWritable;
EnsureBlobInitialized;
result := Count;
if Count <= 0 then exit;
if (FPosition + Count > FBlobSize) then SetSize(FPosition + Count);
Move(Buffer, FBuffer[FPosition], Count); Inc(FPosition, Count);
FModified := True;
end;
Исходя из этого прихожу к выводу о необходимости лезть в API и самому вызывать
isc_create_blob2
isc_put_segment; // n-раз
isc_close_blob
3. Что произойдет в следующем случае:
при помощи функций API
начать транзакцию
начать заливать данные в поле BLOB
откатить транзакцию до вызова isc_close_blob
откатить транзакцию после вызова isc_close_blob, но не приклеив BLOB ID ни к какой записи.
4.
Цитата из FAQ
Все красиво и понятно опять же в случае если заливать весь блоб целиком, а вот как быть если заливать его частями. Не произойдет ли следующее:Первый фрагмент сдуру поместился на странице с данными и соответственно похерит производительность, а потом все равно серверу придется выделять дополнительные страницы, но первый фрагмент сервер же переносить не будет?Сервер сохраняет blob следующим образом:
1. Если размер данных, записываемых в blob, помещается на свободном месте рядом с оригинальной записью, которой принадлежит blob - blob записывается на это место (при этом возникает "фрагментированность" страниц данных блобами, что в некоторых случаях может ухудшить производительность при обработке только записей). Объем свободного места зависит от размера страницы и количества записей, уже размещенных на этой странице.
2. Если свободного места на странице записей нет, то для blob выделяется отдельная страница или несколько, в зависимости от размера blob. Если после записи blob на такой странице осталось свободное место, то оно остается пустым и не будет занято другими blob.