- Поисковые системы
 - Практика оптимизации
 - Трафик для сайтов
 - Монетизация сайтов
 - Сайтостроение
 - Социальный Маркетинг
 - Общение профессионалов
 - Биржа и продажа
- Финансовые объявления
 - Работа на постоянной основе
 - Сайты - покупка, продажа
 - Соцсети: страницы, группы, приложения
 - Сайты без доменов
 - Трафик, тизерная и баннерная реклама
 - Продажа, оценка, регистрация доменов
 - Ссылки - обмен, покупка, продажа
 - Программы и скрипты
 - Размещение статей
 - Инфопродукты
 - Прочие цифровые товары
 
 - Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
 - Ведение рекламных кампаний
 - Услуги в области SMM
 - Программирование
 - Администрирование серверов и сайтов
 - Прокси, ВПН, анонимайзеры, IP
 - Платное обучение, вебинары
 - Регистрация в каталогах
 - Копирайтинг, переводы
 - Дизайн
 - Usability: консультации и аудит
 - Изготовление сайтов
 - Наполнение сайтов
 - Прочие услуги
 
 - Не про работу
 
        Тренды маркетинга в 2024 году: мобильные продажи, углубленная аналитика и ИИ
          Экспертная оценка Адмитад
        
        
              Оксана Мамчуева
          
            
          
        
      Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
                
            
        
Либо предоставьте ссылки, где мои "заявления" не соответствуют действительности, либо извинитесь. То, что я не люблю поисковиков на СУБД - это факт, однако чтобы говорить об этом подобным образом, нужны убедительные аргументы, которые меня опровергают.
Итак?
Вячеслав, Вы, наверное, хотели сказать "поисковиков на СУБД общего назначения, в частности 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 начинает раньше отдавать страницу клиенту...
Я прекрасно помню (и без моего поиска, который установлен на этом сайте) все, о чем я здесь говорил, и что-то не припомню, чтобы кто-то аргументированно доказал обратное.
В исходный код - да, однако неоднократно имел возможность оценивать результаты и качество их работы.
И если вы полагаете, что СУБД в этих поисковиках за это время стали работать быстрее, или же разработчики изобрели какие-то невероятные алгоритмы, то вы глубоко заблуждаетесь.
Или же докажите обратное.