MYSTERRIA3.0

Почему не Sphinx

Я подбираю индекс для живого и динамичного сайта, где не могу позволить себе роскошь в виде перестроения индекса раз в 10 минут, все документы, добавленные в индекс должны быть доступны уже сейчас. Или "почти" сейчас.

Sphinx - это не realtime поисковый движок (во всяком случае пока). Именно из-за этого прискорбного момента мне пришлось полностью исключить его использование в проекте. Строго говоря, в Sphinx-е есть 2 типа индексов:

Далее я подробно объясню, почему не использовать RT и в чем проблема дисковых индексов.

Итак, почему бы не взять RT?

Это не весь список проблем с RT индексами, я выбрал из них только те, что показались мне наиболее значительными и влияют на выбор, я так же оставил без внимания проблемы, которые по словам разработчиков всплывают "очень редко". Полный список вы можете посмотреть в документации по Sphinx.

А что с disk based?

Их надо реиндексировать время от времени, чтобы новые документы попадали в индекс.  В теории, можно попробовать обновлять индекс достаточно часто, чтобы добиться некоего подобия realtime и разработчики Sphinx даже сделали так называемые дельта-индексы (не тип индексов, а скорее методика индексирования) для этого. Основная идея дельта-индексов в том, что часто меняется только верхушка стека документов и именно ее (скажем, последние 10000 документов) и надо время от времени реиндексировать. Для этой врехушки мы создадим отдельный индекс и его обновление будет работать быстро и не будет убивать сервер. Кроме того, время от времени, мы будем сливать (merge) наш дельта-индекс с основным индексом. Здесь есть пара подводных камней:

Допустим, с виду все выглядит не так уж и плохо, но давайте взглянем на эту выдержку из документации, относительно слияния индексов: "Merging the indexes is normally faster than reindexing but still not instant on huge indexes. Basically, it will need to read the contents of both indexes once and write the result once. Merging 100 GB and 1 GB index, for example, will result in 202 GB of IO (but that's still likely less than the indexing from scratch requires). " Если операция слияния выливается в двойном объеме дисковых операций, что тем не менее "быстрее, чем перестроение индекса", какая же трагедия кроется в последнем?

А что если все таки был изменен старый документ, находящийся в main индексе? Тут все может быть либо тривиально, либо очень сложно. Все зависит от того, что именно было изменено. Если изменилось не текстовое поле, участвующее в full-text search, а, скажем, какой-то числовой атрибут, то мы просто обновим индекс на месте, без перестроения и каких бы то ни было трудностей, в API для этого есть метод UpdateAttributes( $index, $attrs, $values ). С полями, участвующими в полнотекстовом поиске все значительно хуже - обновляются они только при перестроении индекса и если существует вероятность изменения индексированных данных и есть потребность в каких-либо оперативных действиях по факту таких изменений, нужно думать о разбиении индекса на партиции и стратегии перестроения этих партиций.

Надеюсь, я уже вдохнул в вас оптимизм и желание потратить денек на планирование вашего индекса и схемы его перестроения.

 

 

Рубрики: Поисковые индексы

↑ Наверх


blog comments powered by Disqus

Контакты

Igor Zinkovsky aka TLoD,Snake. Писать на электропочту, стучаться в аську 302380533, искать в Санкт-Петербурге.

© 2002-2019