давайте забенчмаркаем с tsearch, интересно все-таки. у меня под рукой сейчас есть небольшой 200MB индекс (прямой, обратный будет быстрее, очевидно) где-то на 10^6 документов на нескольких машинах (могу подобрать соответствующую). русский язык (испелл), несколько тезаурусных словарей на n*10^3 записей. вы можете подобрать что-то похожее у себя?
кстати, если атрибуты в Сфинкс это возможность добавить в запрос условия вроде and regionid = 1234 and price < 100, то тогда в tsearch это есть с самого начала, потому что это СУБД :) причем количество атрибутов неограничено, а типы данных и их индексная поддержка развита очень сильно, даже не имеет смысла сравнивать.
Вы искажаете смысл моих слов. Про базы размером в 10К записей никто не говорит, они не интересны для рассмотрения. Также никто не говорит, что нужно всегда резать гигантские резалтсеты это не так. tsearch может и миллион записей вернуть. И если вам захочется их чем-то собственным обработать, у вас будут проблемы, да. Но такие же проблемы будут и в Сфинксе, если там вообще возможно добавлять произвольную логику в поиск.
Моя основная мысль проста и спорить с ней довольно глупо: tsearch встроен в мощную СУБД и поэтому вам вместе с его богатыми возможностями доступны еще и возможности СУБД. А это значит, что вы можете писать очень гибкие запросы и делать произвольные системы на основе полнотекстового поиска например, разграничивая полномочия пользователей на чтение документов, как кто-то здесь спрашивал в комментах.
Что касается тупого сравнения кто лучше, то давайте проведем бенчмарки :) Помнится, на РИТ-2007 цифирки о Sphinx разработчиков tsearch не очень впечатлили :) Ну а что касается функциональности то tsearch практически ни в чем не уступает тоже, даже во многом опережает. Давайте в отдельной дискуссии померяемся и поговорим про 100TB базы на tsearch? :)
Для таких любопытных и практически важных :) случаев в tsearch есть gin_fuzzy_search_limit, который обрезает резалтсет на заданном уровне. Дело в том, что при низкой селективности пользователю в подавляющем большинстве случаев не важны уже даже десятки тысяч матчей. Или кто-то здесь мотает выдачу поисковиков по "стоп-слову" до десятитысячной страницы? :)
Но в целом вы правы и я не спорю у предложенного простого подхода есть ограничения. В некоторых случаях (на мой взгляд, они все же крайне редки) все же нужно анализировать гигантские резалтсеты. Но в tsearch и для них есть фишки, все зависит от задачи.
Плюс еще важно понимать, что ваши возможности с tsearch очень велики и вот почему. Он встроен в СУБД. Он работает очень быстро. Поэтому вы можете с его помощью сделать loose match по индексу, быстро вернув бОльшее кол-во результатов, чем вам нужно, а затем отобранные результаты обработать любым другим способом, добавив собственную эвристику произвольной сложности.
Это открывает удивительные возможности. Например, мало кто в опенсорс мире умеет делать нормальный быстрый suggest, потому что до недавнего времени префиксный поиск (то есть его индексная поддержка, разумеется) вообще не был нигде реализован (первыми, насколько мне известно, это опять сделали в tsearch-е, будет в след. релизе) шутка ли, поискать LIKE 'фраза%' по миллиону строк. Так вот, с помощью tsearch эта задача решается элементарно, используя упомянутый подход. Так что варианты есть всегда.
в данном случае ранк у матчей будет отличаться настолько, что вы сможете отсечь ненужные результаты. да, это не поиск по фразе, но лимитировать по расстоянию между словами в tsearch все же возможно.
Так как tsearch2 встроен в СУБД, вы можете в полнотекстовый запрос добавлять любые условия, в том числе на проверку прав пользователя читать соответствующий документ. То есть в постгресе это все делается и очень легко.
В PostgreSQL используется не только примитивный стеммер, но и морфология русского и других языков, словари синонимов и тезауруса (в том числе пользовательские), и куча других полезных фишек, с помощью которых поиск можно довести до идеального. Конечно, это не яндексовые технологии, но это отличный вариант, причем бесплатный и с открытым кодом.
да, кстати, tsearch легко масштабируется линейно до гигантских размеров, порога в несколько терабайт, как у Сфинкса, попросту нет. все дело в том, что функция релевантности у него локальна, поэтому полнотекстовый индекс можно побить на произвольное количество частей и разложить по нужному количеству машин. ну и с обратным индексом, который реализован в tsearch, по скорости выборки мало кто сравниться сможет. не знаю, правда, как с этим у Сфинкса.
По моему пристрастному мнению постгресмена, tsearch лучше. Единственный существенный плюс сфинкса при сравнении он не связан с СУБД, в некоторых задачах это очень полезно.
Если не сложно, приведите примеры, как именно вы хотели искать в tsearch и не получилось? Зачастую, многие проблемы с ним все же удается решить после тщательного прочтения документации.
Мы минимум 2 проекта крупных на нем сделали: mirtesen.ru и moikrug.ru. Еще есть hi5.com, irr.ru, rabota.ru, и куча-куча других известных сайтов в рунете и за его пределами, udaff.com, наконец. В рунете же вообще сложилось правило: что ни соцсеть, то постгрес :) Так что судите сами.
Моя основная мысль проста и спорить с ней довольно глупо: tsearch встроен в мощную СУБД и поэтому вам вместе с его богатыми возможностями доступны еще и возможности СУБД. А это значит, что вы можете писать очень гибкие запросы и делать произвольные системы на основе полнотекстового поиска например, разграничивая полномочия пользователей на чтение документов, как кто-то здесь спрашивал в комментах.
Что касается тупого сравнения кто лучше, то давайте проведем бенчмарки :) Помнится, на РИТ-2007 цифирки о Sphinx разработчиков tsearch не очень впечатлили :) Ну а что касается функциональности то tsearch практически ни в чем не уступает тоже, даже во многом опережает. Давайте в отдельной дискуссии померяемся и поговорим про 100TB базы на tsearch? :)
Но в целом вы правы и я не спорю у предложенного простого подхода есть ограничения. В некоторых случаях (на мой взгляд, они все же крайне редки) все же нужно анализировать гигантские резалтсеты. Но в tsearch и для них есть фишки, все зависит от задачи.
Это открывает удивительные возможности. Например, мало кто в опенсорс мире умеет делать нормальный быстрый suggest, потому что до недавнего времени префиксный поиск (то есть его индексная поддержка, разумеется) вообще не был нигде реализован (первыми, насколько мне известно, это опять сделали в tsearch-е, будет в след. релизе) шутка ли, поискать LIKE 'фраза%' по миллиону строк. Так вот, с помощью tsearch эта задача решается элементарно, используя упомянутый подход. Так что варианты есть всегда.
2: "Сегодня супер погода"
Запрос: "супер погода" вернет 2, но не вернет 1.
в данном случае ранк у матчей будет отличаться настолько, что вы сможете отсечь ненужные результаты. да, это не поиск по фразе, но лимитировать по расстоянию между словами в tsearch все же возможно.
конечно, имелось в виду 6 петабайт