Всем доброго дня,

возникла задача импорта больших текстовых файлов с последующим разбором их содержимого по другим таблицам. Поскольку при импорте информация берётся из разных частей файлов и т.к. файлы очень большие возникла идея сначала зачитывать их во временные таблицы а потом уже разбирать и импортировать в целевые таблицы (разбирать их в памяти 32битного приложения просто нехватит памяти в 2 Гб). Поскольку после импорта эти данные не нужны хотелось бы эти временные таблицы потом удалять так что бы не оставлять в базе мусор.
Соотв. начал искать информацию по использованию временных таблиц в FB 2.5.9 и в перспективе в 3й версии.
Нашел что согласно документации при создании временных таблиц (мне по видимому нужно уровня соединения) надо использовать "GLOBAL TEMPORARY" и "COMMIT PRESERVE ROWS".
Далее возник вопрос - после того как таблица автоматически удаляется остаётся ли мусор в базе и до какого момента этот мусор будет существовать? Например будет ли он удаляться только при восстановлении из резервной копии или его можно собрать другим способом.
Хотелось бы ещё услышать что то о подводных камнях которые могут ждать при использовании временных таблиц с большим объёмом данных, на что стоит обратить внимание и где "подстелить соломки".
Где можно подробнее почитать о теме временных таблиц кроме документации (её сейчас активно штудирую на эту тему но информаци в ней не так много).

Спасибо за любые советы и информацию.

Дегтярев Евгений,

Datanorm

формат заточенный на обмена товарными артиклями, их группами, ценами на них и скидками.
Целиком зачитывать надо потому что всё в одном файле и понятно что зачитывать, становится только когда всё или проиндексировано или торчит в памяти (т.е. надо многократно позиционироваться в разные части файла). Предведущая версия софта что это делает (написанная ещё в 2005м) наткнулась на проблемы с памятью при импорте больших файлов в этом году. Начиная примерно от 10 млн строк софт вываливается примерно на 80% зачитывания данных с "Out of memory". Можно конечно вынести импорт в отдельное приложение и скомпилироватрь его как x64, но гарантии что файлы не будут расти дальше нет. Опять же, в приложении задействовано куча модулей используемых в основной 32х битной программе и все их вычленить и тоже перекомпилить под х64 проблематично.

не получится, не от нас зависит. Стандарт принят за основу кучей поставщиков и только в нём они присылают данные.

примерно так предведущий коллега и пробовал поступить. Использовал допиленный TbufferedFileStream в сочетании с индексами в памяти в которых и хранилась нужная информация для позиционирования в этом файле в последствии. И как раз этот индекс и вызывал переполнение в последствии. Т.к. Файлов может импортироваться за раз несколько, причём надо между ними прыгать итп. Там достаточно замороченная логика где неудобство формата сталкивается с логикой самого приложания. В эту часть мне ещё надо вникать самому. Сейчас надо определиться с архитектурой пока.

с десятками миллионов строк. У крупных поставщиков огромное количество артиклей, которые тоже разбиваются на различные варианты одного и того же артикля (сочетание цвет, состав, итп).

Могли бы Вы привести пример такой "понятности что зачитывать"?
И в чём проблемы с позиционированием в файле?

да, выше уже написал, что в память не лезет уже сам индекх позволяющий позиционироваться в этих файлах.
тут накладываеся ещё софт в котором это всё запускается, который тоже хорошо кушает память. Хорошое решение было бы просто выделить импорт в отдельное x64 приложене но это практически невозможно. Слишком много связей с другими х32 модулями а у тех с третьими. Софту уже больше 25 лет, для интерфейса одних только самописных фреймворков внутри использовано более трёх. Короче проще переписать нежели выделить и в х64 перекомпилить.

обычный файл с разделителями, каждая срока имеет свой тип, количество полей итп со всякой вложенностью итп немного напоминает IDE но попроще тогоже PRICAT

спасибо, тогда примерно понятна логика работы FB со временными таблицами. С FIREBIRD_TMP проблема не большая, софт имеет инсталлятор который может её создать.

"Не верю!" (с)
Каков размер ключа и в какую структуру этот индекс складывается?

hlopotunобычный файл с разделителями, каждая срока имеет свой тип, количество полей итп со всякой
вложенностью итп немного напоминает IDE но попроще тогоже PRICAT

Так прыгать-то зачем? Импортируй во временные таблицы сразу по мере чтения.


Размер самого ключа не мерял, мерял использование памяти всей программой в процессе импорта этой процедурой:


до момента получения сообщения "Out of memory". Ключ составной, пихается в разные свойства одного из обьектов, которые в свою очередь являются массивами объектов. В итоге это приводит к тому что если грубо то объём используемой памяти на одну запись увеличивается в 2-3 раза в сравнеии с размером самой записи в файле.
В ключ пихается много чего, потом проводится пересорторовка данных итп. Сначала думал где утечки памяти есть, но проверил в процессе импорта этой процедурой через FastMM:


и утечек не обнаружил.
Код большой и сложный, яркий пример того как ненадо делать такой импорт. По сути автор попробовал реализовать свою базу с индексом и частично данными в памяти где всё парсит и потом запихивает всё в базу которая в одних версиях ещё парадоксовая а в других firebird. Собственно отсюда и все проблемы. Но код работает на файлах приемлемого размера (до 600 Мб примерно). По любому прийдётся всё переписывать. От парадокса скорее всего уже отказываться (лишний аргумент клиентам переходить на новую версию).
И да, пихать сразу всё во временные таблицы и от туда уже раскидывать дальше.

инсталляция и ведётся на сервере.

спасибо огромное! проверю.

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