- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
В 2023 году 36,9% всех DDoS-атак пришлось на сферу финансов
А 24,9% – на сегмент электронной коммерции
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Прошу прощения за оффтопик. Zute, судя по всем вашим постам с обязательным упоминанием DataparkSearch, вы его разработчик?
Evg, да и ещё, чем не очень нравится подход ASPSeek - для её использования нужно две базы данных (SQL и их иплементация, в которой они хранят индекс) - что, с моей точки зрения, не правильно (в том числе с точки зрения использования ресурсов)...
Очень даже правильно в рамках open-source поисковика.
Что Вам мешает вынести индексные файлы на RAID-10 массив? Да и mysql базу можно вынести тоже. Замечательная получится производительность.
absolut, аргументы принимаю.
Но вот мои:
- если делать поисковый сервер (отдельно), то я не хочу иметь на нём лишнюю базу данных, обращение к которой, кстати, достаточно "дорого" (время, загрузка);
- получается, что создатели поисковой системы "походя" (слишком сильное слово, но всё же) написали базу сравнимую по возможностям с тем, над чем народ отдельно трудится достаточно долго?
Значительно - это сколько ? И как проводилась проверка, входило ли в сравниваемое время время расчёта релеватности для проиндексированых документов ?
У меня нет под рукой цифровых данных сравнения этих 3 систем.
Скажу лишь следующее..
В 1 случае использовалось 5 т. сайтов. Во втором случае порядка 50 т. сайтов.
Тот и другой индекс останавливался по постижение приблизительно 300 т. документов и 5 миллионов документов.
Если брать 300 т. документов, то по скорости индексации DataparkSearch и ASPseek приблизительно одинаковы с незначительным опережением ASPseek.
При больших объемах разница достаточно заметна даже на глаз, тут я говорю не о секундах (еще раз повторяюсь, к сожалению, под рукой нет точных данных).
Что же касается времени поиска, то чем больше объем «индекса» тем вперед быстрее вырывается ASPseek далее идет DataparkSearch…
Время расчёта релеватности документов входило в сравнение.
У DataparkSearch были убраны те секции, которых нет у ASPseek (кстати, это на мой взгляд один из недостатков данной системы)
>да и ещё, чем не очень нравится подход ASPSeek
Для личного использования вряд ли можно найти идеальный вариант. Если только писать самому или дорабатывать готовые исходники.
Получается, что кроме большой четвёрки (ht:/Dig, mnogosearch, APSSeek, Datapark) ничего стоящего нет?
Есть, посмотрите
h**p://wiki.nebel.de/snipsnap/space/Nutch
Nutch на джаве же написан... Ничего не имею против этого языка, но, по-моему, в данной "отрасли" (поиск), это не лучший выбор (из-за значительного числа вычислений)...
Говорят тестировался до 1000 запросов в секунду. Не ставил не пробовал :(
Прошу прощения за оффтопик. Zute, судя по всем вашим постам с обязательным упоминанием DataparkSearch, вы его разработчик?
Судя по вашим заявлениям об этих системах (ASPSeek, mnogosearch, dataparksearch), несколько далёких от действительности (ну или от того, что я видел и тестил лично)... :)
Может не будем гадать ? :)
Говорят тестировался до 1000 запросов в секунду. Не ставил не пробовал :(
А про железо ничего при этом не говорят? =)