Расухание базы данных

WildSery · Сообщение **WildSery** » 15 май 2007, 11:03

hvlad писал(а):Это не связано с мусором. CommitRetaining здесь тоже не при чём. Он читает всю таблицу (с блобами) целиком каждый раз, когда хочет вставить новую запись - все имеющиеся блобы проходят через его ф-цию и она создаёт новые их копии. Коммит только удалит накопленные тек. тр-цией блобы, но постоянных блобов всё больше и больше.

Влад, я это написал потому, что в самом начале автор утверждал, что после бэкап-рестора база "нормальных размеров", т.е. никаких непредусмотренных дублей у него в реальности нет (не в "тестовом" примере).

hvlad · Сообщение **hvlad** » 15 май 2007, 11:04

ivl писал(а):Честно сказать, я немного разочарован: при обработке функцией блоб поля в операторе SELECT на большом объеме выбираемой информации в одной транзакции происходит рост базы...

А кто тебя заставляет вычитывать все блобы таблицы каждый раз ??? Никто в здравом уме так не делает

ivl писал(а):Отсюда я делаю для себя один вывод: обработка функцией блоб поля в операторе SELECT есть зло

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

ivl писал(а):т.е. раздуть базу можно и ничего в неё не вставляя, только сделав большую выборку с обработкой в SELECT блобов. Ни как это ранее я не предполагал.

Жизнь вообще сильно отличается от наших о ней представлениях

ivl писал(а):Теперь мне просто кажется странным почему нельзя повторно использовать временные блоб до окончания транзакции? Или просто Firebird не имеет механизма проверки используется блоб или нет.

Тебе на клиента блоб_ид вернули ? И как движок может знать о твоих намерениях после этого ?

ivl писал(а):Интересно, наблюдался ли бы такой же эффект если бы использовалось поле VARCHAR аналогичного размера?

Нет

ivl · Сообщение **ivl** » 15 май 2007, 11:23

Она не есть зло, просто делать ее надо правильно: с помощью блоб-фильтров, а не страшными удфками.

Этот вариант я уже когда-то рассматривал для своего использования.
И даже вопрошал по его поводу на этом форуме:
http://forum.ibase.ru/phpBB2/viewtopic.php?t=2196
Но ввиду отсутствия необходимой мне функциональности в его использовании, отверг. Может что-то новое появилось с блоб-фильтрами
в Firebird 2? Тогда возможно имеет смысл попробовать их снова.

Тебе ж ясно сказано, что место используется повторно. А насчёт "до окончания транзакции" - откуда известно, что не обратишься к нему?

Если создание временного блоб происходит в контексте оператора SELECT, отдельного, не входящего в состав ни триггера, ни хранимой процедуры, то как можно суметь обратиться после его окончания (оператора) к временным блоб? Мне казалось логичным, что после его выполнения место отданное для временных блобов должно быть освобождено еще до окончания транзакции. (Я уже понял, что неправ, но всё равно странно почему это не выполняется сервером.)

мда. "разочарован". прямо анекдот получается. "я разочарован, что пихаю тучу временных блобов в базу". Ты в функции ПИШЕШЬ БЛОБ НА ДИСК! Или ты ожидал, что волшебным образом запись будет происходит "в никуда"?

Я прекрасно понимаю, что запись не происходит "в никуда"
Честно сказать, я предполагал, что при выборке временные блоб не будут помещаться именно в базу данных. Думал, что для их хранения используются временные файлы. Это мне казалось логичным (см. выше)

Как это "обработка ... не вставляя..."???

Я хотел сказать о том, что не вставляя в этой транзакции. Т. е. если в базе есть уже 200 записей, мы начинаем транзакцию и делаем выборки.
Если мы сделаем в транзакции одну выборку всех двухсот записей то база может вырасти на 200*(Размер области под блоб). Но если мы сделаем в одной (именно одной) транзакции несколько выборок, то размер базы вырастет на (число выборок)*200*(Размер области под блоб). И дело тут не в том сколько я в одном операторе выбираю (т. е. если я выполню 1000 SELECT по одной записи в каждом, то база может увеличиться на 1000*(Размер области под блоб) ).
Для себя я делаю такой вывод, что мне придется либо делать COMMIT после каждого SELECT, либо отказаться от обработки блоб удфками.

WildSery · Сообщение **WildSery** » 15 май 2007, 12:10

ivl писал(а):то как можно суметь обратиться после его окончания (оператора) к временным блоб?

А что, есть какой-то "конец" у оператора SELECT, кроме окончания транзакции? Если бы после "окончания оператора" всё прибивалось - ты б данные из него считать не смог, не правда ли?

ivl писал(а):Если мы сделаем в транзакции одну выборку всех двухсот записей то база может вырасти на 200*(Размер области под блоб). Но если мы сделаем в одной (именно одной) транзакции несколько выборок, то размер базы вырастет на (число выборок)*200*(Размер области под блоб). И дело тут не в том сколько я в одном операторе выбираю (т. е. если я выполню 1000 SELECT по одной записи в каждом, то база может увеличиться на 1000*(Размер области под блоб) ).
Для себя я делаю такой вывод, что мне придется либо делать COMMIT после каждого SELECT, либо отказаться от обработки блоб удфками.

Чего-то я недопонимаю. Тебя напрягает, что база выделит место под временное хранение твоих рабочих блобов в размере пускай даже в гигабайт?
Извини, телепатор я начинающий, и не понимаю мотивов такой "экономии".

Сообщение **kdv** » 15 май 2007, 12:18

либо отказаться от обработки блоб удфками.

отказаться от ТАКОЙ обработки blob.
ты так и не рассекретил, зачем ты при чтении преобразуешь блоб путем его сохранения. Вообще по уму сервер должен был тебя при этой операции обломать. Здесь скорее всего сервер не видит контекста, в котором выполняется udf, и допускает операцию модификации блоба.

ivl · Сообщение **ivl** » 15 май 2007, 12:53

А что, есть какой-то "конец" у оператора SELECT, кроме окончания транзакции? Если бы после "окончания оператора" всё прибивалось - ты б данные из него считать не смог, не правда ли?

Конец у оператора есть. На сколько я помню, "курсоры" в Firebird НЕ двунаправленные, т. е. при выборке (FETCH) записи на клиента, место занимаемое ей ранее можно смело освобождать сразу, так как вернуться к ней назад нет никакой возможности. Или я неправ?

отказаться от ТАКОЙ обработки blob.
ты так и не рассекретил, зачем ты при чтении преобразуешь блоб путем его сохранения. Вообще по уму сервер должен был тебя при этой операции обломать. Здесь скорее всего сервер не видит контекста, в котором выполняется udf, и допускает операцию модификации блоба.

Да с какой стати обломаться? Я НЕ ПИШУ в тот же блоб из которого читал! Ниже заголовок удфки:

Код: Выделить всё

procedure bl_blob(InBlob, OutBlob: PBlob); cdecl; export;

Блобу InBlob соответствует блоб таблицы, а запись результата обработки происходит в OutBlob -- второй, возвращаемый блоб.

Код: Выделить всё

DECLARE EXTERNAL FUNCTION BL_BLOB
    BLOB,
    BLOB
    RETURNS PARAMETER 2
    ENTRY_POINT 'bl_blob' MODULE_NAME '_test_udf';

Помоему это нормальный способ. В чем здесь криминал то?

hvlad · Сообщение **hvlad** » 15 май 2007, 13:29

kdv писал(а):ты так и не рассекретил, зачем ты при чтении преобразуешь блоб

Например распаковывает упакованное

kdv писал(а):путем его сохранения.

Это ты о чём ?

kdv писал(а):Вообще по уму сервер должен был тебя при этой операции обломать. Здесь скорее всего сервер не видит контекста, в котором выполняется udf, и допускает операцию модификации блоба.

Не бывает модификации блоба, сам знаешь.
Чего-то я тебя тут вообще не понял

hvlad · Сообщение **hvlad** » 15 май 2007, 13:37

ivl писал(а):
А что, есть какой-то "конец" у оператора SELECT, кроме окончания транзакции? Если бы после "окончания оператора" всё прибивалось - ты б данные из него считать не смог, не правда ли?
Конец у оператора есть. На сколько я помню, "курсоры" в Firebird НЕ двунаправленные, т. е. при выборке (FETCH) записи на клиента, место занимаемое ей ранее можно смело освобождать сразу, так как вернуться к ней назад нет никакой возможности. Или я неправ?

Нет, не прав.
Ты так и не понял как работают блобы.
Сервер в SELECT'е тебе возвращает blob_id временных блобов, которые создала твоя UDF
Далее ты можешь эти blob_id присвоить каким-либо полям таблицы (любой) - в этом случае блобы перестанут считаться временными.
А можешь ничего с ними не делать - тогда они умрут с окончанием тр-ции.
Но до окончания тр-ции сервер не имеет права ничего делать с этими блобами.
Теперь понятно ?

Для чего ты вычитываешь на клиента всю таблицу ???
Ладно, не умеешь по-другому, - читай. Вырастет она до десятка тыщ записей сам начнёшь головой думать об этом

Но поля с блобами-то зачем читать ? У тебя каждый новый блоб зависит от всех старых ???

ivl · Сообщение **ivl** » 15 май 2007, 16:51

Нет, не прав.
Ты так и не понял как работают блобы.
Сервер в SELECT'е тебе возвращает blob_id временных блобов, которые создала твоя UDF
Далее ты можешь эти blob_id присвоить каким-либо полям таблицы (любой) - в этом случае блобы перестанут считаться временными.

Да, теперь я понял. Хорошо. А если у таблицы в параметрах будет стоять read, то по окончании выборки (не транзакции) память тоже не может повторно использоваться? А если база в состоянии Read Only? Где тогда создаются временные блоб?

Для чего ты вычитываешь на клиента всю таблицу ???
Ладно, не умеешь по-другому, - читай. Вырастет она до десятка тыщ записей сам начнёшь головой думать об этом

На самом деле в таблицах хранится на два порядка больше данных. Просто в выборке необходимо вычитывать приблизительно 150 записей
(разумеется с блобами). Поэтому в тестовом примере я занес в базу именно 200 записей и всю прочитал, просто для демонстрации эффекта.

hvlad · Сообщение **hvlad** » 15 май 2007, 20:08

ivl писал(а):
Нет, не прав.
Ты так и не понял как работают блобы.
Сервер в SELECT'е тебе возвращает blob_id временных блобов, которые создала твоя UDF
Далее ты можешь эти blob_id присвоить каким-либо полям таблицы (любой) - в этом случае блобы перестанут считаться временными.
Да, теперь я понял. Хорошо. А если у таблицы в параметрах будет стоять read, то по окончании выборки (не транзакции) память тоже не может повторно использоваться? А если база в состоянии Read Only? Где тогда создаются временные блоб?

У таблицы нет параметров.
Временные блобы не относятся ни к какой таблице
В рид-онли БД твой фокус не пройдёт, ибо ты создаёшь в ней новые объекты

ivl писал(а):
Для чего ты вычитываешь на клиента всю таблицу ???
Ладно, не умеешь по-другому, - читай. Вырастет она до десятка тыщ записей сам начнёшь головой думать об этом
На самом деле в таблицах хранится на два порядка больше данных. Просто в выборке необходимо вычитывать приблизительно 150 записей
(разумеется с блобами). Поэтому в тестовом примере я занес в базу именно 200 записей и всю прочитал, просто для демонстрации эффекта.

Нет, ты демонстрировал другой эффект.

ivl · Сообщение **ivl** » 15 май 2007, 21:06

У таблицы нет параметров.

Это я описался. Имелась в виду не таблица, а транзакция. Транзакция только для чтения.

Код: Выделить всё

Нет, ты демонстрировал другой эффект.

Я демонстрировал рост базы. А чтение из таблицы 200 раз, по разу после каждой вставки или в другой последовательности не так для меня важен.

Вообщем спасибо всем за помощь. Жаль только, что в Firebird нельзя задать отдельный файл для хранения временной информации.
Но может блоб фильтры как-нибудь развиваться будут в будущем, тогда на них перееду, а так придется выкручиваться.

hvlad · Сообщение **hvlad** » 15 май 2007, 21:40

ivl писал(а):Жаль только, что в Firebird нельзя задать отдельный файл для хранения временной информации.
Но может блоб фильтры как-нибудь развиваться будут в будущем, тогда на них перееду, а так придется выкручиваться.

Какая разница что раздувать ?
Не вижу, чем тебя не устраивают блоб фильтры
Как правило, когда заходит речь про "придется выкручиваться", ищут в консерватории. В собственной

ivl · Сообщение **ivl** » 15 май 2007, 21:54

Не вижу, чем тебя не устраивают блоб фильтры

Что не устраивает? Вообщем механизм использования.
Я уже когда-то расспрашивал про них здесь.
Вот линк http://forum.ibase.ru/phpBB2/viewtopic.php?t=2196

hvlad · Сообщение **hvlad** » 15 май 2007, 22:43

Что-то в течение года не появилось соответствующего запроса в трекере...

ivl · Сообщение **ivl** » 15 май 2007, 23:06

Что-то в течение года не появилось соответствующего запроса в трекере...

Киньте ссылку куда писать. Я туда помимо этого еще три или четыре напишу. Очень хотелось бы, например, чтобы в Firebird операторные (выполняющиеся один раз для оператора UPDATE и т.п.) триггеры появились...

Сообщение **kdv** » 15 май 2007, 23:38

интересно, какую экономию тебе дает упаковка блобов. и какие препятствия ты видишь в упаковке-распаковке этих блобов в приложении (клиенте).
Это я к тому, что выбранный тобой метод опасен в смысле "лишнее чтение приводит к увеличению занимаемого пространства". Т.е. возникает эффект, обратный тому, которого ты добиваешься.

hvlad · Сообщение **hvlad** » 16 май 2007, 00:04

ivl писал(а):
Что-то в течение года не появилось соответствующего запроса в трекере...
Киньте ссылку куда писать. Я туда помимо этого еще три или четыре напишу. Очень хотелось бы, например, чтобы в Firebird операторные (выполняющиеся один раз для оператора UPDATE и т.п.) триггеры появились...

http://tracker.firebirdsql.org/

ivl · Сообщение **ivl** » 16 май 2007, 01:08

интересно, какую экономию тебе дает упаковка блобов. и какие препятствия ты видишь в упаковке-распаковке этих блобов в приложении (клиенте).
Это я к тому, что выбранный тобой метод опасен в смысле "лишнее чтение приводит к увеличению занимаемого пространства". Т.е. возникает эффект, обратный тому, которого ты добиваешься.

Я не говорил об упаковке. Но да, она там есть. Вообщем мне нужно криптование данных. А перед криптованием рекомендуется обычно повышать их энтропию путем упаковки. И место это занимает тогда меньше. Да, этот обратный эффект я не предполагал.
Препятствия паковать в клиенте? Они есть. Скорее организационные чем технологические. Вообщем вот они: 1. Нарушение идеологии клиет-сервер, когда обработка выносится только на сервер, а клиент её не делает. Упаковка на сервере позволяет не заботиться на чем написан клиент, толстый он или тонкий. 2. В моем случае у базы данных клиентов несколько. Пишутся они разными людьми. Проще производить подобную обработку прозрачно для клиента, чтобы никто не забивал себе голову ненужной информацией и действиями, а я чтобы правильно паковали-распаковывали. 3. Если с разжатой информацией необходимо произвести какие либо действия без передачи самой информации на клиент, то удобнее её не гонять, а распаковать и обработать на сервере. Клиент получит только резутьтат.
Теперь вижу, что не всё из того, что я хотел можно сделать теми методами, которыми предполагал.
Что кается самой базы, то она работает в двух режимах: сначала она только набивается, а потом из неё делают в основном выборки. Для меня не составляет труда сделать бэкап-рэсторэ, но хотелось бы чтобы она работала с минимальным администрирование или вовсе без него в условиях ограниченного дискового пространства. Поэтому сильное распухание меня не устраивает.
Вот и всё.

Сообщение **kdv** » 16 май 2007, 01:32

Нарушение идеологии клиет-сервер, когда обработка выносится только на сервер, а клиент её не делает.

с идеологией поосторожнее. клиент-серверу не важно, где происходит обработка. Есть два крайних случая - когда все обрабатывается на сервере, и когда даже FK обрабатываются на клиенте. Клиент в последнем случае, например, middleware-сервер. При этом клиент сервер никуда не исчезает, в обоих случаях. Так что...

Упаковка на сервере позволяет не заботиться на чем написан клиент, толстый он или тонкий.

это понятно.

Пишутся они разными людьми.

такие вопросы решаются организационно.

чтобы она работала с минимальным администрирование или вовсе без него в условиях ограниченного дискового пространства.

без резервных копий не получится. одно движение корявым пальцем клиента, и база тю-тю. впрочем, и бэкап может тю-тю, но это меньшее из двух зол.

Поэтому сильное распухание меня не устраивает.

нет в жизни счастья.

hvlad · Сообщение **hvlad** » 16 май 2007, 02:00

ivl писал(а):хотелось бы чтобы она работала с минимальным администрирование или вовсе без него в условиях ограниченного дискового пространства.

И какая разница что будет пухнуть - база или темп ?

ivl писал(а):Поэтому сильное распухание меня не устраивает.

Она 'пухнет' ровно на то кол-во блобов, которое ты создаёшь при чтении таблицы. Если каждое чтение в отдельной тр-ции затрагивает 200 блобов (а не так, как в примере), то она один раз 'распухнет' на 200 блобов и всё.

И я не верю, что все эти 200 блобов тебе нужны на клиенте одновременно.