поиск по сайту (статические страницы)

[mar]

собственно, subj
имеется сайт. на нем куча статей (статика). Народ просит поиск, может быть придется заняться.
варианты:
1)- переводим статику в php+база, пишем движек для добавления нового (ну, и чтения старого, естественно :) (может быть не пойдет по многим причинам, одна из которых - не хочу лишать куска хлеба тамошнего webmaster-а :))
2)- делаем индексацию и скрипт переиндексации. Webmaster, кдадя очередную статью запускает скрипт и идет переиндексация базы.
2-1- вопрос: как лучше хранить индексы? в текстовом файле-словаре, или в БД?
2-2- если в бд, то в принципе возможно не переиндексация, а доиндексация. Идеи?
3)- делаем просто перевод текста статей в бд и используем полнотекстовый поиск mysql (кто что хорошего-плохого мог бы о нем сказать?) Делаем скрипт, при запуске которого идет добавление текста новой статьи в БД.

Кому какие идеи нравятся/не нравятся? Какие еще идеи?
Спасибо :)

[Vlad Drakula]

mar
я бы делал так:
1) берем страницу
2) выризаем в ней теги
3) создаем список слов встретившихся на этой странице (все повторяющиеся выкидываем)
4) заносим в базу
5) неплохо бы сделать фул индекс на это поле.

mar
но это все так... теория... тут очень много значит размер сайта и то как часто будут пользоваться поиском...

[mar]

Vlad Drakula
ну то есть тебе нравится путь - делаем индексацию c использованием базы? + полнотекстовый поиск, что даст возможным отслеживать словофоры?
Размер... Большой там размер. (Правда картинок много, - это я размеры каталоговсмотрю, - но и текста полно. Причем ведь еще напишут :))

С другой стороны, если целиком текст хранить, можно задействовать полнотекстовый поиск и искать в том числе по точному совпадению кусков фраз

Добавлю, пожалуй, пункт 4:
- гибрид 2+3 : то есть храним и словарь и весь текст (интересно, а база не рухнет... :))

[Vlad Drakula]

mar
все зависит еще и от сервера...
500-1000 мб текста это не так много!

[mar]

сейчас они сидят на nodex-е ;)
О своем серваке думают, но, видимо, где-то через год (по финансовым соображениям,- им сейчас не до того).

[archy]

mar
может mnogosearch спасет?

[mar]

archy
может быть :) Ты с ним дело имел?

[archy]

нет, но не думаю, что там могут быть сложности... можно и htdig испытать

[mar]

archy
на хостинге могут :( - когда поставить нельзя. О! супер phpinfo() выдало --with-mnogosearch=/usr/local/mnogosearch
(второй возможный облом на чужем хостинге может быть с кодировками - сайт на cp1251. Я тут на днях развлекалась postgres-ом для извращенцев - работе под win. В результате все удалось, даже upper/lower заработали и словари в tsearch2 удалось подключить, но эмоций была масса ;))
так что уже имеется и в php вкомпилен. Пойду почитаю документацию :)

Тогда еще один вопрос:
- пункт 6 за и против mnogosearch

[vadimiron]

А может самому ничего не писать, а воспользоваться внешним поисковиком??
Например Google
Делаем форму, и запрос поиска посылаем сайту Гугла, я такое на многих сайтах видел.
Можно обрабатывать страницу результатов Гугла, чтобы под свой дизайн подогнать, так как у этих страниц стандартная разметка
По моему такое решение наиболее быстрое, нетребовательное к собственным ресурсам и наиболее гибкое

[Vlad Drakula]

vadimiron
да можно пользоваться гуглем, но для комерческого сайта это не очень хорошо....
есть конечно вариант платного использования гугля, но я не думаю что это подходящий вариант...

mar
главное чтобы поиск работал не так как на IXBT , а то там второй запрос поиска кладет базу нафиг...

[mar]

vadimiron
тот же гугль на втором шаге поиска вынесет на свои страницы. Помнишь, как в конце жизни старого движка осзона было? Что не есть гут :)
Vlad Drakula
:) ну я пока только прикидываю. Тот же mnogosearch на том же nodex-е стоит, но, насколько я понимаю, один на всех. Попросила webmaster-а сайта списаться с техподдержкой и узнать, как к нему обращаться
А полнотекстовый поиск на mysql интересен, но боюсь, не тяжел ли в обращении... (никогда с ним не работала, так что своего +/- опыта нет)

[Vlad Drakula]

mar
в принципе там ничего сложного вроде нет...
кстати раз тебе больше нравится постгри, так может его использовать будешь а не MySQL ?
(доплата коло 0,5$ в месяц)

тяжелость выясняется на предварительных тестах....

mar
всекогда то в первый раз!!!

[mar]

Vlad Drakula
тяжесть в обращении - имелось в виду не написание запросов, а загрузка сервака :tongue:
по поводу постгреса, - у меня там на mysql (делалось под предыдущего хостера) крутится форум с поиском, страницы юзеров (клуб при форуме), записные книжки юзеров (при том же форуме) и некоторый задел для идей, которые пока озвучены, но не заказаны. Миграция на постгрес на боевом серваке с достаточно большой посещаемостью и к тому же коммерческими обязательствами, - мне, пожалуй, при всем любви к нему (постгресу то бишь :)) - не улыбается :shuffle:

[Vlad Drakula]

mar
а зачем мигрировать... можно использовать и то и другое... т.е. иметь и MySQL И постгрее....

mar
я сторонник тестирования...
т.е. есть идея, я ее воплощаю в наброске... произвожу тестирование... понимаю плоха она или хороша...
(потом пишу тест под нагрузкой...) если производительность меня устроила то пиши вчистую... если нет то исправляю и опят начинаю тестировать...

[mar]

ну, быстрее все-таки все вместе хранить (скажем, чтобы тот же поиск и по сайту и по форуму разом шел)
Может, я когда-нибудь все на постгрес там и переделаю, но только после того, как у них будет выделенный сервак (а у меня - время :(). Хочется, если уж использовать возможности нормальной :) СУБД, то и тюнинг там делать такой, какой захочется

[mar]

значит так :)
хотела написать - "не прошло и пол года", но пол года с тех пор уже прошло. Выдался свободный день, сделала таблицу с индексом по fulltext, скрипт, загоняющий в нее данные статических страниц и поиск к этому делу. Запрос элементарный:
SELECT url, title, MATCH (text) AGAINST ('.....то, что запросили...') AS relevant
FROM full_text
WHERE MATCH (text) AGAINST ('.....то, что запросили...')
Двойной запрос MATCH (text) AGAINST, судя по dev.mysql.com (http://dev.mysql.com/doc/refman/4.0/ru/fulltext-search.html), выполняется 1 раз, но зато выстраивает ответ по релевантности, отсекая 50% границу. Короткие слова, слова частовстречающиеся не индексируются. Если слово встречается на всех страницах многократно, оно игнорируется. Работает, на мой взгляд весьма быстро (хотя объем относительно неболшой - весь текст уложился в 11-12 Мб): запрос отыгывает за <= 1 мсек. В общем, мне нравится :)
Посмотреть настройки MySQL, касаяющиеся полнотекстового поиска можно: SHOW VARIABLES like '%ft%';
Статьи:
http://dev.mysql.com/doc/refman/4.0/ru/fulltext-search.html - документация по 4.0 на русском
http://dev.mysql.com/doc/refman/4.1/en/fulltext-search.html - документация по 4.0 на английском
http://xpoint.ru/know-how/PHP/GotovyieResheniya/Poisk?1 - "Поиск по сайту" - пример скрипта-индексатора сайта

[Vlad Drakula]

mar
я пробовал fulltext, в каталоге программ он вел себя не лучьшим образом, по этому мне пришлось писать свой собственный поиск + свою собственную индексацию.

[mar]

Vlad Drakula
ну, индексатор и поиск мне тоже писать пришлось =) Я просто показала запрос, покрывающий бОльшую часть потребностей посетителей сайта. В принципе мне приходилось писать и разные поисковые системы, но в данном случае fulltext мне действительно понравился. (Посмотрим, правда, что скажет тестирование) Вопрос к тебе - можешь поподробней написать, что именно тебя не устроило? Если можно с примерами. (Может, есть какие-то незамеченные мной грабли)

[Vlad Drakula]

mar
ну... мне он полностью не подошол!

fulltext ищет только слова целиком, а мне нужно было чтобы и части слов искал.