Ох. Ну давайте подряд. Начнем с конца :-p
3) Мгновенного поиска не бывает. Так что нужно сразу понимать необходимой быстродействие. Кому то и 1500ms "мгновенно", а кто то хочет за 10ms данные получить.
Критические вопросы:
- какой объем данных в базе всего
- какое количество поисков случается в секунду
- насколько поисковые запросы избирательны (ответ на поисковый запрос это единицы записей или десятки тысяч)
- насколько консистентна и релевантна должна быть поисковая выдача с учетом постоянных апдейтов.
- сколько есть денег на сервера ;-)
Если данных мало (< 1gb плюс минус) я бы не парился и записал это все в обычный mysql навешав на него 100500 индексов. Дальше нужно померять производительность на запись-чтение, если все устраивает - на этом и остановиться.
Если данных больше и хочется освоить что то новое - я бы посмотрел в сторону Elastic Search.
Ребята из 2gis как раз пару лет назад его внедряли
https://habrahabr.ru/company/2gis/blog/213765/ документации по нему море. Из минусов - выдача всегда будет отставать от горячих данных.
Если нужен поиск по горячим данным и при этом быстродействие mysql не устраивает - у меня нет хорошего ответа :) Можно какую нибудь кассандру посмотреть, можно свой велосипед напилить, но тут советовать лично мне - сложно.
2) Нода, питон, руби, пхп - дело вкуса абсолютно. Основная нагрузка (если речь не идет про велосипеды) будет все равно на БД идти. А велосипеды лучше на C++ писать такие.
1) По Вашему посту у меня больше вопросов чем ответов если честно. Что за json, откуда они берутся, как будут разрешаться конфликты если новые json приходят быстрее чем обрабатываются старые, итд.
В целом это более тривиальный вопрос чем задача быстрого поиска.
