Мне вот то же самое говорят

в общем, было бы желание, а где руки приложить — найдется.

Подобную дискуссию лучше проводить в каком-нибудь баре под пиво или лучше водку. Чтобы можно было бить кулаком себя в грудь и по столу.

кстати, поглядите фильмик:
https://www.rstudio.com/resources/rstudioconf-2017/happy-r-users-purrr-tutorial-/

на rconf вообще ОЧЕНЬ МНОГО показывают и рассказывают ценных вещей

Я регулярно их доклады поглядываю.

ну из моей практики пример- парсинг чего то слабоструктурированого, с постраничным опросом.

Поэлементное обращение к апи,
Быстрый опрос нескольких бд

Вот последний пункт в сердечке откликнулся.

ну до базы с транзакциями дойти обычно не проблема. Оттуда выручка достается

еще вспомнил парсинг сложных json ов, когда силами бд не победить, да и просто длинных текстов

Ага, а потом начинается: "это не те транзакции, это мы вообще не считаем, это другой юнит, это транзакция внутри холдинга". И вот эти "это" часто только в голове заказчика)

Поэлементное обращение к апи — тут неплохо бы уточнить, может оно и не нужно поэлементное....
но в этом случае очень хорошо использовать https://github.com/HenrikBengtsson/doFuture
plan(future.callr::callr)
обычно API отвечает долго. можно создать воркеров много больше (32-64, сколько ОС позволит) чем ядер (они все равно будут 95% времени простаивать) и дать нагрузку на API по полной.
если API не помрет, то данные можно вытащить на максимальной скорости.
а разработчики будут вспоминать вас хорошими словами.

на практике такой стресс-тест мало какая система проходит. а все потому, что API пишут по остаточному принципу.

Т.е. если у меня есть 8 идентичных баз (1 на МРФ), к которым мне нужно сделать идентичный запрос. Где мне тут этот ваш параллелизм поможет?

одновременно их запустить
furrr/foreach
ускорение почти в 8 раз.
главное, чтобы оперативки и ядер хватило.

Что не так?

чем парсите?

Ок, гляну, как это написано на другом языке. Если реально в 8 раз, то ради того, чтобы лишний раз адептов того языка ткнуть носом вот в это самое, я готов и виньетки почитать.

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

а что, в ОПСОС-ах еще осталось кого тыкать?

Вполне успешно можно дербанить JSON с помощью jsonlite, purrr и tydir

какой объем?

ну там fromjson и всякое такое, если про тексты то стрингером