Здравствуйте!
Имею RT-индекс на 16 млн. документов. Всё работало прилично, но захотелось кое-что попробовать: очистил этот индекс, создал 3 идентичных и объединил их в distributed (local). Заинсертил соответственно по 4 млн. доков в каждый.
Особой разницы по производительности не заметил.
Существует ли хотя бы теоретически польза от подобного решения?
RT индекс внутри устроен очень похоже на distributed. Только в последнем случае вы сами создаёте индексы-элементы и объединяете в один. А rt делает это автоматически - при вставке до определённого лимита накапливает данные в оперативке, а затем сохраняет накопленное как самый обычный дисковый индекс. Затем накапливается и сохраняется следующий, и т.д.
Лимит задаётся через rt_mem_limit.
Поиск по дисковому индексу всегда однопоточный.
Поиск по составному (неважно, rt или distributed) может распараллеливаться в зависимости от количества частей (очевидно, если там единственный элемент - так и останется один поток. Если больше - то уже появляются варианты распараллеливания).
Если у вас, условно, в исходном индексе было 4 дисковых чанка, а потом вы вручную поделили на 4 и получилось 4 индекса по 1 чанку - ну, вы просто повторили структуру оригинального rt-индекса. Какая-то разница в производительности возможна, но скорее всего непрогнозируемая и несущественная.
Спасибо! Всё понятно.
Скажите пожалуйста, я правильно понял, что если rt-индекс локальный, не distributed, но имеет несколько чанков (количество чанков = общего размер индекса \ его rt_mem_limit), то поиск по такому индексу не может быть в несколько потоков и всегда будет утилизировать 1 CPU ?
Спасибо.
Нет.
Всё зависит от типа запроса и размера индекса.
Если в запросе есть count(distinct) - всё будет в один поток, иначе для подсчёта distinct может потребоваться очень много памяти. Но это частный случай.
В остальных случаях создаются внутренние задачи для поиска по чанкам и кладутся в очередь.
По сравнению с distributed это проще, потому что у чанков единая схема, что делает работу проще.
Дальше эта очередь выполняется пулом потоков заданного размера (или одним потоком, если это vip), при этом каждому задействованному потоку нужен свой отдельный сортировщик.
По окончании все промежуточные результаты аггрегируются.
Для небольших индексов это может означать, что отработает единственный поток (остальные просто не успеют подготовиться - создать свою копию сортировщика и т.д.).