Sphinx RT (real-time) индексы
Sphinx 1.10 поддерживает индексы реального времени (Reat-time или RT). Это самая важная функция в новой версии этого отличного полнотекстового поисковика. Индексы реального времени позволяют синхронно добавлять документы для поиска в индекс. Это позволяет избежать задержки появления новых документов в результатах поиска. Пробуем RT индексы на практике.
Обзор
Как уже было сказано, RT индексы позволяют добавлять документы в поисковый индекс на лету (не только добавлять, но и обновлять/удалять). RT индексы поддерживают не все дополнительные возможности (сейчас нет поддержки MVA атрибутов, префиксов, процесс оптимизации индекса еще не реализован), но большинство уже доступно. “Живые” индексы находятся в активной разработке, поэтому все недостающие функции будут доступны в скором времени.
Использование RT индексов
Объявление RT индекса выглядит следующим образом:
index rt_test
{
type = rt
path = /usr/local/sphinx/data/rt_test
rt_field = title
rt_field = content
}
Мы объявили RT индекс с двумя полями для индексации. Каждый RT индекс содержит целочисленную колонку ID документа (ее не нужно объявлять).
После перезагрузки демона поиска “searchd” на 9306 порту (по умолчанию) будет доступен сервер RT индексов. Работа с RT индексами пока реализована только на основе протокола MySQL. Для управления индексами доступны следующие команды:
- INSERT INTO rt_test(id, title, content) VALUES ( 1, ‘hello’, ‘world’)
- REPLACE INTO rt_test(id, title, content) VALUES ( 1, ‘hello’, ‘world’)
- DELETE FROM rt_test WHERE id = id
Также поддерживается множественная вставка, что предпочтительнее для вставки большого количества данных.
mysql -h 127.0.0.1 -P 9306 mysql> INSERT INTO rt_test ( id, title, content ) VALUES ( 2, 'second', 'world' ), ( 3, 'third', 'earth' ); Query OK, 2 rows affected (0.01 sec) mysql> REPLACE INTO rt_test ( id, title, content ) VALUES ( 1, 'new text', 'for first row' ); Query OK, 1 row affected (0.01 sec) mysql> DELETE FROM rt_test WHERE id=2; Query OK, 0 rows affected (0.00 sec)
На клиентской стороне поиск ни чем не отличается от обычного индекса, поэтому там все стандартно.
Внутренности и особенности RT индексов в Sphinx’e
RT индексы внутри состоят из фрагментов. Один фрагмент хранится в оперативной памяти, который хранит последние обновления. Когда размер фрагмента в RAM превышает лимит, он сбрасывается на диск, а оперативная память очищается. Большое количество дисковых фрагментов может привести к высокой фрагментации и снижению производительности поиска (пока дефрагментация не поддерживается), поэтому параметр rt_mem_limit а настройках лучше ставить побольше.
Фрагменты на диске представляют из себя обычные полнотекстовые индексы. Поскольку дисковые фрагменты не могут быть изменены, то изменения в индексе (удаление или обновление документов) переопределяют предыдущую версию документа. При большом объеме операций обновленния/удаления это может привести к снижению производительности поиска (из-за наличия “мусорных” документов). Уже запланирована работа по реализации процедуры оптимизации RT индексов.
В данный момент мы используем Sphinx 1.10 в продуктивной среде на одном крупном проекте. Работает очень стабильно. Планируем постепенно мигрировать на RT индексы.
Спасибо, за статью.
Пользуюсь сфинксом, решил посмотреть на новую 1.10 версию, и не совсем понял суть RT индексов, и принципы работы с ними.
Допустим я сделал полный индекс по определенной таблице, и хочу использовать RT индекс для новых данных, то получается я должен делать синхронно запрос вставки данных в реальную БД и в RT индекс сфинкса?? т.е. выходит два запроса.
а при поиске указывать оба индекса, но тогда должен пользоваться sql синтаксисом, т.к. RT индексы других интерфейсов пока не поддерживают ?
И при этом как не отпадает надобность в полной пере индексации, или создании дельта индекса скажем раз в сутки и сливании в основной, с вычисткой RT индекса, т.к. RT индекс сливать с чем либо не возможно (ругается на отсутствие файла с расширением sph).
Просто чего спрашиваю, я когда сначала прочитал эту новость, то подумал что реализовали возможность в сфинксе быть посредником между БД и приложением и прозрачно индексировать запросы вставки и апдейта, по описанным в конфиге правилам, но покопав насколько я понял RT индексы представляют из себя как бы отдельное быстрое хранилище с sql подобным синтаксисом.
Надеюсь вы развеете мои недопонимания.
@netisfen
Спасибо за вопросы.
RT индексы позволяют избежать процедуры переиндексации данных вообще (в т.ч. создания дельта индексов). После записи данных в RT индекс, они мгновенно становятся доступными в результатах поиска.
В приложении для поисковых данных действительно придется делать два запроса - один для сохранения в СУБД, другой - для записи в RT индекс. RT индексы имеют другую структуру, поэтому не могут быть использованы в операциях “сливания” (index merging).
SQL для доступа к RT индексам реализован просто как удобный протокол, т.к. многие используют MySQL в качестве хранилища, в скором времени будут доступны другие протоколы для управления RT индексами.
скажите, а SphinxQL и RT indexes по прежнему не могут сделать
SELECT id,title FROM rt_test WHERE id=1 ??
Во многих случаях поддержка индексов реального времени двухкратно усложняет программную логику так как фактически возникает необходимость поддержки в актуальном состоянии двух БД.
Одна особенность RT-индексов. При объявлении полей и атрибутов использовать только маленькие буквы. С большими буквами будут ошибки.
Т.е.
rt_field = TITLE
rt_field = CONTENT
выдаст потом ошибку при запросах INSERT/REPLACE и при поиске по атрибутам. Будет писать unknown field