logoped: Согласен с написанным выше - не будет такого никогда. Смысл владельцам прочих сайтов рвать себе анус, если переходов не будет? Поисковикам нужна движуха в инете, иначе им нечего будет анализировать.
В данном случае играет правило "Клиент всегда прав".
Если клиенту удобней получить всю информацию уже на первой странице, то зачем его кудато отправлять ?
ХорошийЧеловек: Вам тогда лучше всего где-нибудь описать архитектуру системы, потому что, как я ощущаю, мы с Вами общаемся про разные вещи. Получается как сравнение мягкого с мокрым :)
Если будет когдато время, может быть, опишу архитектуру подробней.
Но на данном этапе у меня не образовательное направление проекта и на это просто нет времени.
ХорошийЧеловек: В линейном массиве блоков данные хранятся в виде B+ дерева или линейного отсортированного массива? :)
У Вас ОЗУ используется как кэш или полностью дублирует индекс с харда?
Полностью дублирует. Даже можно указать режим, будем бегать по диску или попробуем все загрузить в ОЗУ.
ХорошийЧеловек:
Я к чему спрашиваю... Чтобы найти ноду с нужным значем на харде и вставить ее в дерево, нужно бежать по линейному массиву на харде искать ноду или обходить дерево и далее найденную ноду вставлять в дерево в ОЗУ.
Интересно как Вы себе это представляете ? Поток данных при индексировании контента, примерно 1 млрд вставок/поисков за час. Головка винчестера будет бегать что сумашедшая.
Диск через пару месяцев покупать новый не жалко ? :)
В моей схеме нету такого понятия как вставка чегото на диске. Есть операция мерж. А мержу впринципе всеравно, он склеивает две части индекса в один. Даже неважно где лежит часть индекса. Можно смержить два независимых индекса на диске в один.
ХорошийЧеловек:
У Вас диплом, исследовательская работа или диссер?
Диплом уже давно отгудел на задачах в разы попроще.
ХорошийЧеловек: Я имел ввиду, например, у Вас есть индекс и Вы его храните в базе данных, которую Вы разработали (NoSQL).
Пусть даже уже что-то в ОЗУ подгрузилось или хранится на диске - не важно.
1) Индекс у Вас расположен в отсортированном в линейном массиве или B+ дереве?
Т.е. вот сделали запрос однословник - Вася. Код посчитал хэш и пошел гулять далее по линейному отсортированному массиву искать или обходим B+ деревья. Т.е. Какая реализация ?
На диске это линейный массив блоков. В ОЗУ это дерево.
ХорошийЧеловек:
***
Например, Вы еще проиндексировали 1 000 000 сайтов и добавили информацию в индекс. Если индекс строили с нуля, то один вопрос, если вставляли в текущий индекс, то вопрос:
2) Как боритесь с фрагментацией?
Потому что при вставке начинается все равно внутренняя фрагментация данных.
Если в существующий индекс добавить 1 000 000 сайтов, то:
1. Все данные будут вставлены в ОЗУ, максимально быстро.
2. Два индекса, существующий на диске и тот который новый в ОЗУ будут смержены. Мерж индексов по сути означает что они будут дефрагментированы и перезаписаны на диске в один монолитный индекс.
Согласен с написанным выше - не будет такого никогда. Смысл владельцам прочих сайтов рвать себе анус, если переходов не будет? Поисковикам нужна движуха в инете, иначе им нечего будет анализировать.
В данном случае играет правило "Клиент всегда прав".
Если клиенту удобней получить всю информацию уже на первой странице, то зачем его кудато отправлять ?
Имплементировал смарт паука. Наконец сервис стал не офлайновый, а онлайновый.
База обновляется автоматом с лагом гдето в 4 часа, пока что по одному сайту в тестовом режиме.
+ В самых дорогих ресторанах не только приносят еду, но и показывают как ее готовят :)
Добавил простейшую страницу мониторинга спайдера и базы данных поисковика
http://booben.com/Monitoring
Посмотрим как база будет рости. По ощущениям даже если сайтов будет штук 50,
одного инмемори инстанца хватит на лет 5.
🍿
Поглотить практически все существующие сайты - это задача максимум, в ближайшем будущем точно невозможно.
В интернете медиа много.
Если считать только текст, то влезет все в один небольшой датацентр.
---------- Добавлено 14.06.2015 в 16:46 ----------
не будет такого, потому что ПС зарабатывают на борьбе владельцев сайтов за топ
Уже такое есть. Например тотже Фейсбук и Вконтакт эмулирует миллионы блогов, сайтов, новостных лент и прочье, что по хорошему должно быть на сайтах.
Добавил статейку в блог, Ляпы Яндекса и Гугла
🍿
То-то я смотрю из Вас ничего щипцами не вытащишь ))
Давайте так. Цель достигнута. Теория готова, по ней есть код.
Ваши дальнейшие действия?
Не совсем понятен вопрос.
Это R&D проект, результаты могут быть самыми разными.
В данном случае модифицирую ядро движка для фасетного поиска.
Подробности будут позже.
Просьба уточнить - какая Ваша конечная цель для проекта?
Поисковый движок следующего поколения.
Интересно, как можно обьяснить сей реверанс Яши ?
Ключевое слово Соцсетевич, на форуме есть
http://booben.com/?q=%D1%81%D0%BE%D1%86%D1%81%D0%B5%D1%82%D0%B5%D0%B2%D0%B8%D1%87&s=sql.ru
но Яндекс не находит
https://yandex.ua/search/?text=site%3Asql.ru%20%D1%81%D0%BE%D1%86%D1%81%D0%B5%D1%82%D0%B5%D0%B2%D0%B8%D1%87&lr=143
Вам тогда лучше всего где-нибудь описать архитектуру системы, потому что, как я ощущаю, мы с Вами общаемся про разные вещи. Получается как сравнение мягкого с мокрым :)
Если будет когдато время, может быть, опишу архитектуру подробней.
Но на данном этапе у меня не образовательное направление проекта и на это просто нет времени.
В линейном массиве блоков данные хранятся в виде B+ дерева или линейного отсортированного массива? :)
У Вас ОЗУ используется как кэш или полностью дублирует индекс с харда?
Полностью дублирует. Даже можно указать режим, будем бегать по диску или попробуем все загрузить в ОЗУ.
Я к чему спрашиваю... Чтобы найти ноду с нужным значем на харде и вставить ее в дерево, нужно бежать по линейному массиву на харде искать ноду или обходить дерево и далее найденную ноду вставлять в дерево в ОЗУ.
Интересно как Вы себе это представляете ? Поток данных при индексировании контента, примерно 1 млрд вставок/поисков за час. Головка винчестера будет бегать что сумашедшая.
Диск через пару месяцев покупать новый не жалко ? :)
В моей схеме нету такого понятия как вставка чегото на диске. Есть операция мерж. А мержу впринципе всеравно, он склеивает две части индекса в один. Даже неважно где лежит часть индекса. Можно смержить два независимых индекса на диске в один.
У Вас диплом, исследовательская работа или диссер?
Диплом уже давно отгудел на задачах в разы попроще.
Я имел ввиду, например, у Вас есть индекс и Вы его храните в базе данных, которую Вы разработали (NoSQL).
Пусть даже уже что-то в ОЗУ подгрузилось или хранится на диске - не важно.
1) Индекс у Вас расположен в отсортированном в линейном массиве или B+ дереве?
Т.е. вот сделали запрос однословник - Вася. Код посчитал хэш и пошел гулять далее по линейному отсортированному массиву искать или обходим B+ деревья. Т.е. Какая реализация ?
На диске это линейный массив блоков. В ОЗУ это дерево.
***
Например, Вы еще проиндексировали 1 000 000 сайтов и добавили информацию в индекс. Если индекс строили с нуля, то один вопрос, если вставляли в текущий индекс, то вопрос:
2) Как боритесь с фрагментацией?
Потому что при вставке начинается все равно внутренняя фрагментация данных.
Если в существующий индекс добавить 1 000 000 сайтов, то:
1. Все данные будут вставлены в ОЗУ, максимально быстро.
2. Два индекса, существующий на диске и тот который новый в ОЗУ будут смержены. Мерж индексов по сути означает что они будут дефрагментированы и перезаписаны на диске в один монолитный индекс.