- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
В 2023 году Google заблокировал более 170 млн фальшивых отзывов на Картах
Это на 45% больше, чем в 2022 году
Оксана Мамчуева
Все что нужно знать о DDоS-атаках грамотному менеджеру
И как реагировать на "пожар", когда неизвестно, где хранятся "огнетушители
Антон Никонов
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Либо предоставьте ссылки, где мои "заявления" не соответствуют действительности, либо извинитесь. То, что я не люблю поисковиков на СУБД - это факт, однако чтобы говорить об этом подобным образом, нужны убедительные аргументы, которые меня опровергают.
Итак?
Вячеслав, Вы, наверное, хотели сказать "поисковиков на СУБД общего назначения, в частности SQL БД"? Или имелся ввиду поисковик на любой базе данных??
Я имел в виду поисковик на SQL базе, конечно.
Если брать 300 т. документов, то по скорости индексации DataparkSearch и ASPseek приблизительно одинаковы с незначительным опережением ASPseek.
При больших объемах разница достаточно заметна даже на глаз, тут я говорю не о секундах (еще раз повторяюсь, к сожалению, под рукой нет точных данных).
Что же касается времени поиска, то чем больше объем «индекса» тем вперед быстрее вырывается ASPseek далее идет DataparkSearch…
Время расчёта релеватности документов входило в сравнение.
У DataparkSearch были убраны те секции, которых нет у ASPseek (кстати, это на мой взгляд один из недостатков данной системы)
Я тестировал DataparkSearch и ASPSeek примерно на одинаковых базах в 300-350 тыс. документов. Скорость индексации действительно была примерно одинаковой с незначительным преимуществом ASPSeek. Но DataparkSearch при это ещё строит матрицу ссылок между документами, чего не делает ASPSeek. Похоже именно из-за это матрицы и начинаются тормоза при большом количестве документов.
По скорости поиска: а как вы её измеряли ? Дело в том, что эти поисковики по-разному считают цифру, которую выводят в качестве времени поиска. ASPSeek выводит время нахождения собственно документов, DataparkSearch плюс к этому еще учитывает время построения цитат по словам из запроса.
Дело не только в цифре, которая показывается в результатах поиска. Но и во времени обычного отображения страницы.
Если бы при 5 миллионах документов разница была бы 1-2 секунды, то возможно об этом я и не заговорил.
Однако разница была в разы.
Либо предоставьте ссылки, где мои "заявления" не соответствуют действительности, либо извинитесь. То, что я не люблю поисковиков на СУБД - это факт, однако чтобы говорить об этом подобным образом, нужны убедительные аргументы, которые меня опровергают.
Итак?
Я не хочу вступать с вами в никакие разборки, если вас действительно интересует именно этот вопрос - воспользуйтесь поиском по форуму, - в тех местах, где я счёл нужным сделать, а вас поправил. Могу вам напомнить, что в одном из топиков, вы сами признались, что последний раз смотрели на mnogosearch пару-тройку лет назад, - это уже значительно устаревшая информация, именно не соответсвующая действительности...
Дело не только в цифре, которая показывается в результатах поиска. Но и во времени обычного отображения страницы.
Если бы при 5 миллионах документов разница была бы 1-2 секунды, то возможно об этом я и не заговорил.
Однако разница была в разы.
На моей базе время, затрачиваемое на построение цитат, обычно больше времени, затрачиваеемого на собственно поиск документов.
А эффект получается таким: dataparksearch сначала строит цитаты для всех выводимых документов, а потом собвенно начинает выводить результаты, aspseek же строит цитату для первого документа, потом выводит кусок страницы с эти результатом, потом начинает строить цитату для второго и т.д. В результате веб-сервер у aspseek начинает раньше отдавать страницу клиенту...
Я прекрасно помню (и без моего поиска, который установлен на этом сайте) все, о чем я здесь говорил, и что-то не припомню, чтобы кто-то аргументированно доказал обратное.
В исходный код - да, однако неоднократно имел возможность оценивать результаты и качество их работы.
И если вы полагаете, что СУБД в этих поисковиках за это время стали работать быстрее, или же разработчики изобрели какие-то невероятные алгоритмы, то вы глубоко заблуждаетесь.
Или же докажите обратное.