Обновить
5
0
Виктор Кугаус@vkugay

Пользователь

Отправить сообщение

Вы имеете в виду следующий алгоритм?

  1. Клиент отправляет составные данные, например, CSV файл, с помощью протокола HTTP

  2. Сервер оформляет подписку на событие data c помощью readable.on('data', callback);

  3. Обработчик буферизует X байт и инициирует процесс загрузки данных в базу данных

  4. Обработчик буферизует еще X байт и снова инициирует процесс загрузки данных в базу данных, пока предыдущие данные загружаются

  5. Обработчик ставит потребление данных на паузу, когда суммарно обрабатываемое количество данных достигает размера Y

  6. Обработчик продолжает потребление данных, когда один из процессов загрузки X байт завершился

Если я все понял правильно, то, возможно, такой алгоритм позволит ускориться в сравнении с for await, но нужно замерить производительность в среде приближенной к эксплуатационной, потому что я вижу следующие риски:

  • Все еще нужно контролировать общую утилизацию памяти, т.к. одновременно не должно обрабатываться более Y байт данных, иначе можно поймать OOMKilled

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

Что точно можно сделать с помощью такого алгоритма, так это обойти лимит на количество параметров SQL в PostgtreSQL, который для libpq составляет 65,535. Но тоже самое можно реализовать, если разбить крупный чанк, полученный с помощью for await ... of, на более мелкие и использовать для их загрузки отдельные подключения.

Информация

В рейтинге
Не участвует
Откуда
Москва, Москва и Московская обл., Россия
Дата рождения
Зарегистрирован
Активность