Это согласуется с моим опытом на последней версии :-)
Может и стало быстрее, раза в два, только это все равно достаточно скромная скорость. И у DPsearch при его текущей архитектуре как раз то самое пресловутое ограничение в 5-7 мс * N, где N от пяти до десяти. Пока все в кеш влезает, то может скорость и будет 900 гб в час, а как только кешоверфлоу, имеем 0.5 - 1 документа в секунду (или примерно 10кб/c) при почти 100% загрузке проца и диска.
А это больше похоже на правду.
Да я в общем-то разделяю в какой-то степени скептицизм по поводу проанонсированных цЫфр, просто хочу сказать, что это отнюдь не невозможно. А под публичными коллекциями часом не ромиповская имеется в виду? Так там меньше миллиона урлов.
Вот неправда, было это в соответствующей теме. И, кстати, вполне себе нормальная скорость поиска.
Ну и небольшая поправочка: индексы, даже промежуточные были сжатыми, алгоритм распаковки подбирался быстрый, собственно это был VBC (variable byte coding). Он отличается тем, что распаковывает-упаковывает заметно быстрее, чем идет запись на диск. Возможно, что за счет этого достигается определенный доп выигрыш.
Я вот недавно тестировал: 3.5 документов (по тексту примерно в два раза меньше, чем средний вебовский документов, или примерно как два млн средних HTMLей) со специальным добавочным индексом, размер которого превышает исходный раз в пять-шесть индексируются часов 20. На слабеньком гигагерцовм пне с 512к ОЗУ и ОДНИМ IDE диском. Собственно поделим это число на пять, получаем 4 часа без дополнительного индекса. Или два часа на млн стандартных вебовских документов. Похожие цифры получаются? Как раз была реализована стратегия параллельного слияния нескольких индексов.
Ну и потом, даже если господин Леом где-то проколося в ошибках измерения раза так в 2-3. То даже с такой поравкой скорость индексирования более чем удовлетворительная.
Кстати, насчет 7 мс я тоже в корне не согласен. Это только время позиционирования головки. В случае последовательного считывания-записи на диск все совсем по-другому. Чисто теоретически можно строить индекс со скоростью сравнимой со скоростью записи на диск. Особенно если один винт на чтение работает, а второй на запись.
Сначала строим N инвертированных индексов в памяти записываем на диск. Потом за один проход их читаем с одного диска и сливая пишем на другой диск. Опять-таки, если читать каждый раз большими кусками по несколько мегабайт все будет работать со скоростью чтения-записи. Считанные куски естественно сливаем в памяти, записываем на диск.
Разбор документа тоже можно делать довольно быстро. Если парсер, конечно, не тормозит. Другое дело, что достижение такой высокой скорости на практике дело весьма трудоемкое, требующее высококвалифицированных программистов и быстро работающего парсера.
некоторые поисковики, так долго индексируют, переиндексируют, что доджаться того светлого момента, когда можно искать практически нет никакой возможности.
Зодчий, Вы, АПСОЛЮТНО, АПСОЛЮТНО не правы. Тема-то подымалсь, но проблема в ней обсуждалась немножечко другая (если не сказать совсем другая). Почему у человека не находятся результаты по некоторым ключевым словам. А ответ простой: потому что искать нужно в BOOLEAN mode. Вопрос второй: релевантность результатов. Конечно, для больших баз будет не очень релеватно, потому что поиск без учета расстояний. Но если добавить морфологию, чуть-чуть подкрутить релевантность, чтобы тайтл шел с большим весом, то для 50-100 тысяч записей вполне пойдет. Вопрос третий про лайк. Это неправда, в MySQL реализована векторная модель. Читайте не русскую документацию, а вот здесь. В частности, это означает, что LIKE, скорее всего, будет работать ощутимо медленнее.
MySQL fulltext search вполне себе рулит.
Я вот его собираюсь использовать в ближайшее время вот здесь http://punto.ru/ctl. Точные предел предсказать сложно, но несколько десятков тысяч страниц должен потянуть без проблем, см, например, отзывы здесь (как раз про пятерку) .
