Форум больше не используется. Присоединяйтесь к каналу #community-ru в Slack for TYPO3 community |
|
01.03.2007, 21:09 | #1 |
Administrator
|
Патч для использования MySQL fulltext индекса в index_search
http://bugs.typo3.org/view.php?id=5089
ускорение во много раз, что не удивительно. |
03.08.2007, 12:08 | #2 |
Senior Member
|
Помимо этого патча нужно применить две команды:
ALTER TABLE index_fulltext ADD FULLTEXT (fulltextdata); ALTER TABLE index_words ADD FULLTEXT (baseword); |
03.08.2007, 12:26 | #3 |
Administrator
|
у меня не получилось настроить нормально работу этого патча
(вропчем не очень много времени на это потратил) т.е. что-то он искал, но не для всех параметров ... в ближ. время буду с этим разбираться снова. |
04.06.2008, 12:23 | #4 |
Senior Member
|
Есть результаты использования патча? Действительно заметно?
|
05.06.2008, 01:11 | #5 |
Administrator
|
почитайте в dev листе
очень скоро уже сделают не патч, а нормальную версию index_search ускорение в десяток раз или больше, хотя все равно долго - 4 сек на нескольких тысячах документов помоему |
16.06.2008, 22:36 | #6 | |
Новенький
Регистрация: 02.03.2006
Сообщений: 26
|
Цитата:
|
|
16.06.2008, 23:39 | #7 | |
Administrator
|
Цитата:
чтобы его использовать надо пересобирать PHP (это стремная операция, в результате можно получить нестабильную работу - у меня такое один раз было) На счет качества поиска - это тоже вопрос. Несмотря на то, что indexed_search не поддерживает русскую морфологию, он индексирует действительно все и показывает результаты красиво - т.е. субъективно вполне рулит. Из других интересных решений - есть сфинкс http://sphinxsearch.com/ |
|
17.06.2008, 02:09 | #8 |
Senior Member
|
Главное что для многих хостингов это просто не приемлемо.
|
17.06.2008, 08:02 | #9 |
Новенький
Регистрация: 02.03.2006
Сообщений: 26
|
Немного по-другому. Если уж дошло до mnoGoSearch и т.п., то хостинг там у людей примелемый, как правило. Точно так же, кстати, и с TYPO3 вообще. Не здесь ли в wiki пишется, что если у хостера нету ImageMagic, "ищите другого хостера".
|
17.06.2008, 08:04 | #10 | |
Новенький
Регистрация: 02.03.2006
Сообщений: 26
|
Цитата:
Если заметили, ситуация в точности, как и с этим форумом. Года два назад, помню, было обсуждение. И что-то вы тогда не очень выбрали "некузявый" 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. И всё. Это наглядная иллюстрация общего уровня, комментарии не требуются. |
|