Как писал Leom То что они морфологию не поддерживают -- понятно.
Вопрос -- а как насчет поиска по фращзам с растоянием? Из описаний я пока увидел что они ищут только по набору слов с логической комбинацией and.
Прав ли я?
Совершенно не прав. Морфология поддерживается, поиск по фразам с учётом морфологии тоже. Поиск фраз с учётом расстояния интересует только теоретиков поиска. :)
Как писал Vyacheslav Tikhonov Около 6 млн документов. Точнее скажут только они сами.
Дело не в возможностях этих БД. Поисковый индекс все равно нужно как-то закладывать в базу и создавать в ней индексы с координатами.
Я здесь неоднократно говорил, что универсальные БД не должны использоваться для поисковиков.
Мне попадались упоминания об установках aspseek и в 10, и в 50 млн. документов. Aspseek использует MySQL, примерно также как dpsearch - обратный индекс хранится в файлах на диске, всё остальное в БД.
Посмотрите cache mode в DataparkSearch (http://www.dataparksearch.org/) .
Посмотрите функцию DpsStrHash32 в DataparkSearch.
Нет ничего более субъективного, чем качество поиска, т.к. нет формального определения релевантности :)
Здесь можно моного копий наломать без особой пользы...
Берите: http://www.dataparksearch.org/ - только с .exe боюсь облом будет :), только в исходниках и только под юниксы.
Насчет теоретиков -- не знаю. Все поисковики стараются вначале ввывести те документы где расстояние между словами во фразе минимальное.
Искать с учётом расстояний и выводить с учётом расстояний - две большие разницы :)
DataparkSearch выводит с учётом расстояний, но не ищет.
То что они морфологию не поддерживают -- понятно.
Вопрос -- а как насчет поиска по фращзам с растоянием? Из описаний я пока увидел что они ищут только по набору слов с логической комбинацией and.
Прав ли я?
Совершенно не прав. Морфология поддерживается, поиск по фразам с учётом морфологии тоже. Поиск фраз с учётом расстояния интересует только теоретиков поиска. :)
Вы меня не так поняли, я не спрашивал про скорость паука, я спрашивал про скорость индексатора. Как правило ему канал в интернет не нужен.
У DataparkSearch это в одном флаконе, так что вас поняли правильно :)
Не сказал бы, что проц здесь главное, более важны толщина канала и крутость дисковой системы.
У DataparkSearch вполне получается около 180Килобайт/с (ну или около 10Мегабайт в минуту :) с 10 нитями на PentiumIV, IDE SATA RAID1, 10Mbit в Нет.
Около 6 млн документов. Точнее скажут только они сами.
Дело не в возможностях этих БД. Поисковый индекс все равно нужно как-то закладывать в базу и создавать в ней индексы с координатами.
Я здесь неоднократно говорил, что универсальные БД не должны использоваться для поисковиков.
Мне попадались упоминания об установках aspseek и в 10, и в 50 млн. документов. Aspseek использует MySQL, примерно также как dpsearch - обратный индекс хранится в файлах на диске, всё остальное в БД.
На этих движках поисковик с объемом Меты поднять нереально - база быстро ляжет.
И каков объём Меты ?
Есть подозрение, что ваши представления о возможностях MySQL и PgSQL несколько устарели :)