Совет по многопоточности при работе с базами..

[kibsoft]

Есть примерно 58000 записей, я их через execBatch() забиваю в базу (СУБД ORACLE), на это уходит около 4 секунд..вопрос: если например запись в базу разбить на два потока, то можно ускорить запись? Хотя бы теоретически это возможно?

[BlackTass]

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

[sne]

а еще очень могут помочь транзакции + query::prepare(), заместо query::exec(), если конечно это все уже не используется.

[BRE]

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

[BlackTass]

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

Это уже надо тестировать. Фиг его знает что в оракле наворочено. Может там основное то время на коннект с сервером тратится.

[BRE]

Может там основное то время на коннект с сервером тратится.

Так а что тогда ускорят несколько потоков?

[break]

Терзают смутные сомнения что пока реально не требуется оптимизации именно кода пишущего в БД - лучше с потоками не эксперементировать.

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

Это конечно более актуально при вставке записей в разные таблицы, но все равно возможно.

[voronElf]

похожая ситуация была у меня, только не Oracl (к сожалению), а с sqlite я работал. Надо было больше 100 000 insert запросов сделать побыстрее, тратилось времени полчаса на это дело, разбил всю операцию на транзакции (по 500 запросов в каждой), процесс теперь успевает в 3 минуты. Я понимаю что способ очень некрасивый, но другого не нашел.

[sne]

Я понимаю что способ очень некрасивый, но другого не нашел.

Для SQLite можно асинхронный режим "PRAGMA synchronous = ON;" работы с хранилищем попробовать включить, вероятно результаты без транзакций и с транзакциями, при этом, будут примерно равны.

ЗЫ
Описка, "PRAGMA synchronous = OFF;" конечно же

[Tonal]

А смотреть что именно тормозит не пробовал?
Тормозить может (грубо):
1. Подготовка данных для заливки.
2. Передача данных на сервер.
3. Обработка сервером.
Разбивая заливку на 2 потока скорость какой именно части изменится?

[voronElf]

Для SQLite можно асинхронный режим "PRAGMA synchronous = ON;"

Да можно, это даст тот же эффект (не будет блокировки таблицы на каждом запросе)

PS: есть у меня подозрение, что Ораклу транзакции не сильно помогут, но надо тестить

[ритт]

http://www.linuxjournal.com/article/9602

[break]

Для SQLite можно асинхронный режим "PRAGMA synchronous = ON;"

Кстати в FB тоже такой режим есть Forced Write - при его выключении работа БД сильно ускорялась, в свое время как раз использовал для таких больших импортов...

[Amigo_sa]

похожая ситуация была у меня, только не Oracl (к сожалению), а с sqlite я работал. Надо было больше 100 000 insert запросов сделать побыстрее, тратилось времени полчаса на это дело, разбил всю операцию на транзакции (по 500 запросов в каждой), процесс теперь успевает в 3 минуты. Я понимаю что способ очень некрасивый, но другого не нашел.

Использовать транзакции - очень даже красивое решение
Разработчики сами предлагают такой путь.

[break]

Использовать транзакции - очень даже красивое решение

Это кстати позволит отменить изменения целого блока - если одна из записей не всавилась, правде в некоторых серверах для этого еще удобнее savepoints.