Как организовать пагинацию, если БД и поисковая машина - это раздельные сервисы?

Boris Korobkov, на данный момент атрибутов 43 (из них 14 MVA с кол-вом внутри до 110) - и уже проверено, что полнотекстовый индекс (он, кстати, достаточно слабый - индексируются слова без словоформ и большим количеством стоп-слов) с атрибутами и без них различаются по объему на 63%. Не удвоенние, но ощутимо.

Однако я так понял, что вариант здесь только один (предложенный вами) и других решений попросту пока не существует.

Единственная реальная проблема - это обновление данных в этом индексе (обновлений много и они регулярные). Оно попросту не успевает выполняться, 16 воркеров на сервере с 24 ядрами отведены сфинксу - и все равно не успевает. Пересматриваем архитектуру, важность некоторых атрибутов, но все равно пока что слабо работает поиск.

Как организовать пагинацию, если БД и поисковая машина - это раздельные сервисы?

В тексте вопроса указано, что поисковая машина справляется куда медленнее с фильтрацией по атрибутам, поскольку они хранятся в индексе поисковой машины неиндексированными. Все, для чего годится информация в индексе поисковой машины - добавочные фасеточные запросы. Плюс требуется содержать полную копию данных в индексе поисковой машины, по которым требуется фильтрация и сортировка - а это банальное удвоение занимаемого места на жестком диске / SSD (при 100 миллионах документов это очень ощутимые объемы).

Еще один крайне неприятный момент - это чрезвычайно медленный UPDATE в real-time индексе SPHINX'a / Manticore - от 0.06 до 0.25 с на одну строчку (это даже если просто меняется значение одного атрибута). Поддерживать строки в индексе поисковой машины в актуальном состоянии становится проблематичным (а обновления частые)