Search engines with key/value db

123
VT
На сайте с 27.01.2001
Offline
130
#11
Значительно - это сколько ? И как проводилась проверка, входило ли в сравниваемое время время расчёта релеватности для проиндексированых документов ?

Прошу прощения за оффтопик. Zute, судя по всем вашим постам с обязательным упоминанием DataparkSearch, вы его разработчик?

A
На сайте с 23.10.2003
Offline
196
#12
Как писал xlex
Evg, да и ещё, чем не очень нравится подход ASPSeek - для её использования нужно две базы данных (SQL и их иплементация, в которой они хранят индекс) - что, с моей точки зрения, не правильно (в том числе с точки зрения использования ресурсов)...

Очень даже правильно в рамках open-source поисковика.

Что Вам мешает вынести индексные файлы на RAID-10 массив? Да и mysql базу можно вынести тоже. Замечательная получится производительность.

андроид ТВ (http://qway.com.ua/android_tv) и экшн камеры (qway.com.ua/action-cameras) в Украине.
X
На сайте с 15.05.2004
Offline
16
#13

absolut, аргументы принимаю.

Но вот мои:

- если делать поисковый сервер (отдельно), то я не хочу иметь на нём лишнюю базу данных, обращение к которой, кстати, достаточно "дорого" (время, загрузка);

- получается, что создатели поисковой системы "походя" (слишком сильное слово, но всё же) написали базу сравнимую по возможностям с тем, над чем народ отдельно трудится достаточно долго?

Evg
На сайте с 12.07.2004
Offline
128
Evg
#14
Как писал Zute
Значительно - это сколько ? И как проводилась проверка, входило ли в сравниваемое время время расчёта релеватности для проиндексированых документов ?

У меня нет под рукой цифровых данных сравнения этих 3 систем.

Скажу лишь следующее..

В 1 случае использовалось 5 т. сайтов. Во втором случае порядка 50 т. сайтов.

Тот и другой индекс останавливался по постижение приблизительно 300 т. документов и 5 миллионов документов.

Если брать 300 т. документов, то по скорости индексации DataparkSearch и ASPseek приблизительно одинаковы с незначительным опережением ASPseek.

При больших объемах разница достаточно заметна даже на глаз, тут я говорю не о секундах (еще раз повторяюсь, к сожалению, под рукой нет точных данных).

Что же касается времени поиска, то чем больше объем «индекса» тем вперед быстрее вырывается ASPseek далее идет DataparkSearch…

Время расчёта релеватности документов входило в сравнение.

У DataparkSearch были убраны те секции, которых нет у ASPseek (кстати, это на мой взгляд один из недостатков данной системы)

>да и ещё, чем не очень нравится подход ASPSeek

Для личного использования вряд ли можно найти идеальный вариант. Если только писать самому или дорабатывать готовые исходники.

libarea.ru ( https://libarea.ru/ )
X
На сайте с 15.05.2004
Offline
16
#15

Получается, что кроме большой четвёрки (ht:/Dig, mnogosearch, APSSeek, Datapark) ничего стоящего нет?

Evg
На сайте с 12.07.2004
Offline
128
Evg
#16

Есть, посмотрите

h**p://wiki.nebel.de/snipsnap/space/Nutch

X
На сайте с 15.05.2004
Offline
16
#17

Nutch на джаве же написан... Ничего не имею против этого языка, но, по-моему, в данной "отрасли" (поиск), это не лучший выбор (из-за значительного числа вычислений)...

Evg
На сайте с 12.07.2004
Offline
128
Evg
#18

Говорят тестировался до 1000 запросов в секунду. Не ставил не пробовал :(

Z
На сайте с 03.01.2004
Offline
32
#19
Как писал Vyacheslav Tikhonov

Прошу прощения за оффтопик. Zute, судя по всем вашим постам с обязательным упоминанием DataparkSearch, вы его разработчик?

Судя по вашим заявлениям об этих системах (ASPSeek, mnogosearch, dataparksearch), несколько далёких от действительности (ну или от того, что я видел и тестил лично)... :)

Может не будем гадать ? :)

X
На сайте с 15.05.2004
Offline
16
#20
Как писал Evg
Говорят тестировался до 1000 запросов в секунду. Не ставил не пробовал :(

А про железо ничего при этом не говорят? =)

123

Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий