Ускорить процесс обновления данных в БД Postgres

@zuxa-zuxa · Регистрация: 15.02.2012

Студворк — интернет-сервис помощи студентам

Здравствуйте! Делаю вот так:

Java
1
2
3
4
5
6
7
8
9
10
11
12
13
updates.forEach((key, data) -> {
            executeWithTransaction(em -> {
                List<MyModel> resultList = em.createQuery(
                        SELECT_BY_KEY_QUERY, MyModel.class).setParameter("key", key)
                        .getResultList();
                if (resultList.isEmpty()) {
                    em.persist(new MyModel(key, data));
                } else {
                    aggregate(resultList.get(0).getData(), data);
                    em.merge(new MyModel(key, data));
                }
            });
        });

Суть - обновить данные в бд, тех которых нет - добавить, а которые есть - к ним применить aggregate и перезаписать.
Проблема: на 80тыс. updates - время всего этого выходит около 12 минут. Каждый апдейт в своей транзакции - дорого, однако зато безопасность, чтобы не потерять все данные из за 1 ошибки. Пробовал делать всё в 1 транзакции, чисто для теста, на 40% примерно быстрее, но безопасность данных важнее мне, могу только в 1 транзакции по 10 апдейтов обрабатывать. Но выйгрыш не большой выходит. Может быть будет быстрее это native query делать? Как заставить hibernate ускориться? Помогите пожалуйста. Data у меня - это json колонка, её размер в символах может превышать 150тыс символов.
В java она прописана у меня как:

Java
1
2
@Column(name = "data", nullable = false)
    @Type(type = "data-map")

Java
1
@TypeDefs({@TypeDef(name = "data-map", typeClass = DataMapJsonType.class)})

За ранее спасибо за любые идеи

@KEKCoGEN · 20.09.2018, 08:39

Сообщение от zuxa-zuxa

Каждый апдейт в своей транзакции - дорого, однако зато безопасность

безопасность тут каким боком?

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

@zuxa-zuxa · 20.09.2018, 09:24 **[ТС]**

KEKCoGEN, Вы предлагаете потратить 10 минут на заваливание транзакции, а потом частями тоже самое ещё раз делать? Ну это совсем не ускорит процесс, а мне ускорить бы.
Чисто в теории ошибки не больше 1шт на 100тыс. Я готов терять 10, ну даже 100 записей на 1 такую ошибку, так что вот пока наилучшее решение - 100 записей в одну транзакцию.
Я вот волнуюсь по поводу того, что я сначала делаю select, а потом update. 2 раза по большой таблице идти, может это лучше сделать одним запросом как то? Чтобы разок прошелся, увидел запись и обновил.

Новые блоги и статьи Все статьи Все блоги /
Валидация и контроль данных табличной части документа перед записью Maks 22.04.2026 Алгоритм из решения ниже реализован на примере нетипового документа, разработанного в КА2. Задача: контроль и валидация данных табличной части документа перед записью с учетом регламента компании. . .	Отчёт о затраченных материалах за определенный период с макетом печатной формы Maks 21.04.2026 Отчёт из решения ниже размещён в конфигурации КА2. Задача: разработка отчёта по затраченным материалам за определённый период, с возможностью вывода печатной формы отчёта с шапкой и подвалом. В. . .	Отчёт о спецтехнике находящейся в ремонте Maks 20.04.2026 Отчёт из решения ниже размещен в конфигурации КА2. Задача: отобразить спецтехнику, которая на данный момент находится в ремонте. Есть нетиповой документ "Заявка на ремонт спецтехники" который. . .	Памятка для бота и "визитка" для читателей "Semantic Universe Layer (Слой семантической вселенной)" Hrethgir 19.04.2026 Сгенерировано для краткого описания по случаю сборки и компиляции скелета серверного приложения. И пусть после этого скажут, что статьи сгенерированные AI - туфта и не интересно. И это не реклама -. . .
Запрет удаления строк ТЧ документа при определённом условии Maks 19.04.2026 Алгоритм из решения ниже реализован на примере нетипового документа "Аккумуляторы", разработанного в конфигурации КА2. У данного документа есть ТЧ, в которой в зависимости от прав доступа. . .	Модель заражения группы наркоманов alhaos 17.04.2026 Условия задачи сформулированы тут Суть: - Группа наркоманов из 10 человек. - Только один инфицирован ВИЧ. - Колются одной иглой. - Колются раз в день. - Колются последовательно через. . .	Мысли в слух. Про "навсегда". kumehtar 16.04.2026 Подумалось тут, что наверное очень глупо использовать во всяких своих установках понятие "навсегда". Это очень сильное понятие, и я только начинаю понимать край его смысла, не смотря на то что давно. . .	My Business CRM MaGz GoLd 16.04.2026 Всем привет, недавно возникла потребность создать CRM, для личных нужд. Собственно программа предоставляет из себя базу данных клиентов, в которой можно фиксировать звонки, стадии сделки, а также. . .

@zuxa-zuxa Мишка Косолапый :) 285 / 255 / 86 Регистрация: 15.02.2012 Сообщений: 1,511
	20.09.2018, 09:24 [ТС]
	KEKCoGEN, Вы предлагаете потратить 10 минут на заваливание транзакции, а потом частями тоже самое ещё раз делать? Ну это совсем не ускорит процесс, а мне ускорить бы. Чисто в теории ошибки не больше 1шт на 100тыс. Я готов терять 10, ну даже 100 записей на 1 такую ошибку, так что вот пока наилучшее решение - 100 записей в одну транзакцию. Я вот волнуюсь по поводу того, что я сначала делаю select, а потом update. 2 раза по большой таблице идти, может это лучше сделать одним запросом как то? Чтобы разок прошелся, увидел запись и обновил. 0

Опции темы