- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Маркетинг для шоколадной фабрики. На 34% выше средний чек
Через устранение узких мест
Оксана Мамчуева
В 2023 году 36,9% всех DDoS-атак пришлось на сферу финансов
А 24,9% – на сегмент электронной коммерции
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Начало темы было здесь: /ru/forum/832998
При попытке добавить сообщение, пишет что эта тема "слишком старая",
поэтому создал тему продолжение.
Итак, готова версия движка на основе ассоциативного поиска,
которая подымает ассоциации не только на основе единичных слов, но и на основе фраз. :idea:
Напомню, что в некоторых тестах, движок зарекомендовал себя как более интеллектуальный, не уступающий алгоритмам гугла в некоторых кейсах:
http://blog.pikosec.com/?p=72
(по-моему субьективному мнению, естественно)
Таким образом это уже в какойто мере полноценный движок, с достаточно сильными релевантными алгоритмами. Он еще плохо оттесан, но он уже работает:
http://booben.com/?q=%D0%BF%D0%B5%D1%80%D0%B2%D1%8B%D0%B9%20%D0%BA%D0%BE%D1%81%D0%BC%D0%BE%D0%BD%D0%B0%D0%B2%D1%82&s=sql.ru
Следующий этап, тюнинг движка и, возможно, движение в сторону селекторных запросов, запросов с выделением фактов из страниц и предоставления их в табличном виде.
PS: Прошу прощение у всех кто мне писал в личку или на мыло, освободился и добрался до проекта только сейчас.
Bazist, http://booben.com/?q=%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%B0%20%D0%B4%D0%BE%D0%BC%D0%B0&s=searchengines.guru :)
Bazist, http://booben.com/?q=%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%B0%20%D0%B4%D0%BE%D0%BC%D0%B0&s=searchengines.guru :)
Да, тут нужно учитывать, что в отличии от разных гуглов, у которых на "работа дома", "куплю машину" и тд уже захаркоджено 1500 позиций проплаченого топа - у меня это еще чистый незаангажированный поиск. Возвращает результаты без каких либо проплат, как есть, на основе конкурирующей модели ассоциативных связей. ☝
Ну вот чтото типа такого 😂
Начало темы было здесь: /ru/forum/832998
При попытке добавить сообщение, пишет что эта тема "слишком старая",
поэтому создал тему продолжение.
Итак, готова версия движка на основе ассоциативного поиска,
которая подымает ассоциации не только на основе единичных слов, но и на основе фраз. ☝
Напомню, что в некоторых тестах, движок зарекомендовал себя как более интеллектуальный, не уступающий алгоритмам гугла в некоторых кейсах:
http://blog.pikosec.com/?p=72
(по-моему субьективному мнению, естественно)
Таким образом это уже в какойто мере полноценный движок, с достаточно сильными релевантными алгоритмами. Он еще плохо оттесан, но он уже работает:
http://booben.com/?q=%D0%BF%D0%B5%D1%80%D0%B2%D1%8B%D0%B9%20%D0%BA%D0%BE%D1%81%D0%BC%D0%BE%D0%BD%D0%B0%D0%B2%D1%82&s=sql.ru
Следующий этап, тюнинг движка и, возможно, движение в сторону селекторных запросов, запросов с выделением фактов из страниц и предоставления их в табличном виде.
PS: Прошу прощение у всех кто мне писал в личку или на мыло, освободился и добрался до проекта только сейчас.
Ветку не читал,
Давно уже есть вот такое опенсоурсное решение:
http://www.opensearchserver.com/
Без суппорта можно просто скачать, изучать и использовать.
Можно под себя подделать формулу ранжирования.
Данный проект изучали?
Ветку не читал,
Давно уже есть вот такое опенсоурсное решение:
http://www.opensearchserver.com/
Без суппорта можно просто скачать, изучать и использовать.
Можно под себя подделать формулу ранжирования.
Данный проект изучали?
Чем оно лучше Сфинкс, Люсена, Ксапиан и других подобных опенсорц проектов ?
Чем оно лучше Сфинкс, Люсена, Ксапиан и других подобных опенсорц проектов ?
Вот так глубоко не капал. Поэтому и спрашиваю.
Еще такой вопрос:
Вы архитектуру с нуля разрабатывали и с нуля код писали или форкнули что либо?
Вы архитектуру с нуля разрабатывали и с нуля код писали или форкнули что либо?
/ru/forum/832998
/ru/forum/832998
Частично просмотрел. Судя по всему проект делаете с нуля.
1) Какую хэш функцию используете: свою, известный алгоритм или дернули из какого-нибудь gnu проекта?
2) Индекс хранится отсортированным в линейном массиве или используете B+ деревья?
3) При обновлении индекса создаете новый и работаете по нему или идет вставка в существующий индекс?
4) Как боритесь с фрагментацией данных в хранилище (там где хранится индекс)?
Частично просмотрел. Судя по всему проект делаете с нуля.
1) Какую хэш функцию используете: свою, известный алгоритм или дернули из какого-нибудь gnu проекта?
2) Индекс хранится отсортированным в линейном массиве или используете B+ деревья?
Используется Trie и NoSql база данных собственной разработки.
Она значительно быстрее работает чем существующие решения.
Например стандартный std::map из С++ построенный на красно черных деревьях превосходит в среднем по скорости в 5 раз. Достаточно легко оперирует таблицами в которых десятки и даже сотни миллионов ключей ( что важно для поисковиков )
Подробней еще здесь: http://blog.pikosec.com/?p=55
3) При обновлении индекса создаете новый и работаете по нему или идет вставка в существующий индекс?
Индекс делится на две части. На тот что лежит на диске и тот что в ОЗУ. Новые страницы попадают в ОЗУ. Когда лимит выделенный на ОЗУ превышен, часть индекса из ОЗУ мержится с дисковым индексом и ОЗУ очищается.
4) Как боритесь с фрагментацией данных в хранилище (там где хранится индекс)?
Благодаря хорошей степени сжатия, индекс часто удается весь вытянуть в ОЗУ. Например расчет такой. На 56 ГБ проиндексированого контента индекс в районе 500-600 мб. На рабочей машинке сейчас 8 ГБ ОЗУ. Следовательно в ОЗУ можно разместить индекс сразу на несколько крупных ресурсов, вроде серчэнжин. Когда данные в ОЗУ, вопрос с фрагментацией уже не актуален.
"ваз в кредит" лучше искать на серче или на хабре?