Клиент отправляет составные данные, например, CSV файл, с помощью протокола HTTP
Сервер оформляет подписку на событие data c помощью readable.on('data', callback);
Обработчик буферизует X байт и инициирует процесс загрузки данных в базу данных
Обработчик буферизует еще X байт и снова инициирует процесс загрузки данных в базу данных, пока предыдущие данные загружаются
Обработчик ставит потребление данных на паузу, когда суммарно обрабатываемое количество данных достигает размера Y
Обработчик продолжает потребление данных, когда один из процессов загрузки X байт завершился
Если я все понял правильно, то, возможно, такой алгоритм позволит ускориться в сравнении с for await, но нужно замерить производительность в среде приближенной к эксплуатационной, потому что я вижу следующие риски:
Все еще нужно контролировать общую утилизацию памяти, т.к. одновременно не должно обрабатываться более Y байт данных, иначе можно поймать OOMKilled
Усложнится обработка данных, а прироста в скорости загрузки данных не произойдет, т.к. одновременная вставка большого количества данных создаст узкое место в БД
Что точно можно сделать с помощью такого алгоритма, так это обойти лимит на количество параметров SQL в PostgtreSQL, который для libpq составляет 65,535. Но тоже самое можно реализовать, если разбить крупный чанк, полученный с помощью for await ... of, на более мелкие и использовать для их загрузки отдельные подключения.
Вы имеете в виду следующий алгоритм?
Клиент отправляет составные данные, например, CSV файл, с помощью протокола HTTP
Сервер оформляет подписку на событие data c помощью readable.on('data', callback);
Обработчик буферизует X байт и инициирует процесс загрузки данных в базу данных
Обработчик буферизует еще X байт и снова инициирует процесс загрузки данных в базу данных, пока предыдущие данные загружаются
Обработчик ставит потребление данных на паузу, когда суммарно обрабатываемое количество данных достигает размера Y
Обработчик продолжает потребление данных, когда один из процессов загрузки X байт завершился
Если я все понял правильно, то, возможно, такой алгоритм позволит ускориться в сравнении с for await, но нужно замерить производительность в среде приближенной к эксплуатационной, потому что я вижу следующие риски:
Все еще нужно контролировать общую утилизацию памяти, т.к. одновременно не должно обрабатываться более Y байт данных, иначе можно поймать OOMKilled
Усложнится обработка данных, а прироста в скорости загрузки данных не произойдет, т.к. одновременная вставка большого количества данных создаст узкое место в БД
Что точно можно сделать с помощью такого алгоритма, так это обойти лимит на количество параметров SQL в PostgtreSQL, который для libpq составляет 65,535. Но тоже самое можно реализовать, если разбить крупный чанк, полученный с помощью for await ... of, на более мелкие и использовать для их загрузки отдельные подключения.