Как писал Evg http://aspseek.itmag.ru/filemanager/. В нем исключены (проверял) смешения файлов от разных версий.
Сообщать о багах, ошибках желательно аналогично на
aspseek.itmag.ru
Эффект тот же, не собирается.
А куда на aspseek.itmag.ru сообщения о багах постить, там ведь только форум ?
Как писал Evg Дело не только в цифре, которая показывается в результатах поиска. Но и во времени обычного отображения страницы.
Если бы при 5 миллионах документов разница была бы 1-2 секунды, то возможно об этом я и не заговорил.
Однако разница была в разы.
На моей базе время, затрачиваемое на построение цитат, обычно больше времени, затрачиваеемого на собственно поиск документов.
А эффект получается таким: dataparksearch сначала строит цитаты для всех выводимых документов, а потом собвенно начинает выводить результаты, aspseek же строит цитату для первого документа, потом выводит кусок страницы с эти результатом, потом начинает строить цитату для второго и т.д. В результате веб-сервер у aspseek начинает раньше отдавать страницу клиенту...
Как писал Vyacheslav Tikhonov Либо предоставьте ссылки, где мои "заявления" не соответствуют действительности, либо извинитесь. То, что я не люблю поисковиков на СУБД - это факт, однако чтобы говорить об этом подобным образом, нужны убедительные аргументы, которые меня опровергают.
Итак?
Я не хочу вступать с вами в никакие разборки, если вас действительно интересует именно этот вопрос - воспользуйтесь поиском по форуму, - в тех местах, где я счёл нужным сделать, а вас поправил. Могу вам напомнить, что в одном из топиков, вы сами признались, что последний раз смотрели на mnogosearch пару-тройку лет назад, - это уже значительно устаревшая информация, именно не соответсвующая действительности...
Как писал Evg Если брать 300 т. документов, то по скорости индексации DataparkSearch и ASPseek приблизительно одинаковы с незначительным опережением ASPseek.
При больших объемах разница достаточно заметна даже на глаз, тут я говорю не о секундах (еще раз повторяюсь, к сожалению, под рукой нет точных данных).
Что же касается времени поиска, то чем больше объем «индекса» тем вперед быстрее вырывается ASPseek далее идет DataparkSearch…
Время расчёта релеватности документов входило в сравнение.
У DataparkSearch были убраны те секции, которых нет у ASPseek (кстати, это на мой взгляд один из недостатков данной системы)
Я тестировал DataparkSearch и ASPSeek примерно на одинаковых базах в 300-350 тыс. документов. Скорость индексации действительно была примерно одинаковой с незначительным преимуществом ASPSeek. Но DataparkSearch при это ещё строит матрицу ссылок между документами, чего не делает ASPSeek. Похоже именно из-за это матрицы и начинаются тормоза при большом количестве документов.
По скорости поиска: а как вы её измеряли ? Дело в том, что эти поисковики по-разному считают цифру, которую выводят в качестве времени поиска. ASPSeek выводит время нахождения собственно документов, DataparkSearch плюс к этому еще учитывает время построения цитат по словам из запроса.
Как писал Vyacheslav Tikhonov Прошу прощения за оффтопик. Zute, судя по всем вашим постам с обязательным упоминанием DataparkSearch, вы его разработчик?
Судя по вашим заявлениям об этих системах (ASPSeek, mnogosearch, dataparksearch), несколько далёких от действительности (ну или от того, что я видел и тестил лично)... :)
http://aspseek.itmag.ru/filemanager/.
В нем исключены (проверял) смешения файлов от разных версий.
Сообщать о багах, ошибках желательно аналогично на
aspseek.itmag.ru
Эффект тот же, не собирается.
А куда на aspseek.itmag.ru сообщения о багах постить, там ведь только форум ?
gmake вместо make
без разницы, эффект тот же...
configure именует себя 2NET v.1.0
по-прежнему не собирается на FreeBSD...
http://aspseek.2net.info/ - ?
WordNet http://www.cogsci.princeton.edu/~wn/
Есть в портах FreeBSD, используется в kde и koffice - скорее всего есть и в Линуксах.
Дело не только в цифре, которая показывается в результатах поиска. Но и во времени обычного отображения страницы.
Если бы при 5 миллионах документов разница была бы 1-2 секунды, то возможно об этом я и не заговорил.
Однако разница была в разы.
На моей базе время, затрачиваемое на построение цитат, обычно больше времени, затрачиваеемого на собственно поиск документов.
А эффект получается таким: dataparksearch сначала строит цитаты для всех выводимых документов, а потом собвенно начинает выводить результаты, aspseek же строит цитату для первого документа, потом выводит кусок страницы с эти результатом, потом начинает строить цитату для второго и т.д. В результате веб-сервер у aspseek начинает раньше отдавать страницу клиенту...
Либо предоставьте ссылки, где мои "заявления" не соответствуют действительности, либо извинитесь. То, что я не люблю поисковиков на СУБД - это факт, однако чтобы говорить об этом подобным образом, нужны убедительные аргументы, которые меня опровергают.
Итак?
Я не хочу вступать с вами в никакие разборки, если вас действительно интересует именно этот вопрос - воспользуйтесь поиском по форуму, - в тех местах, где я счёл нужным сделать, а вас поправил. Могу вам напомнить, что в одном из топиков, вы сами признались, что последний раз смотрели на mnogosearch пару-тройку лет назад, - это уже значительно устаревшая информация, именно не соответсвующая действительности...
Если брать 300 т. документов, то по скорости индексации DataparkSearch и ASPseek приблизительно одинаковы с незначительным опережением ASPseek.
При больших объемах разница достаточно заметна даже на глаз, тут я говорю не о секундах (еще раз повторяюсь, к сожалению, под рукой нет точных данных).
Что же касается времени поиска, то чем больше объем «индекса» тем вперед быстрее вырывается ASPseek далее идет DataparkSearch…
Время расчёта релеватности документов входило в сравнение.
У DataparkSearch были убраны те секции, которых нет у ASPseek (кстати, это на мой взгляд один из недостатков данной системы)
Я тестировал DataparkSearch и ASPSeek примерно на одинаковых базах в 300-350 тыс. документов. Скорость индексации действительно была примерно одинаковой с незначительным преимуществом ASPSeek. Но DataparkSearch при это ещё строит матрицу ссылок между документами, чего не делает ASPSeek. Похоже именно из-за это матрицы и начинаются тормоза при большом количестве документов.
По скорости поиска: а как вы её измеряли ? Дело в том, что эти поисковики по-разному считают цифру, которую выводят в качестве времени поиска. ASPSeek выводит время нахождения собственно документов, DataparkSearch плюс к этому еще учитывает время построения цитат по словам из запроса.
Прошу прощения за оффтопик. Zute, судя по всем вашим постам с обязательным упоминанием DataparkSearch, вы его разработчик?
Судя по вашим заявлениям об этих системах (ASPSeek, mnogosearch, dataparksearch), несколько далёких от действительности (ну или от того, что я видел и тестил лично)... :)
Может не будем гадать ? :)
Значительно - это сколько ? И как проводилась проверка, входило ли в сравниваемое время время расчёта релеватности для проиндексированых документов ?