Появилась необходимость быстро загонять во временную таблицу (create global temporary table xxxx ...) порядка 100000 записей. Временная таблица состоит из одного столбца varchar(256). На моём компе стандартный вариант через prepare отрабатывает порядка 8 секунд на FB 2.5. Это медленно и надо ускорить хотя бы до одной секунды. Как это можно сделать? Могу перейти на более свежий вариант сервера, если вдруг там будет такая возможность.

PS: У PostgreSQL для этих целей есть команда "COPY" и API для быстрой заливки данных одним куском (PQputCopyData, PQputCopyEnd). Для тех же самых данных этот вариант отрабатывает около секунды. Есть ли что-нибудь подобное для Firebird?

Данные на клиенте. Думаю поковырять Batch API. Правда, везде пишут, что это фича FB4.0, а не 3.

Код простейший. Но я не уверен, что он о чём-то скажет, т.к. используется своя либа, которая работает с разными СУБД:

Имеется ввиду что-то типа такого:


?

Или даже проще



Я правильно понял идею?

Ускорилось до 1.3 сек. Правда, сервак на моём же компе с клиентом. Думаю, по сети будет помедленнее, но всё равно так гораздо лучше.

Кстати, какой размер не должны превышать выходные параметры в сумме: 32к или 64к?

mayton, у меня UTF8. Надо на 4 ещё умножить в случае с FB вроде как. Но это не точно.

PS: для PG на каждое строковое значение varchar(256) в случае с командой COPY на сервер с клиента уходит количество байт, равное длине реальной строки в кодировке UTF8 (+ 4 байта длины, но это не критично). А для для FB на каждое строковое значение varchar(256) уходит 256 x 4 = 1024 байта. Я правильно понимаю?

PPS: не совсем понятно что значит "попробовать ее обработать на другом уровне"

Всему своё время. Проверю ) И заодно сравню трафик к серверу у FB и PG при заполнении временной таблицы одними и теми же данными.

По скорости посмотреть не получается, т.к. пока некуда FB поставить. А вот что по трафику при заполнении временной таблицы 100'000 значениями:
Firebird 2.5 (запись блоками по 20): трафик к серверу - 5.5Мб, трафик от сервера - 3.3Мб
PostgreSQL (команда COPY, передача бинарного буфера) трафик к серверу - 1Мб, трафик от сервера - несколько килобайт

FB показал себя намного лучше в плане трафика чем я ожидал. Видимо при передаче на сервер применяется какое-то сжатие для varchar.

Скоро найду свободный сервак для FB и потестю скорость

PS: Кстати, откуда у FB берётся трафик от сервера в этом случае?

Dimitry Sibiryakov,

Эта временная таблица нужна для ORM, когда у него получается запрос с большим количеством условий. Например, чтобы не городить гигантский запрос с where xxx in (...), он загоняет эти значения во временную таблицу и джойнит её с таблицей в запросе. На самом деле таких временных таблиц много. Есть временные таблицы для разных типов данных. И их по 10 штук для каждого типа данных на всякий случай.

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

Шавлюк Евгений,

Не совсем понял. Таблица же временная. Заполнили, выполнили запрос, а при коммите она автоматом очистилась. Зачем там ещё "идентификатор сессии"?

Шавлюк Евгений,

У меня нету необходимости в "запрос выполнить в соседних окнах. И затем сравнить" ))

Я не понимаю какую тебе постановку надо. И этот антипатер я не делаю. Он давно уже сделан и работает.
Есть сервак с 3хзвенкой. На нём крутиться наш сервис. Сервис в качестве СУБД по желанию клиента может использовать разные СУБД, в том числе FB. Чаще всего с FB он и используется. Сервак многофункциональный. В том числе для него есть API, чтобы получать данные.
И данные, получаемые от сервиса, и условия запросов могут быть совершенно произвольными (но в рамках объектов ORM). Например: я хочу получить фамилии работников, которые обрабатывали материл по контролю за разработкой со скважин таких-то месторождений, в период такой-то. Или: выдай мне 3-мерные координаты пересечений пласта АС4 со стволами скважин, список скважин такой-то. Или: нужны результаты интерпретации скважин, в частности пористость, список скважин такой-то, список названий методов исследования такой-то ну и плюс дофига всяких вариантов, которые только можно напридумывать. Основной клиент, который пользуется этим сервисом - ещё одна система, которая у меня в организации и разрабатывается.
Причём ни одно значение в эту базу не вбивается вручную. Все данные попадают туда путём индексирования файлов-результатов работы большого количества работников. Этим индексированием тоже занимается наш сервис, который знает как парсить исходные файлы и как распихивать эту инфу по базе.
Просто недавно выяснилось, что количество параметров условий в запросе может быть очень большим (например при просмотре пользователями карты скважин больших месторождений). Из-за этого и был написан пост.

Так какие у тебя идеи как победить этот "антипатерн"? ))

Могут быть привязаны, могут быть не привязаны, могут быть привязаны хитрым образом. Всё зависит от того, как это было проиндексировано. Это не особо важно. Важно то, что прога, которая показывает карту (и которая частично для отображения карты использует наш сервис), просто запрашивает данные по куче скважин по их уникальному идентификатору, присвоенному нефтяной компанией. И не обязательно это будут скважины одного месторождения. Вроде как возможен вариант, когда на экране будут скважины с разных месторождений, если они умещаются на экране. Я сам не спец по этим картам, отвечаю только за работу с СУБД, индексирование и сетевой протокол для сервиса.

Dimitry Sibiryakov,

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

mayton,

Основной таблицы нету. Временная таблица может джойниться с любой таблицей из запроса, генерённого ORM, если по ней есть много условий. Мало того, может быть ситуация, когда используется дофига временных таблиц. Они заполняются и джойняться с разными таблицами из 100-этажного запроса. Тут как повезёт.

С этим я согласен на 146 процентов.


А вот с этим не согласен. На то они и временные таблицы, чтобы их заполнять данными и извращаться ради того, чтобы получить то, что тебе нужно ))


А вот это я совсем не понял. Что за динамические справочники и как они могут помочь.

mayton, ты лучше суть объясни того, что сказать хотел. А временные таблицы для строк конкретно под FB в моём случае создаются запросами типа

mayton,

Ты ничего не понял. Параллельно в разных транзакциях могут заполняться и использоваться и одни и те же временные таблицы. Например:
1-я транзакция использует TMP_S_0
2-я транзакция использует TMP_S_0, TMP_S_1, TMP_S_2, TMP_S_3, TMP_S_4, TMP_S_5 + временные таблицы для других типов данных
3-я транзакция использует TMP_S_0, TMP_S_1
4-й транзакции повезло, т.к. условий в запросе к сервису мало и все они влезли в текст SQL
5-я ... и т.д.

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

Я же всё подробно изложил уже. Несколько раз. С клиента.

Dimitry Sibiryakov,

Была такая идея. Но есть ещё и ограничение на размер текста SQL. Его легко преодолеть даже группируя по 1000 значений в in.

ЗЫ: Наконец-то дошли руки померить скорость заполнения временной таблицы по сети 100'000-ю значений. Сетка гигабитная. Сервак в том же сегменте что и мой рабочий комп. Вот результаты:

Firebird (блочная вставка по 20): 6.6 секунды на заполнение и практически мгновенное выполнение запроса после
PostgreSQL (COPY + передача бинарного буфера): 1.4 сек на заполнение и 0.7 сек на выполнение запроса после

Данные и там и там абсолютно одинаковые. Правда, Firebird был уже на серваке, но версии 3.0. Я 2.5 не стал ставить. Потестил на том что было.

Чаще всего Firebird стоит на том же серваке, где крутится наша служба. В этом случае FB не только не отстаёт от PG но и даже работает быстрее (время заполнения временной таблицы и выполнения запроса близко к 1.4 сек), что меня устраивает. Всем спасибо кто посоветовал блочную вставку! ))

Включил WireCompression. Среднее время заполнения таблицы упало до 6.5 сек. Но сервак стоит на виртуалке. В параллель там много чего крутиться, так что это уменьшение времени в пределах погрешности ))

Немного перехвалил Firebird )) На самом деле запрос после заполнения выполняется не почти мгновенно, а ~0.7 сек, как и у PG.