Сравнение движков полнотекстового поиска - История изменений

VitaliyFilippov: /* MySQL fulltext (5.5) */

2012-10-31T18:01:22Z

‎MySQL fulltext (5.5)

VitaliyFilippov: /* PostgreSQL Textsearch (9.1) */

2011-08-25T11:55:13Z

‎PostgreSQL Textsearch (9.1)

VitaliyFilippov: /* Сравнительная таблица */

2011-08-25T11:51:07Z

‎Сравнительная таблица

VitaliyFilippov: /* Сравнительная таблица */

2011-08-25T11:50:18Z

‎Сравнительная таблица

VitaliyFilippov в 11:49, 25 августа 2011

2011-08-25T11:49:26Z

VitaliyFilippov: /* Сравнительная таблица */

2011-08-22T15:48:53Z

‎Сравнительная таблица

VitaliyFilippov в 15:43, 22 августа 2011

2011-08-22T15:43:58Z

VitaliyFilippov в 14:25, 20 августа 2011

2011-08-20T14:25:26Z

VitaliyFilippov: /* Заключение */

2011-08-19T16:27:57Z

‎Заключение

Внесённые изменения

@@ Строка 9: / Строка 9: @@
 * Индексы можно создавать только на полях MyISAM-таблиц.
 * Размер индекса — примерно половина от размера данных. Правда, нужно иметь ввиду, что отключить сохранение самих текстов вы не можете, поэтому к этим 50 % нужно добавить ещё 100 % — данные-то хранятся.
-* Скорость индексации — в чистом виде приличная, примерно 1.5 МБ/с. Понятно, что ещё нужно прогонять через стеммер. Если наполнять индекс, на ходу вытаскивая данные из той же базы, и прогоняя через Perl-порт русского Snowball-стеммера — получается 314 КБ/с.
+* Скорость индексации — в чистом виде приличная, примерно 1.5 МБ/с. Понятно, что ещё нужно прогонять через стеммер. Если наполнять индекс, на ходу вытаскивая данные из той же базы, и прогоняя через Perl-порт русского Snowball-стеммера — получается 314 КБ/с. На самом деле в MySQL есть архитектура для подключения стеммеров плагинами («fulltext parser plugins»), вот только самих плагинов как-то нет… :)
 * Встроенного стеммера нет, стоп-слова вшиты английские, свои добавить нельзя. По умолчанию булев поиск идёт по «ИЛИ», поэтому для поиска по «И» нужно каждое слово превращать в «+слово».
 * Есть два режима — булев и обычный («natural language») поиск. Булев поиск просто проверяет, есть ли слова в документе и поддерживает логические операции, фразы и префиксный поиск, но не возвращает оценку релевантности (только 0 или 1). Обычный поиск умеет релевантность, но не умеет операторы. Поэтому, чтобы поддерживать и то, и другое — нужно дёргать один и тот же запрос в двух режимах.

@@ Строка 77: / Строка 77: @@
 * Индекс — инвертированный на основе [http://www.postgresql.org/docs/current/static/gin.html GIN] (обобщённый инвертированный индекс — Generalized Inverted iNdex). Раньше назывался [http://www.sai.msu.su/~megera/postgres/gist/tsearch/V2/ Tsearch2], создан Олегом Бартуновым и Фёдором Сигаевым.
 * Есть встроенные стеммеры, поддержка стоп-слов, синонимов, тезауруса (что-то типа словаря понятий, заменяет слова на другие «предпочитаемые»), словарей ISpell (хотя они, говорят, жутко тормозят при инициализации).
-* Есть возможность при индексации прицепить к каждой лексеме «вес», который на самом деле не «вес», а аналог Xapian-префикса, то есть, название поля, из которого лексема пришла. Таких «весов» может быть всего 4 — A, B, C, D, и в дальнейшем их можно использовать при поиске. Пример построения <tt>tsvector</tt>'а из двух полей с «весами»: <tt>setweight(to_tsvector(coalesce(title,'')), 'A') || setweight(to_tsvector(coalesce(keyword,'')), 'B')</tt>.
+* Есть возможность при индексации прицепить к каждой лексеме «вес», который на самом деле не «вес», а аналог Xapian-префикса, то есть, название поля, из которого лексема пришла. Таких «весов» может быть всего 4 — A, B, C, D, и в дальнейшем их можно использовать при поиске. Пример построения <tt>tsvector</tt>'а из двух полей с «весами»: <tt><nowiki>setweight(to_tsvector(coalesce(title,'')), 'A') || setweight(to_tsvector(coalesce(keyword,'')), 'B')</nowiki></tt>.
 * Есть ''отдельные'' функции для ранжирования результатов и подсветки искомых слов в цитатах. Ранжировать можно, присваивая численные веса «весам» ABCD, указанным выше (которые «поля»). Причём по умолчанию веса равны {0.1, 0.2, 0.4, 1.0}.
 * Индексируемый тип данных называется <tt>tsvector</tt> (text search vector). PostgreSQL позволяет создавать функциональные индексы, и в мануале по умолчанию предлагают создавать именно их — <tt>CREATE INDEX i ON t USING gin(to_tsvector(<поле>))</tt>. Так вот: <span style="color: red">не надо так делать!</span> А то очень неприятно удивитесь скорости запросов. Обязательно создавайте отдельную колонку типа <tt>tsvector</tt>, складывайте в неё свои <tt>tsvector</tt>'ы, и создавайте индекс на ней.

@@ Строка 151: / Строка 151: @@
 Интерфейс | SQL | SQL | API | API, SQL | Веб-сервис | API
 <abbr title="Количество доступных интерфейсных библиотек к различным языкам">Биндинги</abbr> | <abbr title="Распространённая СУБД, почти все языки">&forall;</abbr> | <abbr title="Распространённая СУБД, почти все языки">&forall;</abbr> | 9 | 6 + <abbr title="MySQL-протокол, с которым можно работать почти отовсюду">&forall;</abbr> | 8 | <abbr title="C++, Perl, оригинал Lucene в Java, остальное полуживое">3.5</abbr>
-Операторы поиска | <abbr title="Булевы, точная фраза. Префиксный поиск лучше не использовать, т.к. очень медленный."><nowiki>&*"</nowiki></abbr> | <abbr title="Только булевы? префиксный поиск"><nowiki>&*</nowiki></abbr> | <abbr title="Булевы, префиксный поиск, точная фраза, слова вблизи, диапазоны, приблизительный поиск"><nowiki>&*"N-~</nowiki></abbr> | <abbr title="Булевы, префиксный поиск, точная фраза, слова вблизи, диапазоны, порядок слов, зоны"><nowiki>&*"N-<Z</nowiki></abbr> | <abbr title="Булевы, префиксный поиск (+ wildcard'ы), точная фраза, слова вблизи, диапазоны, приблизительный поиск"><nowiki>&*"N-~</nowiki></abbr> | <abbr title="Булевы, префиксный поиск (+ wildcard'ы), точная фраза, слова вблизи, диапазоны, приблизительный поиск"><nowiki>&*"N-~</nowiki></abbr>
+Операторы поиска | <abbr title="Булевы, точная фраза. Префиксный поиск лучше не использовать, т.к. очень медленный."><nowiki>&*"</nowiki></abbr> | <abbr title="Булевы, префиксный поиск"><nowiki>&*</nowiki></abbr> | <abbr title="Булевы, префиксный поиск, точная фраза, слова вблизи, диапазоны, приблизительный поиск"><nowiki>&*"N-~</nowiki></abbr> | <abbr title="Булевы, префиксный поиск, точная фраза, слова вблизи, диапазоны, порядок слов, зоны"><nowiki>&*"N-<Z</nowiki></abbr> | <abbr title="Булевы, префиксный поиск (+ wildcard'ы), точная фраза, слова вблизи, диапазоны, приблизительный поиск"><nowiki>&*"N-~</nowiki></abbr> | <abbr title="Булевы, префиксный поиск (+ wildcard'ы), точная фраза, слова вблизи, диапазоны, приблизительный поиск"><nowiki>&*"N-~</nowiki></abbr>
 Стеммеры | Нет | 15 | 15 | 15 | 31 | 15 + CJK
 Стоп-слова, синонимы | <abbr title="Стоп-слова есть, но только намертво зашитые английские">Нет</abbr> | Да | Да | Да | Да | Да

@@ Строка 151: / Строка 151: @@
 Интерфейс | SQL | SQL | API | API, SQL | Веб-сервис | API
 <abbr title="Количество доступных интерфейсных библиотек к различным языкам">Биндинги</abbr> | <abbr title="Распространённая СУБД, почти все языки">&forall;</abbr> | <abbr title="Распространённая СУБД, почти все языки">&forall;</abbr> | 9 | 6 + <abbr title="MySQL-протокол, с которым можно работать почти отовсюду">&forall;</abbr> | 8 | <abbr title="C++, Perl, оригинал Lucene в Java, остальное полуживое">3.5</abbr>
-Операторы поиска | <abbr title="Булевы, точная фраза. Префиксный поиск лучше не использовать, т.к. очень медленный."><nowiki>&*"</nowiki></abbr> | <abbr title="Только булевы"><nowiki>&</nowiki></abbr> | <abbr title="Булевы, префиксный поиск, точная фраза, слова вблизи, диапазоны, приблизительный поиск"><nowiki>&*"N-~</nowiki></abbr> | <abbr title="Булевы, префиксный поиск, точная фраза, слова вблизи, диапазоны, порядок слов, зоны"><nowiki>&*"N-<Z</nowiki></abbr> | <abbr title="Булевы, префиксный поиск (+ wildcard'ы), точная фраза, слова вблизи, диапазоны, приблизительный поиск"><nowiki>&*"N-~</nowiki></abbr> | <abbr title="Булевы, префиксный поиск (+ wildcard'ы), точная фраза, слова вблизи, диапазоны, приблизительный поиск"><nowiki>&*"N-~</nowiki></abbr>
+Операторы поиска | <abbr title="Булевы, точная фраза. Префиксный поиск лучше не использовать, т.к. очень медленный."><nowiki>&*"</nowiki></abbr> | <abbr title="Только булевы? префиксный поиск"><nowiki>&*</nowiki></abbr> | <abbr title="Булевы, префиксный поиск, точная фраза, слова вблизи, диапазоны, приблизительный поиск"><nowiki>&*"N-~</nowiki></abbr> | <abbr title="Булевы, префиксный поиск, точная фраза, слова вблизи, диапазоны, порядок слов, зоны"><nowiki>&*"N-<Z</nowiki></abbr> | <abbr title="Булевы, префиксный поиск (+ wildcard'ы), точная фраза, слова вблизи, диапазоны, приблизительный поиск"><nowiki>&*"N-~</nowiki></abbr> | <abbr title="Булевы, префиксный поиск (+ wildcard'ы), точная фраза, слова вблизи, диапазоны, приблизительный поиск"><nowiki>&*"N-~</nowiki></abbr>
 Стеммеры | Нет | 15 | 15 | 15 | 31 | 15 + CJK
 Стоп-слова, синонимы | <abbr title="Стоп-слова есть, но только намертво зашитые английские">Нет</abbr> | Да | Да | Да | Да | Да

@@ Строка 77: / Строка 77: @@
 * Индекс — инвертированный на основе [http://www.postgresql.org/docs/current/static/gin.html GIN] (обобщённый инвертированный индекс — Generalized Inverted iNdex). Раньше назывался [http://www.sai.msu.su/~megera/postgres/gist/tsearch/V2/ Tsearch2], создан Олегом Бартуновым и Фёдором Сигаевым.
 * Есть встроенные стеммеры, поддержка стоп-слов, синонимов, тезауруса (что-то типа словаря понятий, заменяет слова на другие «предпочитаемые»), словарей ISpell (хотя они, говорят, жутко тормозят при инициализации).
-* Есть ''отдельные'' функции для ранжирования результатов и подсветки искомых слов в цитатах.
+* Есть возможность при индексации прицепить к каждой лексеме «вес», который на самом деле не «вес», а аналог Xapian-префикса, то есть, название поля, из которого лексема пришла. Таких «весов» может быть всего 4 — A, B, C, D, и в дальнейшем их можно использовать при поиске. Пример построения <tt>tsvector</tt>'а из двух полей с «весами»: <tt>setweight(to_tsvector(coalesce(title,'')), 'A') || setweight(to_tsvector(coalesce(keyword,'')), 'B')</tt>.
 * Индексируемый тип данных называется <tt>tsvector</tt> (text search vector). PostgreSQL позволяет создавать функциональные индексы, и в мануале по умолчанию предлагают создавать именно их — <tt>CREATE INDEX i ON t USING gin(to_tsvector(<поле>))</tt>. Так вот: <span style="color: red">не надо так делать!</span> А то очень неприятно удивитесь скорости запросов. Обязательно создавайте отдельную колонку типа <tt>tsvector</tt>, складывайте в неё свои <tt>tsvector</tt>'ы, и создавайте индекс на ней.
 ** Объясняю, почему: функция ранжирования результатов отдельная, и тоже работает с <tt>tsvector</tt>'ом. Если он не хранится, то должен вычисляться на лету при каждом запросе для каждого документа, а это очень хреново влияет на производительность, особенно, когда запрос находит много документов. То есть, если в запрос тупо включить сортировку по релевантности — <tt>ORDER BY ts_rank(to_tsvector(field), <query>) DESC</tt> — будет гораздо медленнее MySQL’я :).
 ** Заодно, в качестве оптимизации дискового пространства, можно не хранить полный текст документов в индексе.
-* Из операторов поиска — только AND, OR и NOT. Ни префиксов, ни поиска близлежащих слов, ни точных форм, ни фраз, ничего.
+* Из операторов поиска — AND, OR и NOT и префиксный поиск. Поиска близлежащих слов, точных форм, фраз нет.
 * Размер индекса — где-то 150 % от размера данных, если сами тексты не хранить, а хранить только <tt>tsvector</tt>'ы.
 * Скорость индексации — пока данных мало, 1.5 МБ/с, с ростом индекса потихоньку падает, но если сами тексты не хранить, то, вроде, устаканивается. На всё тех же данных багзиллы получилось в среднем 522 КБ/с, хотя к концу индексации было меньше, чем в начале.

@@ Строка 164: / Строка 164: @@
 PostgreSQL | Тезаурус, ISpell.
 Xapian | Коррекция опечаток, фасеты, «недовведённые» запросы.
-Sphinx | Синонимы со спецсимволами, "полуразделители" (blend_chars). Зоны (абзацы/предложения/теги). Инфиксы, MVA, слияние индексов (не обновляемых). Тюнинг производительности.
+Sphinx | Синонимы со спецсимволами, «полуразделители» (blend_chars). Зоны (абзацы/предложения/теги). Инфиксы, MVA, слияние индексов (не обновляемых). Тюнинг производительности.
 Solr | Почти всё, что душа пожелает (но зон нет!). Высокая расширяемость.
 CLucene | Фильтрация документов, фасеты, анализаторы, explain. Высокая расширяемость.

@@ Строка 1: / Строка 1: @@
 Так как в интернетах тема сравнения движков полнотекстового поиска не раскрыта — есть либо разрозненные комменты на хабре, либо бессмысленные сравнения от «специальных сравнительных сайтов», решил всё-таки сам сравнить [http://dev.mysql.com/doc/refman/5.5/en/fulltext-search.html MySQL FULLTEXT] vs [http://www.xapian.org/ Xapian] vs [http://sphinxsearch.com Sphinx] vs [http://lucene.apache.org/ Lucene]/[http://lucene.apache.org/solr/ Solr] vs [http://postgresql.org/ PostgreSQL] [http://www.postgresql.org/docs/current/static/textsearch.html Textsearch]. Заодно попробовал [http://sourceforge.net/projects/clucene/ CLucene], а в процессе ещё и запатчил несколько багов и нашёл несколько болячек в разных движках.
-Сравнение проводилось с точки зрения средненькой базы — тестировал на данных Багзиллы, содержащей в районе 80000 багов, текстов было ~330 мб. Со всеми движками работал из Perl’а, то есть, заодно тестировал интерфейсные библиотеки.
+Сравнение проводилось с точки зрения средненькой базы — тестировал на данных Багзиллы, содержащей в районе 80000 багов, текстов было ~330 мб. Со всеми движками работал из Perl’а, то есть, заодно тестировал интерфейсные библиотеки. ОС Debian Linux Unstable (Wheezy/Sid), процессор Core 2 Duo 3 ГГц.
 Итак, встречайте:
@@ Строка 58: / Строка 58: @@
 * Размер индекса — пишут, что примерно равен размеру данных, это не так, реально больше раза в 2. Пишут, если не хранить позиции слов в документах, станет в 2 раза меньше. Но извините, Sphinx тоже хранит позиции, а индекс у него в 2 раза меньше данных. Если прогнать <tt>xapian-compact</tt> (дефрагментация БД) — индекс таки да, уменьшается, но всё равно остаётся где-то в 1.7 раза больше данных.
 ** Ага, причина найдена — Xapian всегда индексирует и основы, и точные формы слов. Отключить индексацию точных форм нельзя, обидно, поставил на эту тему им [http://trac.xapian.org/ticket/563 баг 563].
-* Ищет быстро. Тестировал так: искал по нескольким соседним словам длиной не меньше 2 символов, в режиме STEM_ALL, взятым из заголовков багов (искал не по «ИЛИ», а «И»), причём каждое слово заменял на <tt>(слово OR title:слово OR private:слово)</tt>, то есть на поиск по трём полям вместо одного, ограничивал количество результатов 1000, и всё это на Core 2 Duo 3 ГГц.
+* Ищет быстро. Тестировал так: искал по нескольким соседним словам длиной не меньше 2 символов, в режиме STEM_ALL, взятым из заголовков багов (искал не по «ИЛИ», а «И»), причём каждое слово заменял на <tt>(слово OR title:слово OR private:слово)</tt>, то есть на поиск по трём полям вместо одного, ограничивал количество результатов 1000.
 ** В 5 потоков на 3 словах — в среднем 14 мс, максимум 135 мс.
 ** В 5 потоков на 2 словах — в среднем 29 мс, максимум 137 мс.

@@ Строка 30: / Строка 30: @@
 * Немножко бардак с интерфейсами и фичами: обновление реалтайм индекса только через SphinxQL; синтаксис поиска во всех трёх интерфейсах разный (обычный, SphinxQL, SphinxSE); штук 5 режимов поиска, из которых 4 obsolete; indexer не может перестраивать реалтайм индексы; TRUNCATE индекса через SphinxQL сделать нельзя, посмотреть, сколько в индексе записей, тоже нельзя…
 * На этом недостатки заканчиваются — есть сервер поиска, с которым можно общаться по собственному протоколу или протоколу MySQL, куча разных возможностей, индексирует и ищет очень быстро, размер индекса — примерно 1/3 данных. Может увеличиться раза в 2, если включить индексацию точных словоформ.
-* Встроены русский, английский и чешский стеммеры и препроцессоры Soundex и Metaphone (для сравнения английских слов по звучанию). Стеммеры для других языков можно тоже подключить, только нужно собирать с ключиком <tt>--with-libstemmer</tt>. Поддержка стоп-слов, разумеется, есть.
+* Встроены русский, английский и чешский стеммеры и препроцессоры Soundex и Metaphone (для сравнения английских слов по звучанию). Стеммеры для других языков можно тоже подключить, только нужно собирать с ключиком <tt>--with-libstemmer</tt>. Поддержка стоп-слов, разумеется, есть. Синонимы тоже, причём есть обычные, а есть «tokenizing exceptions», которые могут включать в себя спецсимволы. Также есть «[http://sphinxsearch.com/docs/current.html#conf-blend-chars blend_chars]» — символы, которые одновременно считаются и разделителями, и входящими в слова — например, чтобы «AT&T» превратилось в слова «AT», «T» и «AT&T».
 * Из прикольных необычных фич — умеет инфиксный поиск (для тех, кто хотел быстро искать по подстроке!), многозначные поля (MVA), умеет индексировать по абзацам и предложениям и даже по содержимому заранее заданных HTML-тегов. Также может подсвечивать искомые слова в цитатах и многое другое. Правда, MVA и инфиксы не поддерживаются (пока что?) в обновляемых индексах.
-* Индексация очень быстрая — чистая скорость с реалтайм индексом 6.7 МБ/с (загрузка SQL-дампа), с обычным индексом — вообще 12 МБ/с (загрузка [http://sphinxsearch.com/docs/manual-2.0.1.html#xmlpipe2 xmlpipe2]-дампа). «Нечистая» скорость (из Perl’а, с вычиткой данных на лету из MySQL) — 4.5 МБ/с. С инфиксами всё, естественно, сильно замедляется — 440 КБ/с, куча ввода-вывода — 10.5 ГБ, и индекс получается 3 ГБ размером на 330 МБ данных.
+* Индексация очень быстрая — чистая скорость с реалтайм индексом 6.7 МБ/с (загрузка SQL-дампа), с обычным индексом — вообще 12 МБ/с (загрузка [http://sphinxsearch.com/docs/current.html#xmlpipe2 xmlpipe2]-дампа). «Нечистая» скорость (из Perl’а, с вычиткой данных на лету из MySQL) — 4.5 МБ/с. С инфиксами всё, естественно, сильно замедляется — 440 КБ/с, куча ввода-вывода — 10.5 ГБ, и индекс получается 3 ГБ размером на 330 МБ данных.
 * Поиск вообще реактивный:
 ** В 5 потоков на 3 словах — в среднем 7 мс, максимум 75 мс.
@@ Строка 164: / Строка 164: @@
 PostgreSQL | Тезаурус, ISpell.
 Xapian | Коррекция опечаток, фасеты, «недовведённые» запросы.
-Sphinx | Зоны (абзацы/предложения/теги). Инфиксы, MVA, слияние индексов (не обновляемых). Тюнинг производительности.
+Sphinx | Синонимы со спецсимволами, "полуразделители" (blend_chars). Зоны (абзацы/предложения/теги). Инфиксы, MVA, слияние индексов (не обновляемых). Тюнинг производительности.
 Solr | Почти всё, что душа пожелает (но зон нет!). Высокая расширяемость.
 CLucene | Фильтрация документов, фасеты, анализаторы, explain. Высокая расширяемость.