Если я верно понял ваш вопрос)

а, у вас за последние три месяца все это уже работает?

Просто сразу пишем в солр

И параллельно в хдфс

я бы определился с архитектурой сначала: если у вас запросы к старым данным нужны редко, и ждать готовы долго - держать в операционном только последние месяцы, а поиск в старых данных делать батчем; если бизнес готов платить за держание бОльшего объема в оперативном хранилище - держать там больше

процедуру индексации / поднятия стоит иметь готовой в любом случае, операционно она когда-нибудь пригодится))

Ну это есть уже) просто это рассчитано на ручной запуск. Предложил разрешать ее делать по запросу клиента. И потом маунтить в алиас в паре к существующей коллекции - типо прозрачно что бы было для пользователя.

А я хотел убрать это построение индекса, делать мапРед так и так надо, так почему бы не делать его по критериям. А сам набор критериев всегда хранитьно в быстрой доступности. Но тут возникает вопрос, в каком виде отдать результат мапРеда для дальнейшего анализа?

у вас потребители же общаются через какой-то доменный АПИ? просто добавить туда ветку когда запрос через батч

Добавить ветку, это значит создать индекс и добавить в солр, так как оперативное хранилище это солр и api это по сути веб который ходит в этот солр

И что вы подразумеваете под словом "ветка"?)

ваш АПИ может знать какие данные доступны в операционном хранилище и какие лежат в архиве, и давать пользователю запросить данные из оперативки, или из архива (тогда сделать батч, ждать его завершения и отдать результат как вам удобно)

зависит уже от деталей АПИ, если речь про список документов то должно быть довольно просто, но в пределе может вылиться в сложную федеративную систему, тогда мб дешевле просто расшириться и держать больше в оперативном хранилище

Это значит, что нужно сложить данные в какое то хранилище, что бы можно было сделать поиск в этом хранилище. Поиск по результату батча желательно уже делать быстрый. А это или строить индекс или я не знаю есть ли ещё какие то способы?

я не знаю деталей вашего АПИ, если оно простое - может быть искать сразу в батче и выдавать конечный результат?

Да нет никакого апи. Просто есть веб интерфейс со строкой поиска, на текущий момент рассчитано на полнотекст. Для того что я собираюсь делать видимо надо как то видоизменять это апи

Сложно то что есть назвать апи)

Полнотекст, потому что пока ищется в солр

Простите, я плохо объясняю. По сути хочется сделать такую систему, что бы результат мапредьюса уже загнать в какое то хранилище которое позволяло бы искать быстро - десятки минут, думаю до получаса, лучше в течение 10 минут. Но проблема в том, что в результате будут возвращаться данные с неизвестной мне схемой и я не могу заранее преподготовить структуру куда загнать результат

я так понимаю у вас больше пока архитектурных вопросов, но в смысле хранилищ что HBase что Solr могут хранить данные без всяких ограничений в схеме

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