Сначала о термин запроса против любых других запросов. Срочные запросы являются самыми быстрыми, потому что они требуют только поиска по срокам и получения всех совпадающих идентификаторов документов. Это тривиальная операция, и она использует словарь терминов, где эта информация берется так же быстро, как и поиск ключа.
Конечно, фильтр дальнего радиуса будет намного медленнее, даже если вы включите DocValues (по умолчанию), он все равно будет медленнее.
Я не вижу, чтобы ваш numberSort был вложенного типа. Не уверен, что это ускорит поиск, но стоит попробовать, так как вы хотите, чтобы он был вложенным, я думаю.
Что можно сделать для ускорения запросов:
Вы уже выбрали эти диапазоны запросов в качестве фильтров, которые должны кэшировать их, чтобы впоследствии их можно было эффективно использовать повторно (поэтому, я надеюсь, вы измеряете числа после потепления до)
Из размера вашего индекса ясно, что если вы поделите 120 Гб индекса на 5 узлов, вы получите около 24 Гб на узел данных. Однако объем вашей оперативной памяти составляет всего 26 ГБ , что недостаточно для mmap всех файлов индексов, которые должны быть расположены в памяти (у вас есть только 26 - 12 = 14 ГБ оперативной памяти для mmap). Эта ситуация потребует загрузки / выгрузки файлов с диска в память, что создаст много операций ввода-вывода (думаю, вы могли бы доказать это, измерив это). Я бы предложил увеличить объем оперативной памяти, чтобы ее было достаточно для получения всех файлов индексов на этом узле. Это обычно сильно ускоряется.