Иногда бывает нужно поменять конфиг (потюнить стоп-слова и т.п.), и после этого надо перестраивать индекс. Поскольку данные лежат в монге, то стандартный индексатор не подходит и сделали так:
Написали скрипт, который тянет данные из монги, и пихает в сфинкс пачки REPLACE (не INSERT чтобы при коллизиях ошибки не лезли)
Для прозрачного обновления написали прокси, который дублирует апдейты в новый инстанс поиска, а селекты тянет из старого, пока переиндексация не закончится. Этот же прокси управляет запуском инстансов.
Работает. Но что-то мне подсказывает, что прокси тут лишний, и эта функциональность должна быть внутри поискового движка. Вроде как индексатор что-то подобное умеет.
xmlpipe2 не нравится, т.к.:
не уверен что умеет в RT
будет один долгоиграющий запуск без нормального контроля прогресса (гораздо удобнее все сделать чанками через очередь)
Просто перезаписать все данные поверху и потом optimize - по-моему будет дикая деградация скорости на несколько часов индексации.
Есть какой-то способ сочинить индексатор из кастомного источника, на основе insert/replace-запросов? Логика примерно такая:
просим обновить конфиг
объявляем, что началась индексация
ставим в очередь задач нужное количество чанков и ждем пока зальются
говорим что индексация закончилась, чтобы переключиться на новый индекс
Такого, чтобы структура полей поменялась, на практике случиться не должно. Обычно требуется именно тонкий тюнинг, типа стоп-слов, алиасов и т.д.
индексируете данные в plain индекс с новым конфигом
вводите индекс в строй в демоне ротацией
в старом индексе, меняете конфиг, выполняете ALTER RECONFIGURE
выполняете ATTACH INDEX plain_name TO RTINDEX rt_name WITH TRUNCATE
так у вас получится быстрая индексация и только данные с новым конфигом в РТ индексе
или же вы можете поменять настройки индекса и выполнить ALTER RECONFIGURE, тогда текущие данные будут сохранены со старыми настройками, после этого настройки РТ индекса изменены и новые данные будут индексироваться с новыми настройками
Тут непонятно. Как мне набивать данными plain index, если он не умеет добавлять документы - только генерируется за один проход через indexer, который мне не очень подходит.
В случае RT просто создавался пустой инстанс, и туда кидались пачки по 1000 документов, и параллельно новые запросы из живой системы.
Из документации этот момент не очень понятен. Есть где-нибудь пример, как на одном инстансе втянуть 2 разнотипных индекса с разными конфигами? Может я что-то пропустил.
Было бы неплохо, но как потом проапдейтить старые записи, не убивая производительность? Написать скрипт который загонит кучу replace-запросов не проблема, но ведь анутри RT должен получиться киллист размером со всю базу.
ALTER RECONFIGURE с новым конфигом, сохранит все данные в диск чанк и примент новый конфиг
все новые вставляемые данные будут использовать новый конфиг
по окончании индексации делаете, FLUSH RAMCHUNK index - данные из памяти сохранятся в дисковый чанк
запускаете OPTIMIZE новые данные будут мержится со старыми данными и удалять документы которые были заменены
Таким образом у вас дубут доступны “старые” данные во время индексации новых, во время OPTIMIZE тоже старые и новые данные доступны до окончания процеса оптимизации и ввода диск чанка в индекс.
я предлагал индексацию через plain index \ xmlpipe2 - для того чтобы ускорить процесс индексации. Ввести же этот индекс в RT индекс можно командой ATTACH
те когда у вас plain index проиндексирован - вы пишете
RELOAD index_plain
ATTACH INDEX index_plain TO RTINDEX index_rt WITH TRUNCATE
так у вас удалятся все старные данные и все новые данные присоединятся как 0 диск чанк