Патч для использования 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]

Сообщение от razawa

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

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

[Zotto]

Сообщение от Valery Romanchev

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

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

[Valery Romanchev]

Сообщение от Zotto

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

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

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

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

[Pavel Antonov]

Сообщение от Valery Romanchev

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

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

[Zotto]

Сообщение от Pavel Antonov

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

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

[Zotto]

Сообщение от Valery Romanchev

не все так хорошо с 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. И всё. Это наглядная иллюстрация общего уровня, комментарии не требуются.