Тематическая поисковая система (до 1000 сайтов) - как делать?

Не совсем корректно :) Если поставить системе ограничение, что время поиска на любом запросе не должно превышать N, то можно скадать, что не зависит (поплотившись при этом полнотой). На самом деле, одной из самых больших "головных болей" сравнительно больших енджинов является физическое время seek головок (10 ms отдай и не греши на одно позиционирование :), что, естественно, будет в первую очередь зависеть от сложности входящего запроса, архитектуры системы, наличия кешей и много пр.

Ну вот упреждающий удар... Я тоже кое-что хотел рассказать на тему прунинга. В общем, получается, что только с прунингом можно не зависеть от размера базы. Но, кстати, у современных дисков среднее время позиционирования все-таки поменьше будет. Да и опять-таки если воткнуть в машину гигов 16 оперативки, то можно индекс по паре-тройке десятков миллионов типичных (но не больших веб-страниц) держать в памяти. но 50 миллионов на описанном выше железе - это, кажется, перебор. Впрочем, если я не прав, то подписываюсь на будущую публикацию, в которой будет описана поисковка Максима.

Максим, набери у себя в поисковике слово "нло" и проанализируй выдачу ;)

1. Выдаются далеко не основные сайты.

2. Они малопосещаемые (кроме четвёртого, ригелевского).

3. Они очень слабо релевантные.

Потянуть-то потянет...

Похоже, что нет индекса цитируемости сайтов, поэтому так работает. Механически что-то ищет, но координатного индекса тоже нет. Кроме того, неудобоваримые сниппеты.

В общем, критиковать можно долго.

нифига, координатный индекс - есть

Сделать правильные снипеты - очень интересная задача, завязанная и на координатный индекс и на структуру хранения исходников. Текущее состояние - наследие прошлого, процесс идёт.

Критиковать конечно можно, но пока рановато, betta версия как никак 🙄

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

Вполне потянет и на бытовом серваке, ему только под key buffer метров 500-600 дать, и в multi режиме пускать (в single не потянет конечно). Ну и из базы главное ничего не удалять, только вставлять/обновлять.

Поиск конечно будет мягко говоря небыстрым, но при указанных 500-3000 посетителей в день (которые не факт что много запросов делать будут) - вполне нормально.

Для меня это равнозначно понятию не потянет. Поскольку поиск может идти 10-40 секунд в зависимости от количества ключевых слов, интенсивности процесса индексирования и фрагментированности базы, пользователь может просто не пользоваться таким "тормозом". А если два поиска почти одновременно? Что вешать табличку подождите, или батчи пускать ? :-) Кстати, на фоне процесса индексирования скорость поиска падает весьма заметно. Опять-таки, что значит не удалять? Это как-то несерьезно :-)

Фактически рано или поздно нужно идти путем одного перца:

делать дамп базы и заливать все с нуля. Тогда фрагментация нулевая и ищет довольно шустро. Была анонсирована скорость порядка 3 секунд на двух миллионах. Но как только индексер как следует перелопатит базу многосёрча пару раз, время поиска опять вырастет до 10-40 секунд. К тому же у многосёрча есть фундаментальная проблема, опять-таки, связанная с раскладкой индекса по реляционным таблицам. Индекс получается огромным в 500-600% от размеров текста и из-за этого весьма плохо кешируется. На базе в 1 млн документов вполне себе могут существовать запросы, которым мало 500-800 мегов кеша.

10-40 секунд - это в single режиме наверно только (хотя в этом режиме такой объем вообще не потянет). В multi - быстрее, еще есть режим blob (создается read-only копия индекса) - там вообще получается по disk seek'у на слово из запроса.

Одновременные поиски тоже сами по себе проблемы не создают - разве что на ATA дисках параллельные операции хреновенько работают.

Индексирование большую часть времени базу не трогает - индексатор накапливает данные себе в память, и потом большими порциями заливает.

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

Да не надо дампов никаких делать. В multi режиме при обсуждаемом объеме будет 255 таблиц мегабайт по 50, можно по крону равномерно обходить, и вызывать optimize для каждой, выделять еще мегабайт 100 под эти операции, и все нормально, без отрыва от производства. :) Ну секунд на 5 каждая таблица будет блокироваться.

В общем я конечно согласен, что полноценный поисковик лучше справится. Но у mnogosearch преимущество - очень низкие затраты, как по деньгам, так и по времени.

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