Консультация по оптимизации алгоритма?

Question

[Николай Прогрессов]

Задача: из большой удаленной БД через API пассажира получить, отфильтровать и аккуратно засторить данные к себе. Пассажир отдает данные постранично, на одной странице 50 записей, или меньше, если предверие конца. При конце данных получаем ожидаемые теги.

Сначала решал задачу в одно потоковом режиме типа page++ эффективность такого решения примерно 23 часа. По не зависящим факторам БД может обновится раз в сутки и этот момент может повлиять на консисетность, да и вообще, если честно долго.

Написал пул из 10 воркеров, которые решают задачу, работа из 23 часов превратилась в работу от 1 до 3 часов. Суть работы пула, это просто револьвер, мастер делает page++ а свободный воркер подхватывает задачу. Найдена граница? все следующие воркеры либо узнают в процессе, доделывают и завершаться, либо при ожидании задачи тоже завершатся. Все работает нормально.

Вопрос вот какого характера: вот этот револьвер, как думаете? можно еще оптимизировать?

Второй вопрос: имеет ли смысл заморачиваться с вычислением границ, ну типа узнать сколько страниц и все такое? софт долгоиграющий, просто метрики выплевывать это фигня, а вот говорить сколько из скольких.

Спасибо!

PS: Извините если нет тут кода golang, но смею вас заверить все написано на go, поэтому примеры будут кстати.

Comments

[Вадим Косолапов]

Как я понял, вам отдаётся за 1 раз по 50 записей. Может стоит запускать 50 горутин и через каналы получать данные и всё это синхронизировать?

[Николай Прогрессов]

есть. там на самом деле есть интерфейс, в цикле обрабатываются несколько сущностей. но уникальный айди есть.

[Модератор]

me-zundig, user_test_345, не надо писать комментарии в секции ответов

[Николай Прогрессов]

user_test_345, сущности, это типа: подразделения, другая сущность сотрудники, структуры разные,
есть интерфейс и его контракт знает что делать, ну вы поняли, что пишет в разные сущности, но айди есть, я просто хотел подчеркнуть реализацию, спасибо, что заинтересовались.

[Николай Прогрессов]

Модератор, Извините

[Николай Прогрессов]

спасибо :) очень чревато запускать 50 воркеров, я могу запуситть и несколько тысяч, какой будет результат :) Знаете вопрос больше касался к тому, что как не зная границ решения выдавать результаты типа 8 из 10 и возможно не в тему(извините) как этот пассажир работает, на 50 потоков(возможно это поведение настроено) все плохо

[devalone]

Стоит найти bottleneck, может у тебя сеть больше данных не передаст.

[devalone]

> Написал пул из 10 воркеров, которые решают задачу
обычно берётся число аппаратных потоков и умножается на коэффициент, который подбирается опытным путём, т.е. это скорее всего должна быть степень двойки.

[Николай Прогрессов]

devalone, горутина это не классический форк или тред, горутину обслуживает рантайм, поэтому архитектура тут практически не роляет, даже хеллоу ворлд выполняется в несколько потоков :)

[Николай Прогрессов]

user_test_345, огромное спасибо вам за идею.

[devalone]

Николай Прогрессов, да, я знаю, что горутина != поток.
> даже хеллоу ворлд выполняется в несколько потоков
Смотря какой хеллоу ворлд

Answer 1

[bodrich]

Какое примерно среднее количество записей вы получаете из API/записываете в таблицу?
Есть ли ограничения на количество запросов к API ?

Comments

[Николай Прогрессов]

получаю примерно 2 000 000/ записываю порядка 10 000

[Николай Прогрессов]

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