только я это к тому что

$client->batch(function() {
   $this->call('func1');
   $this->call('func2');
});

не очень подходит для такого кейса

нужно держать это в голове либо какой то явный апи для батчинга придумывать

ща отправлю пример как у нас кое где сделан батчинг для сфинкса , там sql

по теме: Consistent Map-Reduce in vshard

https://github.com/tarantool/vshard/discussions/261

@olegrok  @gerold103


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

Сценарий может быть такой :
Файберы на репликасетах получают задания из системы событий (внутренней или внешней это неважно) и понимают что на время обработки события нужно залочить все перемещения бакетов, например это может быть полезно для миграций , когда нужно все существующие и вновь приходящие данные обработать; при этом может понадобиться согласование с остальными репликасетами, но опять же это можно сделать и через внешний стейт менеджер, лишь бы была возможность взять pin и не отпускать его ни в коем случае пока явно не будет сигнала... Это может показаться похожим на двухфазное отключение шедулера и затем двухфазное включение, но это не совсем так... скорее это двухфазное снятие пинов

Другой пример использования:
(такое могло бы быть применимо в crud )
ситуации когда   tuple-merger невозможно использовать из за мультикей индексов или  когда вообще нужен курсор и сортировка не по текущим индексам,  в таком случае должна использоваться техника временных таблиц, при которой каждый воркер map скрринит данные в своем репликасете в тот момент когда ему удалось взять pin и затем отправляет во временное хранилище для reduce и сортировки,  после чего уже роутер может  свободно по курсору отдавать данные;  тоесть это такой асинхронный подход когда  момент принятия заявки на map reduce может не совпадать с моментом его фактического исполнения.

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

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

===

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

хотелки:
Такая же система хуков или триггеров нужна и при смене rw - ro , нужно иметь возможность "попросить "  снять  ref rw,  но об этом я много писал в тикетах vshard...
То же самое и о процессе выключения , тоесть при переходе из ro  в ничто ,   нужно иметь возможность дождаться снятия pin и ref     предварительно "предупредив " о скором завершении.

На текущий момент  по факту все переключения rw- ro       и   выключения - это жесткое отрубалово вместо реджекта вновь прибывших и ожидания завершения текущих.

Я обновил обсуждение и поотвечал там же в комментах

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

если только:

local tuple1, tuple2 = box.space.myspace:get(key1), box.space.myspace:get(key2)

но если вы про композитный индекс, то все же так:
local tuple = box.space.myspace:get({key1, key2})

Не совсем то, мне нужно, чтобы в одном кортеже присутствовали индексы с нужным значением)