Написать модуль для парсера работа с потоками, cpr и clickhouse C++
Цена договорная
Необходимо написать модуль для эффективной работы с запросами в бд и на сайт.
Функции, который отправляют запрос, возвращают данные, превращают json в объект и записывают объект в бд есть. Также есть пример, как асинхронно запустить 10 потоков и спарсить часть данных в бд (бд разворачивается локально с помощью docker-compose.yml).
Необходимо написать отдельные файлы с логикой для пула с потоками (чтобы использовать не 10, а больше потоков) для парсинга данных. Есть несколько нюансов:
1. Предметов, которые нужно парсить 652
2. Записей всего выйдет около 27млн, на один предмет может приходиться до 7 млн записей. То есть количество данных огромное
3. Не смотря на огромное количество данных, есть проблемы api с которым работаем: нельзя получить больше 200 предметов, а также нельзя делать слишком много запросов. В хедере ответа приходят:
скрин запроса + хедеры
количество оставшихся, время когда восстановятся все запросы. При запуске многопотока надо это учитывать и нет смысла запускать слишком много потоков, если часть из них будет стоять и ждать, пока токен даст возможность отправлять запросы.
Для этого есть функция по рефрешу токена
4. Сущность client для работы с базой данных -- не потокобезопасна, поэтому работа в отдельных самое то, возможно придется дописать database_manager чтобы можно было получать всегда новый клиент
Цены предлагайте, по времени: желательно до вс, если сможете сегодня -- очень круто
Функции, который отправляют запрос, возвращают данные, превращают json в объект и записывают объект в бд есть. Также есть пример, как асинхронно запустить 10 потоков и спарсить часть данных в бд (бд разворачивается локально с помощью docker-compose.yml).
Необходимо написать отдельные файлы с логикой для пула с потоками (чтобы использовать не 10, а больше потоков) для парсинга данных. Есть несколько нюансов:
1. Предметов, которые нужно парсить 652
2. Записей всего выйдет около 27млн, на один предмет может приходиться до 7 млн записей. То есть количество данных огромное
3. Не смотря на огромное количество данных, есть проблемы api с которым работаем: нельзя получить больше 200 предметов, а также нельзя делать слишком много запросов. В хедере ответа приходят:
скрин запроса + хедеры
количество оставшихся, время когда восстановятся все запросы. При запуске многопотока надо это учитывать и нет смысла запускать слишком много потоков, если часть из них будет стоять и ждать, пока токен даст возможность отправлять запросы.
Для этого есть функция по рефрешу токена
4. Сущность client для работы с базой данных -- не потокобезопасна, поэтому работа в отдельных самое то, возможно придется дописать database_manager чтобы можно было получать всегда новый клиент
Цены предлагайте, по времени: желательно до вс, если сможете сегодня -- очень круто
В заказе есть исполнитель
При переводе заказа из архивного в актуальный, текущий исполнитель будет снят с задачи.
Выберите тип сделки
С безопасной сделкой вы всегда сможете вернуть средства, если что-то пойдет не так. С простой сделкой вы самостоятельно договариваетесь с исполнителем об оплате и берете на себя решение конфликтов.