Патч для использования MySQL fulltext индекса в index_search

[Valery Romanchev]

http://bugs.typo3.org/view.php?id=5089
ускорение во много раз, что не удивительно.

[Дылгеров Ц.В.]

Помимо этого патча нужно применить две команды:

ALTER TABLE index_fulltext ADD FULLTEXT (fulltextdata);
ALTER TABLE index_words ADD FULLTEXT (baseword);

[Valery Romanchev]

у меня не получилось настроить нормально работу этого патча
(вропчем не очень много времени на это потратил)
т.е. что-то он искал, но не для всех параметров

... в ближ. время буду с этим разбираться снова.

[razawa]

Есть результаты использования патча? Действительно заметно?

[Valery Romanchev]

Есть результаты использования патча? Действительно заметно?
почитайте в dev листе
очень скоро уже сделают не патч, а нормальную версию index_search
ускорение в десяток раз или больше, хотя все равно долго - 4 сек на нескольких тысячах документов помоему

[Zotto]

http://bugs.typo3.org/view.php?id=5089
ускорение во много раз, что не удивительно.

Это как раз тот самый случай, когда принцип "всё-в-одном" не прокатывает. indexed_search даже рядом не стоять и тыщу лет не угнаться ни по скорости, ни по качеству за MnoGoSearch и его форком DataparkSearch. Есть и расширение в TER на тему.

[Valery Romanchev]

Это как раз тот самый случай, когда принцип "всё-в-одном" не прокатывает. indexed_search даже рядом не стоять и тыщу лет не угнаться ни по скорости, ни по качеству за MnoGoSearch и его форком DataparkSearch. Есть и расширение в TER на тему.
не все так хорошо с MnoGoSearch, как кажется на первый взгляд
чтобы его использовать надо пересобирать PHP (это стремная операция, в результате можно получить нестабильную работу - у меня такое один раз было)

На счет качества поиска - это тоже вопрос. Несмотря на то, что indexed_search не поддерживает русскую морфологию, он индексирует действительно все и показывает результаты красиво - т.е. субъективно вполне рулит.

Из других интересных решений - есть сфинкс http://sphinxsearch.com/

[Pavel Antonov]

надо пересобирать PHP

Главное что для многих хостингов это просто не приемлемо.

[Zotto]

Главное что для многих хостингов это просто не приемлемо.

Немного по-другому. Если уж дошло до mnoGoSearch и т.п., то хостинг там у людей примелемый, как правило. Точно так же, кстати, и с TYPO3 вообще. Не здесь ли в wiki пишется, что если у хостера нету ImageMagic, "ищите другого хостера".

[Zotto]

не все так хорошо с MnoGoSearch, как кажется на первый взгляд
чтобы его использовать надо пересобирать PHP (это стремная операция, в результате можно получить нестабильную работу - у меня такое один раз было)

На счет качества поиска - это тоже вопрос. Несмотря на то, что indexed_search не поддерживает русскую морфологию, он индексирует действительно все и показывает результаты красиво - т.е. субъективно вполне рулит.

Из других интересных решений - есть сфинкс http://sphinxsearch.com/


Если заметили, ситуация в точности, как и с этим форумом. Года два назад, помню, было обсуждение. И что-то вы тогда не очень выбрали "некузявый" chc_forum :) Так и здесь. Я, ведь, не говорю: "кому и кобыла - невеста", и вообще не против indexed_search. Если "сойдёт, что под рукой" или "хостинг не тот"... Ну, скажем, бывает, что вставляют и поисковую форму Гугля. Тоже ничего. Всякому есть место под солнцем. И дело даже не в том, что "indexed_search не поддерживает русскую морфологию" (хотя, согласитесь, это страшный диагноз для поисковика в русскоязычном пространстве), но для реально контентного ресурса нужен реально хороший поиск. Пусть indexed_search механически индексирует "всё подряд", но он не сможет на (мой) запрос "дьяволу" ответить "враг человечества", и, вряд ли, за секунду выдаст (на третьем пне, по ссылке http://www.43n39e.ru/ с офсайта)...
Результаты поиска: синергетика: 89 Время поиска: 0,429 сек.
Проиндексировано 1.166.577 страниц, 1.273.559 сайтов, 27.455 Гб
...как это делает, например, DataparkSearch (мой выбор). И в этом смысле просто некорректно говорить о "качестве поиска" indexed_search. Уж простите. +Достаточно взглянуть на список фич (см. http://www.dataparksearch.org/index.ru.html). Сложно с ходу придумать "что-нибудь эдакое", чего ещё потребуется от поисковой машины. Поэтому у меня тоже "субъективное", т.к. однажды, по необходимости сильно углубился в DataparkSearch и то, что он делает, просто ошеломляет. После этого indexed_search (как часть TYPO3) остался мне симпатичен, но я обрёл истину, и эта истина дороже. Проиндексировал тогда гигов 10 одной известной библиотеки (приобретал). По ходу попробовал большинство поддерживаемых протоколов/парсеров/фич. Была свалка pdf/doc/latex/html/plain/кодировки в том числе - всё вперемежку. Был только один сбой, когда надо было разбор/определение кириллических кодировок в plain-текстовых файлах с одним-двумя словами (т.е. считанные байты в файле). Попросили, многоуважаемый Maxime там что-то подвинитил, стало работать и это. Подключение словарей, синонимы, категории... Кстати, о выводе результатов, можно и "гуглеобразное" (--enable-googlegrp), и, как хочешь, короче. Да что там говорить... Конечно, у любого софта есть недостатки. Вроде известной "фичи" mnoGoSearch - индексировать файлы с лимитом по количеству слов (из-за чего и пришлось в нашем случае от него отказаться, но из-за чего сам mnoGoSearch не стал меньшеSearch'ем). Это пример. Ранее это было ограничение на "64K words", сейчас он пофиксил в сторону увеличения, но всё равно ограничение. Это чудовищно для утилиты, работающей с текстом, - допускать, что какой-то текст будет просто... игнорироваться. Дело прошлое, но. Пытался там на форуме донести своё, мягко говоря, предположение, что это не есть правильно. Что, например, для работы с научными текстами критичен каждый байт. Что вы думаете? Получил пинка под зад. Прекратите, говорит, флудить. Здесь уж лучше indexed_search, который "индексирует всё". А насчёт PHP - честно говоря, я --enable-phpmodule не делал, он там не особо-то и нужен, если search.cgi итп, но и пересобрать же можно всегда в рабочем порядке. И ничего оно не стрёмное (для того, ведь, и предназначенное). Я в такие ситуации не попадал, чтобы php... А Datapark-/mnoGo-, то их пересборка "под себя" - по любому. В общем и целом, разговор "за поиск" не имеет смысла. Хоть, и называется TYPO3 в первой части - CMS, а с большими массивами _настоящего_ контента - библиотеками, научной литературой мало кто серьёзно работает. Соответственно и запросы (спрос/предложение) к поиску и другим лингвоштукам. Есть, вот, один-одинёшенек SixPack для BibTeX'а, да экст latexmath, и на запрос "dictd" в TER'e - Sorry, your search had no results. И всё. Это наглядная иллюстрация общего уровня, комментарии не требуются.

[Pavel Antonov]

По-моему к концу текста, уважаемый Zotto сам забыл про что писал... я как-то тоже потерялся... мысль не понял.

Мое мнение по вопросу, для продолжения дисскусси, а то после такого сообщения никто сюда больше писать не будет (не понятно про что :D):



Indexed_search в текущем состоянии ужасен - подходит для сайтов в 100 страниц. Из плюсов - воткнул и работает. Минусы - медленный.
Indexed_search переработанный должен гарантировать прирост производительности. Плюсы те же. Но прирост производительности не очень большой. Сайты в 500-1000 страниц. Минусы - медленный.
MnogoSearch и же с ним. Морфология, быстрый. Минус, большой - требуется пересборка PHP. Подойдет только для собственных серверов или VPS, так как на хостингах такую штуку придется поискать. И не надо сравнивать с ImageMagick. IM - стандарт де-факто, который умудряются не ставить только косорукие полу-студенчиские хостинги, с которых надо бежать впереди своего визга! А ради 0,01% пользователей нагружать сервер спец сборкой PHP c MnogoSearch ни один хостинг не будет. Из плюсов - в TER есть модуль интеграции с TYPO3 (как работает? никто не видел...). Для сайтов с гигабайтами информации.
Sphinx и ему подобные (Яндекс.Search кстати). Не требует пересборки PHP, отдельное, самостоятельное приложение. Морфология, гигабайты. Многие кто пробовал так же и MnogoSearch говорят что Sphinx лучше (почему не знаю, интересно - ройте). Можно собрать на любом хостинг, где есть gcc и использовать через cgi. Напрямую индексирует таблицы БД, настраиваемые шаблоны. Минус - никакой интеграции с TYPO3.

Резюме: Маленький сайт - Indexed_search, ибо вам все просто и не надо извращатся. А для остальных пока идеального решения нет... Готовьте напильник побольше... и выбирайте что-нибудь :confused:

[Zotto]

Как всегда (для чего-то) усложняете. Что касается mnоGo- и DataparkSearch-, никаких "напильниов" им не надо, ибо это mature-софт, который без проблем устанавливается и настраивается. Рабочие конфиги, rpm'овские спеки/rules для deb, рус. док-ия, поддержка - ВСЁ ЕСТЬ. Настройка "под себя" - другое дело, но там нужен не напильник, а правильно поставленная задача, голова и чтение оригинальной официальной документации на русском языке. По п.3 - нет у них PHP в библиотечных и пр. зависимостях (+сколько разных БД поддерживают, чтобы так упираться в php, вы только подумайте немного). Программа mnoGoDearch (Datapak- уж точно) не есть равно php.net/mnogosearch и mnogosearch_1.0.2.t3x из TER'а. И вставить форму (search.cgi + нарисовать темплейт) в TYPO3 - будет тот же эффект и таки решение проблемы. Если, конечно, речь _о качественных индексации и поиске_ доступными средствами.

[Nobody]

не все так хорошо с MnoGoSearch, как кажется на первый взгляд
чтобы его использовать надо пересобирать PHP
Не надо. Надо скомпилировать экстеншн для ПХП (динамическую библиотеку). Её можно подгружать через dl().