Как ускорить процесс получения большого объема данных?

Question

[Орхан Гасанлы]

Доброго времени суток!
Задача вкратце - есть 1-й datasource (View), изкоторого нужно получить данные и записать их во второй datasource. После получения данных из 1-й БД необходимо для каждого адреса получить координаты из nominatim (поднят, как отдельный сервис).
Логика работы - запрос приходит из фронта, запускается процесс обновления данных и записывается в БД. Потом на фронт возвращается deferredResult со статусом "ок" и компонент таблицы отрисовывается с новыми данными.
Кол-во данных за 1 раз до 10 000.

Что реализовано на данный момент -
Получаю Stream<T> по 1000 из первой БД, итерирую по нему и получаю координаты и записываю их в БД (разумеется, там есть проверки, валидации и т.д.). В общей сложности для 10 000 данных весь процесс занимает около 20-25 мин. Если стрим записи в БД сделать параллельным (parallelStream()), то появляется проблема при записи в БД, так как некоторые потоки пытаются одновременно обновить одни и те же данные. Но если в целом ошибок не возникает, то время сокращается дважды.
Разумеется, что не хочется заставлять юзера так долго ждать. + к тому же если он обновит страницу, то данные могут быть не обновлены.

Что раньше пытался реализовать - использовать Spring Quartz и на запрос юзера возвращать uuid, по которому фронт будет дергать статус и если все ок, то рендерить компонент. Правда, возникли некоторые проблемы с самим фреймворком.

Вариант с дерганием данных по CRON, не является решением. Хоть и реализован на данный момент тоже. Т.е. пользователь всегда может захотеть получить актуальные данные.

Comments

[My1Name]

Получаю Stream по 1000 из первой БД, итерирую по нему и получаю координаты

В общей сложности для 10 000 данных весь процесс занимает около 20-25 мин.

Это время получения и записи в БД, или время получения координат? Если вы работаете со свёрточной нейро-сетью, чтоб получить координаты, то чтоб ускорить процесс его нужно принципиально поменять :)

[Орхан Гасанлы]

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

[My1Name]

Орхан Гасанлы,

некоторые потоки пытаются одновременно обновить одни и те же данные. Но если в целом ошибок не возникает, то время сокращается дважды.

Если вас устраивает сокращение времени на два, то напрашивается "виртуализация" процесса. Например создавать временную БД, или TEMP файл, если вычислительные мощности не позволяют держать весь объём данных в памяти.

По идее Hibernate Shards решает такие проблемы. Однако, сам не пользовался, поэтому утверждать не могу.

Answer 1

[rPman]

что именно занимает так много времени, проведи профилирование чтобы выяснить где больше всего проводит времени твой код - например внутренняя обработка данных или база данных?

для 10 000 данных весь процесс занимает около 20-25 мин.

для такого объема записей это слишком большой срок для базы данных

Что за анализ выполняется для этих данных что так медленно? почти наверняка это сделано ОЧЕНЬ не эффективно, особенно если вылезает вот это:

Если стрим записи в БД сделать параллельным (parallelStream()), то появляется проблема при записи в БД, так как некоторые потоки пытаются одновременно обновить одни и те же данные.

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

Правильно - разделить свою задачу на три - анализ, обработка и сохранение данных. Затем анализ и/или обработку переделать на работу с одновременно большим количеством данных.. в оперативной памяти, а уже потом записать результат.

Классический пример: для каждой записи ты делаешь запрос - найти соответствующий объект(ы) в базе, прочитать их, изменить и записать результат в базе. нужно сделать так - выгрузить сразу много записей (условно по 1000), изменить их с учетом того что это будет происходить в оперативной памяти, многократная запись одних и тех же объектов не будет занимать столько времени как запись в базу.

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

Современные даже десктопные машины с 16-32гб (а серверные с 128-256 легко) оперативной памяти позволяют вообще зхагрузить большую часть данных в оперативную память и обработать ее там эффективнее чем это получится делать через sql прослойку, которая рассчитана не на скорость обработки а на надежность хранения и многопользовательский доступ.

Comments

[Орхан Гасанлы]

Добрый день. Прежде всего большое спасибо за ответ.

что именно занимает так много времени, проведи профилирование чтобы выяснить где больше всего проводит времени твой код - например внутренняя обработка данных или база данных?

Больше времени затрачивается на внутреннюю обработку, потому что приходится много чего проверять.

По факту -
* получить данные в стрим stream<T> Это происходит быстро
* проверить есть ли запись в БД или нет. Если есть, то сделать equals() и в случае надобности обновить
* комбинируя различные варианты попробовать подобрать координаты. В лучшем случае это 1-2 запроса к nominatim или достаем дефолтные координаты села, города и т.д. из БД.
* Ну и дальше записать все в БД.

Классический пример: для каждой записи ты делаешь запрос - найти соответствующий объект(ы) в базе, прочитать их, изменить и записать результат в базе. нужно сделать так - выгрузить сразу много записей (условно по 1000), изменить их с учетом того что это будет происходить в оперативной памяти, многократная запись одних и тех же объектов не будет занимать столько времени как запись в базу

Согласен. Нужно будет пересмотреть процесс обновления.

[rPman]

Больше времени затрачивается на внутреннюю обработку,

В лучшем случае это 1-2 запроса к nominatim

nominatim у тебя локальная установка или пользуешься их api онлайн? Так как онлайн ты маловероятно что сможешь ускорить. batch запросы как я понимаю там не реализованы.

Может все же проведешь профилирование, jprofiler (или тот что в твою IDE встроен) запустить дело пяти минут. Без этого будет тупо гадание.

Запросы на проверку наличия данных в базе можно завернуть в пакет, грубый пример если это поиск по id то будет достаточно задать все списком id in (123,234,345,456), если это что то сложнее, то можно сначала залить данные для фильтрации во временную таблицу (без индексов in memory) и опять одним запросом получить нужные данные.

Если все запросы у тебя происходят локально, проверь, нагружена ли машина полностью? хватает ли ресурсов cpu/disk/ram и если да, то возможно придется запускать больше инстансев того же nominatim или к примеру заранее подгружать в оперативную память какие то данные (например координаты городов и сел, это не такая уж и большая база)

[Орхан Гасанлы]

rPman,

nominatim у тебя локальная установка или пользуешься их api онлайн?

локальная копия

Может все же проведешь профилирование, jprofiler

Да, скорее всего придется профилировать.

Если все запросы у тебя происходят локально, проверь, нагружена ли машина полностью?

Нет машина, не нагружена. В принципе, я могу нагрузить оперативку и процессор.

Большое спасибо

[Орхан Гасанлы]

благодарю за идеи. Мне удалось решить проблему путем batch операций и параллельного стрима для определения координат. Время снизилось с 25 мин до 2-3 минут.

Answer 2

[Андрей Шишкин]

Сходу - это выглядит как обычная батчевая обработка данный. Легко реализуется с помощью spark.

Comments

[Орхан Гасанлы]

Не доводилось работать с apache spark. Вполне возможно. Благодарю за ответ

[Орхан Гасанлы]

благодарю за идеи. Мне удалось решить проблему путем batch операций и параллельного стрима для определения координат. Время снизилось с 25 мин до 2-3 минут.

[Андрей Шишкин]

Орхан Гасанлы, Со спарком в итоге ?

[Орхан Гасанлы]

Андрей Шишкин, пока что нет. Но если понадобится, то в будущем обязательно подключу

Answer 3

[mayton2019]

Сложно обсуждать перформанс-проблему без исходного кода.

Я-бы предложил как всегда ударить кувалдой. Тоесть запустить по приложению JProfiler и просто посмотреть что он покажет. Проблемных мест может быть 3. Это чтение из базы. Второе это собственно проверки и валидации. Как они реализованы? Насколько качественно? И третье это собсно запись в БД. Используется ли JDBC-batch?

SpringQuartz, cron, view здесь вообще непричем и их наличие только путает нас и вносит новые ненужные вопросы. Лучше решать проблему как одну java-функцию с входом и выходом.

Comments

[Орхан Гасанлы]

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

Это чтение из базы.

Да, это происходит быстро.

Второе это собственно проверки и валидации.

Именно второй этап занимает дольше по времени, так как есть маппинги, валидации, проверки существования записи в БД, поиск координат и прочее.

И третье это собсно запись в БД. Используется ли JDBC-batch?

Да, используется.

[mayton2019]

Орхан Гасанлы, показывай код.

[Орхан Гасанлы]

mayton2019,
благодарю за идеи. Мне удалось решить проблему путем batch операций и параллельного стрима для определения координат. Время снизилось с 25 мин до 2-3 минут.

[mayton2019]

Орхан Гасанлы, ПФ... Ну чтож. Решил так решил.

Answer 4

[Орхан Гасанлы]

Проблему решил путем применения Spring Batch.