Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Java Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 [4] 5   вперед  Ctrl      все
 Re: MySQL очень медленный  [new]
mayton
Member

Откуда: loopback
Сообщений: 46531
+ Еще все тоже самое только в каждой сессии (или транзакции не знаю как там)
сделай

SET autocommit=0;


и

SET autocommit=1;


Тоесть всего 4 эксперимента.
13 апр 20, 10:19    [22115210]     Ответить | Цитировать Сообщить модератору
 Re: MySQL очень медленный  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 4832
mayton,
conn = getConnection()
conn.setAutoCommit(false
13 апр 20, 10:33    [22115219]     Ответить | Цитировать Сообщить модератору
 Re: MySQL очень медленный  [new]
mayton
Member

Откуда: loopback
Сообщений: 46531
Да это как вариант. Если он будет грузить внешними утилитами из sql скрипта то будут разные способы.

JDBC - это будет не самый быстрый метод.
13 апр 20, 10:36    [22115220]     Ответить | Цитировать Сообщить модератору
 Re: MySQL очень медленный  [new]
Basil A. Sidorov
Member

Откуда:
Сообщений: 10171
mayton
JDBC - это будет не самый быстрый метод.
При autocommit - без разницы. Без autocommit, скорее всего, любой метод будет "достаточно быстро".
13 апр 20, 10:46    [22115230]     Ответить | Цитировать Сообщить модератору
 Re: MySQL очень медленный  [new]
Zzz79
Member

Откуда:
Сообщений: 168
mayton
Zzz79
пропущено...

Spring Batch очень обширен )
он дает шансы и новичкам( много фич из коробки)
но также много фич и для проф проектов

я вот смотрю наш батч код и тупо не выкупаю что там и где)

вот у меня щас простая проблема

я делаю сервис по загрузке справочников

мне по http прилетает csv я его забираю


по шедулеру два раза в день чекаю дериректорию - если есть парсю csv валидирую и пишу в бд

и вот в чем прикол( оно ни на что не влияет - просто интерес)

у меня на стенде этот сервис работает ок- тоесть шедулер спринговый запускаетсся и запускает джобы

а вот локально ничего не происходит- тоесть подходит время и ничего

ставишь над application @EnableSheduling - все работает локально

но как без анотации этой на стендах работает я не врублюсь

какая то магия спринг актуатора судя по всему

Если ты знаешь как упростить сложное приложение - это хорошо. Это уже синьорный подход.

С спринг-батч для тебя непонятен потому-что юзкейс очень простой.

Давай другой пример. Ты парсишь csv. Очень большой. Порядка 1 Терабайта. Это длинная транзакция.
Длинтся 12 часов. И 12 часов inserts идут в БД и в конце идет commit. Это риски.
БД может лопнуть. Или от сетевых инцедентов отключиться и откатиться назад. Значит надо предусмотреть
разбивку длинной задачи на порции. И делать коммиты чаще. Например по 100_000 строк. Пачка.

Поэтому этот длинный джоб разбивается на шаги (steps) и каждый шаг фиксирует своё состоянии в репозитарии.
(Поищи есть в SpringBatch поддержка этого).

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


сsv у меня мальнький- порядка 20 мб

суть то в чем у меня над процессами стоят @Sheduled (cron=${.......})
когда я сборку заливаю на стенд - щедулер отрабатывает

локально же задачи не запускается- тоесть анотация не отрабатывает

но если над Application.class поставить @EnableSheduling - будет работать локально

и вот теперь вопрос - что за магия врубает на стенде шедулеры без анотации @EnableSheduling

используется spring-boot-starter-actuator
13 апр 20, 11:01    [22115237]     Ответить | Цитировать Сообщить модератору
 Re: MySQL очень медленный  [new]
mayton
Member

Откуда: loopback
Сообщений: 46531
Zzz79
mayton
пропущено...

Если ты знаешь как упростить сложное приложение - это хорошо. Это уже синьорный подход.

С спринг-батч для тебя непонятен потому-что юзкейс очень простой.

Давай другой пример. Ты парсишь csv. Очень большой. Порядка 1 Терабайта. Это длинная транзакция.
Длинтся 12 часов. И 12 часов inserts идут в БД и в конце идет commit. Это риски.
БД может лопнуть. Или от сетевых инцедентов отключиться и откатиться назад. Значит надо предусмотреть
разбивку длинной задачи на порции. И делать коммиты чаще. Например по 100_000 строк. Пачка.

Поэтому этот длинный джоб разбивается на шаги (steps) и каждый шаг фиксирует своё состоянии в репозитарии.
(Поищи есть в SpringBatch поддержка этого).

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


сsv у меня мальнький- порядка 20 мб

суть то в чем у меня над процессами стоят @Sheduled (cron=${.......})
когда я сборку заливаю на стенд - щедулер отрабатывает

локально же задачи не запускается- тоесть анотация не отрабатывает

но если над Application.class поставить @EnableSheduling - будет работать локально

и вот теперь вопрос - что за магия врубает на стенде шедулеры без анотации @EnableSheduling

используется spring-boot-starter-actuator

На стенде Windows или Linux?

Твоё приложение standalone? Или деплоится в контейнер JBoss/WebSphere/GlassFish ?
13 апр 20, 11:06    [22115241]     Ответить | Цитировать Сообщить модератору
 Re: MySQL очень медленный  [new]
Zzz79
Member

Откуда:
Сообщений: 168
mayton

На стенде Windows или Linux?

Твоё приложение standalone? Или деплоится в контейнер JBoss/WebSphere/GlassFish ?

на стенде Linux
это спринг бут -соотвенственно embded tomcat
13 апр 20, 11:16    [22115247]     Ответить | Цитировать Сообщить модератору
 Re: MySQL очень медленный  [new]
mayton
Member

Откуда: loopback
Сообщений: 46531
Не знаю честно. У тебя есть в гитхабе макет этого?
13 апр 20, 11:17    [22115249]     Ответить | Цитировать Сообщить модератору
 Re: MySQL очень медленный  [new]
Zzz79
Member

Откуда:
Сообщений: 168
причем абсолютно все конфиги идентичны за исключением instanceId
что application.yml
что bootstrap.yml
но локально на ноуте- отработка шедулеров только если на мейн классе стоит @EnableSheduling

я уже голову сломал -почему так происходит,не дает покоя мне этот момент
13 апр 20, 11:18    [22115252]     Ответить | Цитировать Сообщить модератору
 Re: MySQL очень медленный  [new]
Zzz79
Member

Откуда:
Сообщений: 168
mayton
Не знаю честно. У тебя есть в гитхабе макет этого?


нет,это банк,у нас свой закрытый репозиторий
13 апр 20, 11:19    [22115253]     Ответить | Цитировать Сообщить модератору
 Re: MySQL очень медленный  [new]
вадя
Member

Откуда: Екатеринбург
Сообщений: 17735
для загрузки csv есть специальные инструменты, позволяющие напрямую загрузить в базу.
13 апр 20, 11:51    [22115272]     Ответить | Цитировать Сообщить модератору
 Re: MySQL очень медленный  [new]
mayton
Member

Откуда: loopback
Сообщений: 46531
Zzz79
mayton
Не знаю честно. У тебя есть в гитхабе макет этого?


нет,это банк,у нас свой закрытый репозиторий

Сделай в 5 строчек макет чтоб компилировался. Без ваших бизнесовых названий.
13 апр 20, 12:06    [22115286]     Ответить | Цитировать Сообщить модератору
 Re: MySQL очень медленный  [new]
Zzz79
Member

Откуда:
Сообщений: 168
mayton,
там не все так просто

вообщем перетестил кучу кейсов

вывод - при переходе с 2.0.5 спринг бута на 2.2.4 перестал работать шедулер
13 апр 20, 16:54    [22115514]     Ответить | Цитировать Сообщить модератору
 Re: MySQL очень медленный  [new]
mayton
Member

Откуда: loopback
Сообщений: 46531
Когда твой скедюлер бин поднимается он должен что-то записать в логи.
13 апр 20, 17:24    [22115530]     Ответить | Цитировать Сообщить модератору
 Re: MySQL очень медленный  [new]
Zzz79
Member

Откуда:
Сообщений: 168
mayton,да он и пишет

ворпос то не в логах,а то что с переходом на новый бут анотация @Sheduled перестала работать без @EnableSheduling
13 апр 20, 17:37    [22115534]     Ответить | Цитировать Сообщить модератору
 Re: MySQL очень медленный  [new]
mayton
Member

Откуда: loopback
Сообщений: 46531
Zzz79, так добавь.
13 апр 20, 19:38    [22115617]     Ответить | Цитировать Сообщить модератору
 Re: MySQL очень медленный  [new]
Zzz79
Member

Откуда:
Сообщений: 168
mayton,да это понятно)
я хочу разобраться в причние

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

тоесть я сижу в мск ввел 11 в базе 8
мне интересно есть ли способ чтобы все записи писались как положено чтобы их не надо было конвертировать
тоесть я сижу в мск записал в мск 11 и в базу тоже легло 11 а не 8 и потом чтобы можно было это 11 достать а не 8)

а кто то во владике в это время тоже записал 11 и чтобы в базу тоже легло 11 а не 3)
13 апр 20, 21:11    [22115650]     Ответить | Цитировать Сообщить модератору
 Re: MySQL очень медленный  [new]
Garrick
Member

Откуда: Москва
Сообщений: 2999
Zzz79

а кто то во владике в это время тоже записал 11 и чтобы в базу тоже легло 11 а не 3)

А когда кто-то во Владивостоке в 11:00 что-то внёс в базу, а в Москве кто-то в 10:00 как узнать кто из них был первый?
А если вам просто цифры хранить, то используйте цифровое поле, а не TIME.
13 апр 20, 21:28    [22115655]     Ответить | Цитировать Сообщить модератору
 Re: MySQL очень медленный  [new]
Zzz79
Member

Откуда:
Сообщений: 168
Garrick,
ну ты потдеврдил мое мнение- такие вещи нужно хранить без всяких тайм зон
13 апр 20, 21:53    [22115661]     Ответить | Цитировать Сообщить модератору
 Re: MySQL очень медленный  [new]
Zzz79
Member

Откуда:
Сообщений: 168
Garrick
Zzz79

а кто то во владике в это время тоже записал 11 и чтобы в базу тоже легло 11 а не 3)

А когда кто-то во Владивостоке в 11:00 что-то внёс в базу, а в Москве кто-то в 10:00 как узнать кто из них был первый?
А если вам просто цифры хранить, то используйте цифровое поле, а не TIME.

вообще нам не нужно знать кто был первым)
нужно в печатках потом правильно отображать время
я столкнулся с тем что мы в вводим 11 +3 в джесон - в базу пишет 8
на печатке выходит естественно 8
13 апр 20, 21:58    [22115663]     Ответить | Цитировать Сообщить модератору
 Re: MySQL очень медленный  [new]
забыл ник
Member

Откуда:
Сообщений: 3289
Zzz79
Garrick
пропущено...

А когда кто-то во Владивостоке в 11:00 что-то внёс в базу, а в Москве кто-то в 10:00 как узнать кто из них был первый?
А если вам просто цифры хранить, то используйте цифровое поле, а не TIME.

вообще нам не нужно знать кто был первым)
нужно в печатках потом правильно отображать время
я столкнулся с тем что мы в вводим 11 +3 в джесон - в базу пишет 8
на печатке выходит естественно 8

рукалицо.
13 апр 20, 22:01    [22115666]     Ответить | Цитировать Сообщить модератору
 Re: MySQL очень медленный  [new]
mayton
Member

Откуда: loopback
Сообщений: 46531
Zzz79
mayton,да это понятно)
я хочу разобраться в причние

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

тоесть я сижу в мск ввел 11 в базе 8
мне интересно есть ли способ чтобы все записи писались как положено чтобы их не надо было конвертировать
тоесть я сижу в мск записал в мск 11 и в базу тоже легло 11 а не 8 и потом чтобы можно было это 11 достать а не 8)

а кто то во владике в это время тоже записал 11 и чтобы в базу тоже легло 11 а не 3)

1) Надо смотреть какой тип данных времени у вас в таблице.
https://www.postgresql.org/docs/12/datatype-datetime.html

2) Надо смотреть как приложение настраивает свою локаль (язык страна часовой пояс)
Для java это тоже касается. И какой тип данных JDBC вы выбрали чтобы представлять дату.

Разумеется приложение должно фиксировать дату с учотом поясов чтобы правильно
сделать comparison.

Сообщение было отредактировано: 13 апр 20, 22:42
13 апр 20, 22:43    [22115683]     Ответить | Цитировать Сообщить модератору
 Re: MySQL очень медленный  [new]
Zzz79
Member

Откуда:
Сообщений: 168
забыл ник,
это не я делал уж извините ))
13 апр 20, 23:06    [22115690]     Ответить | Цитировать Сообщить модератору
 Re: MySQL очень медленный  [new]
Zzz79
Member

Откуда:
Сообщений: 168
mayton


Разумеется приложение должно фиксировать дату с учотом поясов чтобы правильно
сделать comparison.

зачем?
Эта дата используется лишь для распечатки документов на кредит)
типо дата подписи или что то в этом роде)
тоесть если клиент запросил кредит во владике -зачем мне в базу писать гринвич+ зона =чтобы потом обратно все жто дело преобразовывать,вместо того,чтобы записать время фактическое?
13 апр 20, 23:09    [22115694]     Ответить | Цитировать Сообщить модератору
 Re: MySQL очень медленный  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 4832
Zzz79,
Детский вопрос.
В аппСервер с клиента приходит 2013-02-25 18:25:10 +03
Хочешь обрезай, хочешь не обрезай.
14 апр 20, 07:36    [22115756]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 [4] 5   вперед  Ctrl      все
Все форумы / Java Ответить