Новые сообщения [новые:0]
Дайджест
Горячие темы
Избранное [новые:0]
Форумы
Пользователи
Статистика
Статистика нагрузки
Мод. лог
Поиск
|
08.09.2021, 16:26
|
|||
---|---|---|---|
Асинхронное сохранение данных при связи ManyToMany |
|||
#18+
Здравствуйте, собственно сабж что делаю: сущность Tag Код: java 1. 2.
сущность Book Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18.
будет естественно работать вот так: Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13.
и собственно вопрос если для каждого энтити разные удаленные источники как можно асинхронно получить и записать эти данные? знаю что транзакция и асинк вместе не будет работать и к тому же нельзя изменить объект асинхронно... в моем случае мне достаточна сохранить книгу и выдавать инфу, пусть теги асинхронно добавляются... З.Ы. возможно книги и теги не совсем удачный пример, но с юзером и адресом будет правильнее наверно, но суть не меняется )... ... |
|||
:
Нравится:
Не нравится:
|
|||
|
08.09.2021, 16:32
|
|||
---|---|---|---|
|
|||
Асинхронное сохранение данных при связи ManyToMany |
|||
#18+
Ты хочешь сохранить книгу в одном потоке (и в одной транзакции), а тэги сохранить в другом потоке (и другой транзакции)? Ну особых проблем не вижу, только книгу нужно будет сначала закоммитить, иначе tx#2 не увидит ее. ... |
|||
:
Нравится:
Не нравится:
|
|||
|
08.09.2021, 16:38
|
|||
---|---|---|---|
Асинхронное сохранение данных при связи ManyToMany |
|||
#18+
Stanislav Bashkyrtsev, в том то и дело что так нельзя т.к. тэг сохраняется с помощью книг... а когда двух потоках то в другом потоке тоже надо будет сохранить именно книгу а не тег... или что то я не правильно сказал? если сохранить просто тег то в промежуточной таблице не будет связи между книгой и тегом ... |
|||
:
Нравится:
Не нравится:
|
|||
|
08.09.2021, 17:10
|
|||
---|---|---|---|
|
|||
Асинхронное сохранение данных при связи ManyToMany |
|||
#18+
Музаффар Stanislav Bashkyrtsev, в том то и дело что так нельзя т.к. тэг сохраняется с помощью книг... а когда двух потоках то в другом потоке тоже надо будет сохранить именно книгу а не тег... или что то я не правильно сказал? если сохранить просто тег то в промежуточной таблице не будет связи между книгой и тегом Делай синхронно. :-) Можно конечно покапать в сторону чего-нибудь реактивного/корутинного. Но это сложнее. :-) ... |
|||
:
Нравится:
Не нравится:
|
|||
|
08.09.2021, 17:31
|
|||
---|---|---|---|
Асинхронное сохранение данных при связи ManyToMany |
|||
#18+
mad_nazgul, да делал бы так, но для увеличения скорости делал асинхронным, или сделать наоборот т.е. сделать основным не книгу а тегов? или вообще из ассоциативной таблицы сделать ещё один сущность... ... |
|||
:
Нравится:
Не нравится:
|
|||
|
08.09.2021, 17:57
|
|||
---|---|---|---|
|
|||
Асинхронное сохранение данных при связи ManyToMany |
|||
#18+
Музаффар Stanislav Bashkyrtsev, в том то и дело что так нельзя т.к. тэг сохраняется с помощью книг... а когда двух потоках то в другом потоке тоже надо будет сохранить именно книгу а не тег... или что то я не правильно сказал? если сохранить просто тег то в промежуточной таблице не будет связи между книгой и тегом Музаффарили сделать наоборот т.е. сделать основным не книгу а тегов? или вообще из ассоциативной таблицы сделать ещё один сущность...Можно и так. PS: Я не видел еще подобных ситуаций, чтоб сохранение сущностей было такое медленное, чтоб нужно было в async выносить.. ... |
|||
:
Нравится:
Не нравится:
|
|||
|
08.09.2021, 18:44
|
|||
---|---|---|---|
|
|||
Асинхронное сохранение данных при связи ManyToMany |
|||
#18+
AFAIK кроме синхронности/ассинхронности, есть еще такая вещь, как колличество коммитов на единицу записываемых данных ))) т.ч. можно сделать все ассинхронным, но скорость будет на порядки (десятки-сотни) раз медленней, чем синхронно но в одной транзакции. А если в одной транзакции еще и массово писать (например команда COPY), то смысла в ассинхронности записи в БД вообще может не быть, т.к. один клиент вполне будет способен сервер и диск сервера загрузить по самое нехочу (даже при хорошем сервере и хорошем серверном диске, сотню мегобайт с клиента чисто данных... не каждый сервер выдержит). ... |
|||
:
Нравится:
Не нравится:
|
|||
|
08.09.2021, 20:04
|
|||
---|---|---|---|
Асинхронное сохранение данных при связи ManyToMany |
|||
#18+
отвечу на вопрос зачем синхронность вообще: дело в том что данные берутся из удаленных сервисов, и если они загружены то ответ приходит чуть дольше иногда доходит до минуты... и когда все в одном потоке то придется ждать условно 1+ минут чтоб данные пришли и записались в бд ... |
|||
:
Нравится:
Не нравится:
|
|||
|
08.09.2021, 22:27
|
|||
---|---|---|---|
|
|||
Асинхронное сохранение данных при связи ManyToMany |
|||
#18+
Музаффар, Очень странное ТЗ. - можно собирать коллекцию в оперативке ПОКА ВСЕ ДАННЫЕ НЕ ПРИДУТ - можно собирать во временной таблице в бд. Тебе как лучше?))) ... |
|||
:
Нравится:
Не нравится:
|
|||
|
08.09.2021, 22:29
|
|||
---|---|---|---|
|
|||
Асинхронное сохранение данных при связи ManyToMany |
|||
#18+
Музаффар, СУБД не мусорка чтобы писать туда что попало. Например одну руку от человека. Или один палец. ... |
|||
:
Нравится:
Не нравится:
|
|||
|
09.09.2021, 05:15
|
|||
---|---|---|---|
Асинхронное сохранение данных при связи ManyToMany |
|||
#18+
PetroNotC Sharp Музаффар, Очень странное ТЗ. - можно собирать коллекцию в оперативке ПОКА ВСЕ ДАННЫЕ НЕ ПРИДУТ - можно собирать во временной таблице в бд. Тебе как лучше?))) 1. Согласен но это не даст мне то что надо, т.к. время ожидания останется прежним. 2. Это что даст? - знаю что СУБД не мусорка но к чему это? У меня сбор данных происходит из разных источников следовательно время на это уходит по разному чтоб уменьшить это мне нужно как то параллелить обработку данных, т.е. в момент ввода названии книги из одного источника придёт инфо об этой книги и там же из другого источника теги по этой книги. При этом пользователь не должен ждать сбора данных по тегам и их записи в бд ... |
|||
:
Нравится:
Не нравится:
|
|||
|
09.09.2021, 11:10
|
|||
---|---|---|---|
|
|||
Асинхронное сохранение данных при связи ManyToMany |
|||
#18+
Музаффар, Тебе нужно делать так как учат в ВУЗАХ, ПЕРВЫЙ ЭТАП это создание модели и выделение сущностей. Если в твоей ИС "Б" сущность книга, то пол книги это промежуточный этап и ненужно полкниги писать в субд. Нужно складировать в сессию и собирать всю книгу. Если наборот, в твоей "Б" важны "источники книги" то сущность уже не книга а куски книги с меткой источника. ID_ИСТОЧНИКА NAME DATETIME >При этом пользователь не должен ждать сбора данных по тегам и их записи в бд ≠Он в любом случае не ждет. Запись в бд занимает милли и макро секунды. А ответ сервиса" А" занимает минуту. Юзверь ждет сервис А а не твой сервис Б. ... |
|||
:
Нравится:
Не нравится:
|
|||
|
09.09.2021, 11:12
|
|||
---|---|---|---|
|
|||
Асинхронное сохранение данных при связи ManyToMany |
|||
#18+
Музаффар, Пора переходить к логам по времени и дать в топике цифры нагрузочных тестов. ... |
|||
:
Нравится:
Не нравится:
|
|||
|
09.09.2021, 13:28
|
|||
---|---|---|---|
Асинхронное сохранение данных при связи ManyToMany |
|||
#18+
БД не запрещает асинхронность и мультипоточку. Но в БД есть констрейнты которые определяют целостность объектов. И было-бы лучше чтобы эти констрейнты были максимально строгими по отношению в записываемому объекту. В противном случае у нас в БД будет мусор. Тоесть какие-то огрызки книг тегов и непонятно где логический конец. Возможно имеет смысл просто накапливать в памяти модель сложного объекта и записывать его когда он будет полностью сформирован. ... |
|||
:
Нравится:
Не нравится:
|
|||
|
09.09.2021, 14:50
|
|||
---|---|---|---|
|
|||
Асинхронное сохранение данных при связи ManyToMany |
|||
#18+
mayton , если мы получаем неполные данные и могли бы их уже показать пользователю не заставляя его ждать еще минуту, то тут других вариантов то и нет. И мы БД должны подстроить под наши требования, а не под высокие (но не достижимые) идеалы. ... |
|||
:
Нравится:
Не нравится:
|
|||
|
09.09.2021, 15:05
|
|||
---|---|---|---|
Асинхронное сохранение данных при связи ManyToMany |
|||
#18+
Тут жеж речь не об этом. Конечно отображайте пользователю данные сразу. Один виджет - тянет сведентя с одного датасорса. Второй с другого. И т.д. Всё асинхронно. Но тогда при чем здесь БД? Тем более что Музафар пишет что с некоторых сервисов данные приходистя ждать более минуты. Запишете в БД когда будет готов весь бизнес-объект. У вас же не возникает желания сохранять в базу формочку строка-за-строкой в той скорости как оператор из набирает. Верно? ... |
|||
:
Нравится:
Не нравится:
|
|||
|
09.09.2021, 15:37
|
|||
---|---|---|---|
|
|||
Асинхронное сохранение данных при связи ManyToMany |
|||
#18+
mayton Тут жеж речь не об этом. Конечно отображайте пользователю данные сразу. Один виджет - тянет сведентя с одного датасорса. Второй с другого. И т.д. Всё асинхронно. Но тогда при чем здесь БД? ... |
|||
:
Нравится:
Не нравится:
|
|||
|
09.09.2021, 15:52
|
|||
---|---|---|---|
Асинхронное сохранение данных при связи ManyToMany |
|||
#18+
Пускай автор скажет. Получается что мы тут сильно додумываем бизнес-сценарии. ... |
|||
:
Нравится:
Не нравится:
|
|||
|
09.09.2021, 17:16
|
|||
---|---|---|---|
|
|||
Асинхронное сохранение данных при связи ManyToMany |
|||
#18+
Stanislav Bashkyrtsev, Если речь про перформанс, подозреваю разговор идет о каком-то батч процессе или ETL. Мне даже кажется, что пару месяцев назад похожая тема уже всплывала. "Hibernate наше все" ( TM ) - т.ч. хождение по граблям может продолжатся долго. Наша песня хороша, начинай с начала. ... |
|||
:
Нравится:
Не нравится:
|
|||
|
09.09.2021, 19:55
|
|||
---|---|---|---|
|
|||
Асинхронное сохранение данных при связи ManyToMany |
|||
#18+
Stanislav Bashkyrtsev mayton Тут жеж речь не об этом. Конечно отображайте пользователю данные сразу. Один виджет - тянет сведентя с одного датасорса. Второй с другого. И т.д. Всё асинхронно. Но тогда при чем здесь БД? Это чисто вопрос ТС ... |
|||
:
Нравится:
Не нравится:
|
|||
|
09.09.2021, 20:44
|
|||
---|---|---|---|
|
|||
Асинхронное сохранение данных при связи ManyToMany |
|||
#18+
Музаффар отвечу на вопрос зачем синхронность вообще: дело в том что данные берутся из удаленных сервисов, и если они загружены то ответ приходит чуть дольше иногда доходит до минуты... и когда все в одном потоке то придется ждать условно 1+ минут чтоб данные пришли и записались в бд ИМХО стоит посмотреть в сторону чего-то типа RxJava . Для того чтобы "собирать" сущность. ... |
|||
:
Нравится:
Не нравится:
|
|||
|
10.09.2021, 07:35
|
|||
---|---|---|---|
Асинхронное сохранение данных при связи ManyToMany |
|||
#18+
Stanislav Bashkyrtsev, + ребят со всеми утверждениями согласен, вижу что разные мнения изза того что я не правильно задал вопрос походу... за это сорри в целом попробую конкретизировать задачу: есть таблицы/сущности: Юзер (где логин пароль и т.д.), Документ (где биометрические данные, фио, дата рождения и т.д.), адрес (ну и так понятно только тут как постоянный адрес так и временный) и другие таблицы. задача зарегистрировать пользователя в системе (входные данные: логин/пароль/табельный номер) система получив эти данные с помощью табельного номера идет по разным удаленным сервисам и собирает нужные инфа (для документа, и для адреса), как выше говорилось что удаленные серверы не всегда отвечают моментально. кстати чуть не забыл здесь самая главная сущность это документ, если есть документ то можем пойти и запросить из других источников и так кейс №1 сделаем в одном потоке: все круто все замечательно но есть одна проблема, время регистрации займет от 1.5 секунды до 1+минут (это изза того какой то сервис скажем адрес заставил ждать) и к тому же если это все происходит в одной транзакции возможен откат т.к. какой то удаленный сервис дал исключение... возможно? скорее да. кейс №2 попробовать параллелить сбор данных, получив входных данных идем по документу получив документ идем по другим удаленным сервисам только уже этих сервисов вызываем асинхронно тогда у нас сбор данных будет прозрачным отдельно от основного потока, таким образом мы будем ждать только одного сервиса (основного) для Документа... надеюсь смог объяснить суть. ... |
|||
:
Нравится:
Не нравится:
|
|||
|
10.09.2021, 07:51
|
|||
---|---|---|---|
|
|||
Асинхронное сохранение данных при связи ManyToMany |
|||
#18+
Музаффар , я такие проблемы решал след образом: 1. Сохраняем небольшой кусок данных который позволяет пользователю хоть сколько-то работать в системе. Коммит. 2. Тригерим жобу которая смотрит в БД и для всех у кого данные не проставлены - запрашивает эти данные. Если делать иначе, то есть риск что что-то в сервисе сломается (ну или просто наш сервер кто-то перезагрузит) и данные никогда не попадут в БД. А нам нужен механизм который попробует еще, а значит лучше ориентироваться на БД. Такая жоба может не только по требованию запускаться, но и по шедулеру. Хотя при насильном запуске можно все-таки явно указать про какие записи речь, иначе жоба может начать слать запросы для пользователей в другом порядке, а значит наш последний пользователь прождет не минуту, а 5. 3. В это время пользователь может таки успеть дойти до тех мест где эти данные требуются. Если такое произошло, то показываем пользователю спиннер, мол, "мы запрашиваем данные, жди". Как только данные пришли - спинер прячем, показываем то ради чего он сюда пришел. ... |
|||
:
Нравится:
Не нравится:
|
|||
|
10.09.2021, 08:25
|
|||
---|---|---|---|
Асинхронное сохранение данных при связи ManyToMany |
|||
#18+
Тут вопрос лежит в бизнес плоскости а не в технической. На что готов пойти бизнес чтобы дать пользователю начать работать с системой до полного сбора информации. Если очень надо, то да - создание временной записи и асинхронная джоба со всеми сопутствующими(обработка ошибок, откат транзакции, замена временной записи на постоянную). Судя по тому что тс задаёт такие вопросы он явно не искушен, так что вряд-ли представляет гемор вносимый асинхронностью в данном кейсе... ... |
|||
:
Нравится:
Не нравится:
|
|||
|
10.09.2021, 09:26
|
|||
---|---|---|---|
|
|||
Асинхронное сохранение данных при связи ManyToMany |
|||
#18+
Гемора не вижу. Но не понимаю, если данные хранятся в другой системе, зачем их тащить в основную? 1. Данные необходимы для авторизации. Попаболь не понятна, пока данные не собраны, корректно авторизовать в системе мы не можем. Пусть ждет или "система недоступна по техническим причинам". 2. Если таблицы в основной система эта кэш и данные при логине подкачиваются для "прогрева кэша". Тогда опять таки, кэш должен работать как кэш. Данные есть и более-менее актуальны - возвращаем из кэша, данных нет - запрашиваем в медленном хранилище, помещаем в кэш, возвращаем. Прогрев кэша: асинхронно (скорее всего в Java), дергаем get'еры которые данные из кэша возвращают и на результат просто забиваем нано-болт. Подкачка и сохранение данных, задача модуля реализующего кэширование, а никак не модуля авторизации 3. Данные нужны чисто для логирования. НО, логирование это необходимая часть процесса авторизации, т.ч. смотри п.1. Будут разборки службы безопасности, а логи пустые, фэкап. IMHO & AFAIK ... |
|||
:
Нравится:
Не нравится:
|
|||
|
|
start [/forum/topic.php?fid=59&mobile=1&tid=2120353]: |
0ms |
get settings: |
24ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
47ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
492ms |
get tp. blocked users: |
1ms |
others: | 423ms |
total: | 1022ms |
0 / 0 |