ХорошийЧеловек: Частично просмотрел. Судя по всему проект делаете с нуля.
1) Какую хэш функцию используете: свою, известный алгоритм или дернули из какого-нибудь gnu проекта?
2) Индекс хранится отсортированным в линейном массиве или используете B+ деревья?
Используется Trie и NoSql база данных собственной разработки.
Она значительно быстрее работает чем существующие решения.
Например стандартный std::map из С++ построенный на красно черных деревьях превосходит в среднем по скорости в 5 раз. Достаточно легко оперирует таблицами в которых десятки и даже сотни миллионов ключей ( что важно для поисковиков )
3) При обновлении индекса создаете новый и работаете по нему или идет вставка в существующий индекс?
Индекс делится на две части. На тот что лежит на диске и тот что в ОЗУ. Новые страницы попадают в ОЗУ. Когда лимит выделенный на ОЗУ превышен, часть индекса из ОЗУ мержится с дисковым индексом и ОЗУ очищается.
ХорошийЧеловек:
4) Как боритесь с фрагментацией данных в хранилище (там где хранится индекс)?
Благодаря хорошей степени сжатия, индекс часто удается весь вытянуть в ОЗУ. Например расчет такой. На 56 ГБ проиндексированого контента индекс в районе 500-600 мб. На рабочей машинке сейчас 8 ГБ ОЗУ. Следовательно в ОЗУ можно разместить индекс сразу на несколько крупных ресурсов, вроде серчэнжин. Когда данные в ОЗУ, вопрос с фрагментацией уже не актуален.
Да, тут нужно учитывать, что в отличии от разных гуглов, у которых на "работа дома", "куплю машину" и тд уже захаркоджено 1500 позиций проплаченого топа - у меня это еще чистый незаангажированный поиск. Возвращает результаты без каких либо проплат, как есть, на основе конкурирующей модели ассоциативных связей. ☝
Kait: Мне, как пользователю, совершенно нас рать, что 99% сайтов не увидят топ. А также пофиг на их "прекрасный" контент. Могут им подтереться.
Ну вот взять гипотетический случай. У вас на аватарке ежик ест яблоки. Допустим в мире есть 10 ученных со своими блогами которые изучают процесс поедания ежиками яблок. Но как найти эти 10 сайтов ? Их найти нереально. Потому что про ежики и яблоки есть уже 100500 сайтов которые забили топ до десятой страницы. У вас нет возможности более тонко настроить поиск, чтобы из миллиардов страниц вернуть те что надо.
topy: Я о том и говорю, что сейчас уже устно можно задать поисковый запрос и пользователь пойдет по пути наименьшего сопротивления. Пусть даже потом придется перелопатить тонны сайтов и трижды скорректировать свои запрос.
Естественно ИМХО
Проблема в том что 99% сайтов с хорошим контентом никогда не увидят топ.
Потому что как не лопать запрос, на первую страницу уже есть 100500 кое-каких претендентов.
topy: По такому принципу работает, например, Я.Маркет - строгое соответствие параметрам. Ищет не сайты, конечно, а товары, но тем не менее... Пользователю все равно проще набрать (а теперь уже и просто сказать) искомое, а поисковик, опираясь на интересы пользователя и его потенциальные предпочтения построит выдачу.
Поиск по параметрам, самая простая и очевидная область.
Тут вопрос больше в другом. Если ли смысл усложнить поисковый фильтр для глобального поиска.
Не будет ли пользователь лениться его устанавливать ?
Ведь он привык к простой поисковой и малофункциональной строке.
"ваз в кредит" лучше искать на серче или на хабре?
На серче есть:
http://booben.com/?q=%D0%B2%D0%B0%D0%B7%20%D0%BA%D1%80%D0%B5%D0%B4%D0%B8%D1%82&s=searchengines.guru
Частично просмотрел. Судя по всему проект делаете с нуля.
1) Какую хэш функцию используете: свою, известный алгоритм или дернули из какого-нибудь gnu проекта?
2) Индекс хранится отсортированным в линейном массиве или используете B+ деревья?
Используется Trie и NoSql база данных собственной разработки.
Она значительно быстрее работает чем существующие решения.
Например стандартный std::map из С++ построенный на красно черных деревьях превосходит в среднем по скорости в 5 раз. Достаточно легко оперирует таблицами в которых десятки и даже сотни миллионов ключей ( что важно для поисковиков )
Подробней еще здесь: http://blog.pikosec.com/?p=55
3) При обновлении индекса создаете новый и работаете по нему или идет вставка в существующий индекс?
Индекс делится на две части. На тот что лежит на диске и тот что в ОЗУ. Новые страницы попадают в ОЗУ. Когда лимит выделенный на ОЗУ превышен, часть индекса из ОЗУ мержится с дисковым индексом и ОЗУ очищается.
4) Как боритесь с фрагментацией данных в хранилище (там где хранится индекс)?
Благодаря хорошей степени сжатия, индекс часто удается весь вытянуть в ОЗУ. Например расчет такой. На 56 ГБ проиндексированого контента индекс в районе 500-600 мб. На рабочей машинке сейчас 8 ГБ ОЗУ. Следовательно в ОЗУ можно разместить индекс сразу на несколько крупных ресурсов, вроде серчэнжин. Когда данные в ОЗУ, вопрос с фрагментацией уже не актуален.
ИМХО Соцсети это эволюционный тупик. Вики останется на своем месте.
Поисковые системы идут к агрегаторам.
Тоесть их задача в будуйщем будет не просто отдать топ сайтов,
а проанализировать самому этот топ сайтов, вычитать наиболее важную информацию и отдать пользователю информацию уже в своем формате.
Такая система с легкостью сможет ответить на вопросы:
"Найди мне все гостиницы в пределах 30 км где есть теннисный корт и бассейн"
"Пожалуйста мне список сайтов с фильмами онлайн, которые получили наилучший отзыв пользователей в интернете за последние три месяца"
"Список телефонов с наиболее емкой батареей с вот этим диапазоном цен"
Вы архитектуру с нуля разрабатывали и с нуля код писали или форкнули что либо?
/ru/forum/832998
Ветку не читал,
Давно уже есть вот такое опенсоурсное решение:
http://www.opensearchserver.com/
Без суппорта можно просто скачать, изучать и использовать.
Можно под себя подделать формулу ранжирования.
Данный проект изучали?
Чем оно лучше Сфинкс, Люсена, Ксапиан и других подобных опенсорц проектов ?
Ну вот чтото типа такого 😂
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 позиций проплаченого топа - у меня это еще чистый незаангажированный поиск. Возвращает результаты без каких либо проплат, как есть, на основе конкурирующей модели ассоциативных связей. ☝
Мне, как пользователю, совершенно нас рать, что 99% сайтов не увидят топ. А также пофиг на их "прекрасный" контент. Могут им подтереться.
Ну вот взять гипотетический случай. У вас на аватарке ежик ест яблоки. Допустим в мире есть 10 ученных со своими блогами которые изучают процесс поедания ежиками яблок. Но как найти эти 10 сайтов ? Их найти нереально. Потому что про ежики и яблоки есть уже 100500 сайтов которые забили топ до десятой страницы. У вас нет возможности более тонко настроить поиск, чтобы из миллиардов страниц вернуть те что надо.
Я о том и говорю, что сейчас уже устно можно задать поисковый запрос и пользователь пойдет по пути наименьшего сопротивления. Пусть даже потом придется перелопатить тонны сайтов и трижды скорректировать свои запрос.
Естественно ИМХО
Проблема в том что 99% сайтов с хорошим контентом никогда не увидят топ.
Потому что как не лопать запрос, на первую страницу уже есть 100500 кое-каких претендентов.
По такому принципу работает, например, Я.Маркет - строгое соответствие параметрам. Ищет не сайты, конечно, а товары, но тем не менее... Пользователю все равно проще набрать (а теперь уже и просто сказать) искомое, а поисковик, опираясь на интересы пользователя и его потенциальные предпочтения построит выдачу.
Поиск по параметрам, самая простая и очевидная область.
Тут вопрос больше в другом. Если ли смысл усложнить поисковый фильтр для глобального поиска.
Не будет ли пользователь лениться его устанавливать ?
Ведь он привык к простой поисковой и малофункциональной строке.