вот я тоже считаю, что если это нормально делать, а не левой ногой, то это займет нормальное время. потому что надо обязательно
а) Нужно распределять странички, проверять дубликаты и опять-таки считать индекс цитирования. если одна машина не справится с такой работой по объему, то децентрализованная разработка такой фичи - это не просто.
а1) Если это нужно для форума, то придется вкручивать еще какой-нибудь попьюлэрити линк
б) реализовать какой-то там апи для хождения на отдельные машины
и очень желательно
в) как-нибудь отрезать индексер от поисковых машин, чтобы он вертелся на отдельной машине
г) Сделать load balancer и репликацию поисковых баз. И что-то придумать на случай упадания отдельных машин.
а потом все это протестировать, написать скрипты для нагиос. геморрой, короче.
да, и кстати помнится мне, что aspseek не умеет ничего индексировать локально (а-ля file:///) и из базы :-) так, например, для file:/// я сам дела изменения, отправлял киру, но поскольку разработка в то время уже пр. не велась, то кажется, эти изменения в релизную версию и не включили :-)
угу, кстати, в отрыве от мейкфайла, компилятора и платформы это и не баг вовсе, а так непортабельность. кто знает, может в мейкфайле было
CXXFLAGS += -funsigned-char
CFLAGS += ..
CPPFLAGS += ..
Ох, жеж бл@ть. Я бы, кстати, за это уволил разработчиков языка Си. За то, что они разбросали такие шикарные грабли. Шучу, конечно. Не делает ошибок известно кто. Печально то, что на такие и аналогичные грабли регулярно (иногда случайно) наступают не только неопытные, но и весьма зрелые люди. Впрочем, этот пример потдверждает мой тезис, что на языках Си и Си++ нельзя научиться писать быстро.
Интересная темка, а если у меня английская часть сайта лежит в подкаталоге english. Я сначала внес английскую ссылочку. А потом месяца через 1.5 и русскую, которая на корень сайта. Может ли это считаться спамом?
Кстати, MySQL full text search может быть не лучшим решением. Там у нее в основе лежит векторная модель (поиск кажется последовательный перебор) со своими тараканами.
баян, конечно, но от себя добавил бы, что общая алгоритмическая подготовка, в частности в области сжатия данных, дерево- и хеше-строения была бы большим плюсом.
я Вам там сообщение в личку послал, думаю, что нам уже хватит тут офтопить :-)
Пардон, может мы говорим о разных вещах? Запускать я его пока не пробовал. Только смотрел исходные тексты. Имел в виду то, что скачивается по адресу http://www.apache.org/dyn/closer.cgi/lucene/nutch/.
Там архив действительно под 50 метров, но из них java файлы занимают 2 с чем-то мегабайта, а остальное скомпилированные jar файлы. Я исхожу из соображений, что если коды открыты, то они все и должны скачиваться в одном архиве. Может, я конечно, чего-то недопонимаю.
опять-таки запускать я его только собираюсь, но если честно, то не понимаю какие страшные проблемы может вызвать хороший код такого не очень большого объема (2.5 мега). хотя, опять-таки, повторюсь может там действительно не все исходники выдаются?
ну, хорошо, убедили. действительно, новая, хорошая фича.
5.2.2. Cache mode word indexes structure
The main idea of cache storage mode is that word index and URLs sorting information is stored on disk rather than in SQL database. Full URL information however is kept in SQL database (tables url and urlinfo). Word index is divided into number of files specified by WrdFiles command (default value is 0x300). URLs sorting information is divided into number of files specified by URLDataFiles command (default value is 0x300).
но все-таки прошу обратить внимание, что этой фичи нет в mnogosearch'е!
Вы все-таки малость преувеличиваете масштаб бедствия. :-) Современный поисковик, особенно если в нем не изобретать велосипед, а использовать готовые либы и технологии, вроде iconv, corba и j2se довольно-таки кондовая штука. Вот сейчас посмотрел всего два мега исходного джава кода. Абсолютные пустяки. Все остальное, это уже скомпилированные бинарные jar-файлы. А вот, кстати, о каком скрипте идет речь в Вашем сообщение?
