|
|
|
жпа, батч импорт данных в таблицу.
|
|||
|---|---|---|---|
|
#18+
Собссно проблема, надо достаточно большой объем через жпа-хибер заимпортить. сущность довольно простая - десяток полей и всё. ну сделал по простому - каждый раз открывая закрывая сессию - вышло Х времени. долго. сделал так - открыл сессию - сохранил все записи, закрыл сессию - вышло X/2.5 времени. что тоже довольно долго. Почитал про батчи, сделал как написано - ускорилось незначительно. что еще можно сделать? многопоточку? не совсем вариант. начнутся проблемы при импорте связных данных. к тому же пробовал - не особо. одно условие - голый скл и ждбс пользовать нельзя. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.05.2017, 09:58 |
|
||
|
жпа, батч импорт данных в таблицу.
|
|||
|---|---|---|---|
|
#18+
natanabrahamjr, конкретнее - время\лог INSERT и размер слова "большой" Возможно ты упёрся и теперь либо ближе к драйверу (JDBC)? либо тюнинг базы (выкл журналирования) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.05.2017, 10:03 |
|
||
|
жпа, батч импорт данных в таблицу.
|
|||
|---|---|---|---|
|
#18+
У Хибера есть StatelessSession, но в JPA такой фичи, вроде, нет. автор одно условие - голый скл и ждбс пользовать нельзя. Ну, JDBC нафиг не нужен. SQL можно и из JPA запускать. А вот почему вы этого не хотите, вопрос открытый. Если это новые записи, то их в кеше всё равно ещё нет. Если вы хотите чтобы они после импорта сразу в кэш попали, то, поланаю, можно это сделать и насильно. Попробуйте NativeQuery - даёт ли прирост к производительности? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.05.2017, 10:08 |
|
||
|
жпа, батч импорт данных в таблицу.
|
|||
|---|---|---|---|
|
#18+
а можно подробнее касательно стейтлесс сессии? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.05.2017, 10:28 |
|
||
|
жпа, батч импорт данных в таблицу.
|
|||
|---|---|---|---|
|
#18+
по ждбс и скл собссно это желание заказчика чтоб скл не было ни в каком виде нигде. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.05.2017, 10:29 |
|
||
|
жпа, батч импорт данных в таблицу.
|
|||
|---|---|---|---|
|
#18+
natanabrahamjrПочитал про батчи, сделал как написано - ускорилось незначительнос этого места по подробнее, если можно (: ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.05.2017, 10:38 |
|
||
|
жпа, батч импорт данных в таблицу.
|
|||
|---|---|---|---|
|
#18+
natanabrahamjrа можно подробнее касательно стейтлесс сессии? https://docs.jboss.org/hibernate/orm/5.2/userguide/html_single/chapters/batch/Batching.html ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.05.2017, 10:39 |
|
||
|
жпа, батч импорт данных в таблицу.
|
|||
|---|---|---|---|
|
#18+
natanabrahamjr, вот ещё https://stackoverflow.com/questions/14174271/using-statelesssession-for-batch-processing и приводите конкретику. Если всё сделали правильно, то вы технологию используете не по назначению (выстрел в ногу заказчика) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.05.2017, 11:02 |
|
||
|
жпа, батч импорт данных в таблицу.
|
|||
|---|---|---|---|
|
#18+
natanabrahamjr, При массовом обмене данными большого объёма с СУБД (загрузка/выгрузка) рекомендую использовать только JDBC. Быстрее чем JDBC в данном случае никакой Hibernate не настроите. Особенно когда время на загрузку/выгрузку ограничено. Иногда для удобства можно разбавить SpringJDBC или Apache DbUtils. Поверьте... я на этом собаку съел. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.05.2017, 13:03 |
|
||
|
жпа, батч импорт данных в таблицу.
|
|||
|---|---|---|---|
|
#18+
GarrickПри массовом обмене данными большого объёма с СУБД (загрузка/выгрузка) рекомендую использовать только JDBC. Быстрее чем JDBC в данном случае никакой Hibernate не настроите. Особенно когда время на загрузку/выгрузку ограничено. Иногда для удобства можно разбавить SpringJDBC или Apache DbUtils. Поверьте... я на этом собаку съел. Не лучше ли тогда воспользоваться инутраментами самой БД? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.05.2017, 13:15 |
|
||
|
жпа, батч импорт данных в таблицу.
|
|||
|---|---|---|---|
|
#18+
Blazkowicz, Лучше, но не всегда возможно. То прямого доступа к серверу нет, то форматы входных/выходных данных какие-то не удобоваримые для штатных тулзов и т.п., разные случаи бывают. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.05.2017, 13:28 |
|
||
|
жпа, батч импорт данных в таблицу.
|
|||
|---|---|---|---|
|
#18+
UsmannatanabrahamjrПочитал про батчи, сделал как написано - ускорилось незначительнос этого места по подробнее, если можно (: https://vladmihalcea.com/2016/09/27/how-to-customize-the-jdbc-batch-size-for-each-persistence-context-with-hibernate/ один из вариантов. как здесь. другой вариант напрямую батч сайз задавать в апп.конфиге. ватевер короче, в стате вижу батчи, в логах вижу батчи, на производительности это сказывается в районе 10%. я то ожидал что раза в 2 будет быстрее. Тулза была вообще написано забавно - для записи каждой строчки открывали закрывали сессию - эт опервое, что я убрал - производительность возросла в 2.5 раза. идем дальше - привинтил батчи - производительность возрасла в 2.7 раза. )) это я еще игрался с размерами батча и т.п. В общем, боль. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.05.2017, 15:39 |
|
||
|
жпа, батч импорт данных в таблицу.
|
|||
|---|---|---|---|
|
#18+
Garricknatanabrahamjr, При массовом обмене данными большого объёма с СУБД (загрузка/выгрузка) рекомендую использовать только JDBC. Быстрее чем JDBC в данном случае никакой Hibernate не настроите. Особенно когда время на загрузку/выгрузку ограничено. Иногда для удобства можно разбавить SpringJDBC или Apache DbUtils. Поверьте... я на этом собаку съел. да я то понимаю.. хотя не очень понимаю. как например, это будет эффективнее, если и хибер и голый ждбс генерят одинаковое число запросов и к тому же одинаковые по виду и форме? Сейчас идет речь об импорте одной единственной табилцы (но большой) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.05.2017, 15:42 |
|
||
|
жпа, батч импорт данных в таблицу.
|
|||
|---|---|---|---|
|
#18+
Как минимум было бы хорошо сказать, какая СУБД ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.05.2017, 15:46 |
|
||
|
жпа, батч импорт данных в таблицу.
|
|||
|---|---|---|---|
|
#18+
natanabrahamjr, ключи в базе FK могут тормозить. natanabrahamjrда я то понимаю.. хотя не очень понимаю. как например, это будет эффективнее, запустите вне Java цикл for и будет видно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.05.2017, 15:54 |
|
||
|
жпа, батч импорт данных в таблицу.
|
|||
|---|---|---|---|
|
#18+
постгрес. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.05.2017, 16:28 |
|
||
|
жпа, батч импорт данных в таблицу.
|
|||
|---|---|---|---|
|
#18+
а если так ? https://stackoverflow.com/questions/6958965/how-to-copy-a-data-from-file-to-postgresql-using-jdbc ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.05.2017, 17:18 |
|
||
|
жпа, батч импорт данных в таблицу.
|
|||
|---|---|---|---|
|
#18+
natanabrahamjrСейчас идет речь об импорте одной единственной табилцы (но большой) может "импорте в одну таблицу"? Что у вас на входе и откуда вход? Потом проверьте простой цикл вне Java. Скорее всего без Java будет тоже медленно. Отсюда проблема не в коде а в архитектуре. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.05.2017, 17:30 |
|
||
|
жпа, батч импорт данных в таблицу.
|
|||
|---|---|---|---|
|
#18+
какой еще архитектуре? задача тривиальная как топор. есть файл с данными его надо распарсить и положить в одну единственную таблицу.. я не понимаю просто что там тупо можно улучшить, кроме как используя стандартный (который я надеюсь есть) инструментарий для подобных задач. на сегодня у меня скорость импорта (на моей системе) - порядка 1200-1400 записей в секунду. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.05.2017, 18:02 |
|
||
|
жпа, батч импорт данных в таблицу.
|
|||
|---|---|---|---|
|
#18+
natanabrahamjrкакой еще архитектуре? задача тривиальная как топор. есть файл с данными его надо распарсить и положить в одну единственную таблицу.. я не понимаю просто что там тупо можно улучшить, кроме как используя стандартный (который я надеюсь есть) инструментарий для подобных задач. на сегодня у меня скорость импорта (на моей системе) - порядка 1200-1400 записей в секунду. Об этом и речь, что задача тривиальная как топор, а Вы какой то х#$%^й маетесь, что дескать не жить не быть, нужно хибер. Достаете из своего хибера нативное соединение с БД и фигачите один единственный вызов COPY FROM STDIN, по итогу на выходе объем кода минимальный, производительность максимальная. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.05.2017, 18:32 |
|
||
|
жпа, батч импорт данных в таблицу.
|
|||
|---|---|---|---|
|
#18+
natanabrahamjrкакой еще архитектуре? задача тривиальная как топор. есть файл с данными его надо распарсить и положить в одну единственную таблицу.. я не понимаю просто что там тупо можно улучшить, кроме как используя стандартный (который я надеюсь есть) инструментарий для подобных задач. на сегодня у меня скорость импорта (на моей системе) - порядка 1200-1400 записей в секунду. Суть в том что в данной задаче ORM - лишнее звено. Берем гвоздь, подходим к стенке и забиваем микроскопом. Так и у вас. Берем файл, зачем-то парсим, зачем-то складываем в объекты, зачем-то с помощью ORM сохраняем в единственную таблицу. Даже если файл какого-то экстравагантного формата, то намного проще и эффективнее перегнать его в удобоваримый формат и средствами БД импортировать. Хотя бы в тот же CSV файл. И никакого SQL - заказчик доволен. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.05.2017, 18:40 |
|
||
|
жпа, батч импорт данных в таблицу.
|
|||
|---|---|---|---|
|
#18+
natanabrahamjrкакой еще архитектуре? задача тривиальная как топор. есть файл с данными его надо распарсить и положить в одну единственную таблицу. я с вас фигею. Вы бы сразу сказали что у вас на входе - ФАЙЛ. Т.к. ОРМ и Хибер делают ИЗ СУБД Объекты-классы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.05.2017, 19:08 |
|
||
|
жпа, батч импорт данных в таблицу.
|
|||
|---|---|---|---|
|
#18+
natanabrahamjrна производительности это сказывается в районе 10%. я то ожидал что раза в 2 будет быстрее.Можно получить дополнительный прирост оптимизации, если периодически вызывать метод flush() . (см. Chapter 4. Batch Processing ) имхо ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.05.2017, 22:32 |
|
||
|
жпа, батч импорт данных в таблицу.
|
|||
|---|---|---|---|
|
#18+
Petro123natanabrahamjrкакой еще архитектуре? задача тривиальная как топор. есть файл с данными его надо распарсить и положить в одну единственную таблицу. я с вас фигею. Вы бы сразу сказали что у вас на входе - ФАЙЛ. Т.к. ОРМ и Хибер делают ИЗ СУБД Объекты-классы. на входе файл, непонятного формата и либа к нему, которая выдирает из него данные. на выходе приложенька, с хибером. посередине постгрес. копаюсь дальше -- оказывается файлов много )) и они между собой взаимосвязаны. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.05.2017, 12:37 |
|
||
|
жпа, батч импорт данных в таблицу.
|
|||
|---|---|---|---|
|
#18+
Usmannatanabrahamjrна производительности это сказывается в районе 10%. я то ожидал что раза в 2 будет быстрее.Можно получить дополнительный прирост оптимизации, если периодически вызывать метод flush() . (см. Chapter 4. Batch Processing ) имхо пробовал. пока самый быстрый прирост в скорости дает стейтлесс сейшн. внутри одной транзакции. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.05.2017, 12:46 |
|
||
|
|

start [/forum/topic.php?fid=59&msg=39460618&tid=2122893]: |
0ms |
get settings: |
10ms |
get forum list: |
11ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
33ms |
get topic data: |
7ms |
get forum data: |
1ms |
get page messages: |
35ms |
get tp. blocked users: |
1ms |
| others: | 245ms |
| total: | 347ms |

| 0 / 0 |
