связность — просто, позиции слов и некоторый алгоритм вычисления нескольких расстояний. Все постараюсь описать.
Ранги — проще — на вход самообучающегося алгоритма ранжирования поступают как взвешенные коэффициенты — как раз ранг по сути, так и абсолютные. Более того есть еще вспомогательные коэффициенты. Сейчас около 56 параметров всего — после большой чистки.
Остается обучать алгоритм… Над этим и голову ломаю, когда были просто формулы — все руками забивал
Очень просто — Вы забываете что все равно хранить придется, их не выкинуть. Какой-нить одаренный все равно вынесет вам мозг по поводу того что страниц его сайта нет в выдаче, а другой будет икать если по запросу 25.02.2002 ничего не найдется — так что индексим и складываем подальше. Слова-цифры мало котируются в индексе и запросе, к ним будет доступ только если напрямую введут запрос и особенно они не мешают работе
По поводу того что забьется очередь на индексацию — да, конкретно с этим сайтов забьется. Возможно вы правы что можно по url + немного анализа контента выделить еще и значимые страницы, но эта идея будет в списке доделок не первой )
Все описано — асинхронная многопотоковость на уровне 100 запросов в секунду, обработка, сохранение. Лишние запросы к ДНС, большая загрузка
Универсальность всегда неэффективна по сравнению с заточенным под задачу решением, особенно если ее собирать из кусков. Crawler на Perl есть — там как раз модульное, раз в 10 медленнее чем C++ и сокеты низкого уровня.
Календари? Никак. Я беспристрастен — если автор считает что главное что есть на его сайте это ссылки на числа календаря то его право. В топ он может по запросу — конкретной дате — и выйдет, а дальше сам виноват. Поверьте у большинства поисковиков такая же позиция
1. Не сталкивался с проблемами на 1 диске… Может предел запросов одновременный не переходил…
2. Да, естественно если надо. В своих БД специально проектирую возможность seek к нужной записи и чтобы они лежали подряд
3. Свои БД пишу под конкретные задачи, соответственно и алгоритмы там могу использовать только наиболее эффективные, а не только универсальные
4. Почитаю про кластерные индексы. Всякие деревья кроме AVL не дают ответ достаточно быстро, и все что не Oracle, как-то не очень быстро делает выборку например по индексу в базе с парой миллионов пользователей. Возможно есть стандартное решение, но пока не сталкивался
Самая большая ошибка в количестве страниц на сайтах — никто этого не заметил. В среднем у меня не хватает и 1000 страниц лимита, а есть сайты у которых по миллиону ссылок. И не забудьте что на большинстве сайтов есть страницы одинаковые но с разными url — а для того чтобы понять что они одинаковые надо их сначала скачать
Ну вы еще рекламную сеть бегуна и рупоиска возьмите :)
Я рассматриваю только сайты второго уровня + региональные домены немного — у них меньший приоритет
Вы реально думаете что в инете есть контентосодержащих сайтов миллионы? К примеру вычистив promodj.ru третьего уровня я сократил базу в 2 раза. А таких сайтов море. Я их сознательно пока не индексю, с основными то справится бы.
Кроме того ошибки и дубли в эту цифру не входят. Реально проверил из 600 я тысяч 300, которые в индексе больше чем 1-2 страницами
первый сайт — любой, например rambler.ru
дальше получаем контент — берем все ссылки. все ссылки на другие сайты с текущего попадают в общую очередь — только их главные страницы, все страницы с текущего сайта — в текущую очередь в пределах лимита.
Дорабатывая текущий сайт (лимит или кончились страницы) — берем из общей очереди новый сайт
я храню очередь только главных страниц. Все проиндексированные в другой базе — уже собственно поисковика, там полные url.
Соответственно фазы сбора url и их индексации во времени близко стоят, друг за другом, — много ссылок не меняется.
Есть варианты робота на Perl, C++. В основном юзаю C++ — меньше грузит сервер, как понятно
Все неуникальное отрезается — чуть дальше опишу, в этом и есть весь функционал —
запрос — сбор ответа/выделение ссылок на другие страницы — сохранение — анализ всего сайта — отрезание одинакового — сохранение — сортировка очереди
Серверное время останется, ничего не сделать — но таких сайтов единицы.
Товарищи, поймите, там годы работы и экспериментов — я не могу написать сразу все, у меня рук не хватит
про это и есть данный пост.
LWP и остальные готовые средства делают 1 запрос к ДНС на каждый запрос. Кеша там нет. В моем случае я сначала написал кеш, поработал с ним, потом понял что проще поднять локальный bind чем самому грамотно организовывать всю работу, тестировать ее.
Иметь сильно больше 100 потоков смысла нет — скорости обработки не хватит, надо же это все куда-то складывать.
Сам робот — многопотоковый, сокеты низкого уровня, асинхронные, довольно забавно собираются ответы серверов в целую страницу — но собственно все по спецификации TCP/IP ничего нового
Общая очередь с приоритетами. Сейчас приоритет на индексацию никогда не индексированных сайтов — 9 к 1. Это все гибко меняется — сами понимаете какие то сайты типа новостных надо раз в сутки индексить, а какие-то раз в год. В очереди (это единственное что я храню в MySQL) можно проставлять приоритеты, и потом обычная взвешенная выборка
Список ресурсов — проходя по странице все ссылки на другие сайты попадают в 2 очереди — на индексацию и на обновление PR
Ошибка при загрузке понижает рейтинг сайта. 10 ошибок в разное время и ни одной рабочей страницы — и он будет браться из очереди очень редко, считай никогда
когда я так делал умирали некоторые сайты. среднее время сейчас на 1 страницу — меньше 2 секунд, прикиньте как умрет хостинг если за секунду просить по 100 страниц? Реальный пример — форум суммарно на 5000 сообщений умирал при 5 запросах в секунду
Общий ответ:
Да, инфы море.
Сайтов не 15 млн, это глюки от бесплатных хостингов и умерших доменов. у меня 600 тыс актуальных второго уровня .ru и больше не растет.
Хранить все не обязательно, в принципе если я заберу все 600 тыс то сколько-то десятков терабайт моя база займет (одна итерация, я храню минимум 3-4 для инкрементальной работы). Но в таком виде искать по ней на 1 сервере будет нереально. Эти вопросы решить еще предстоит
Ниже я ответил про 2,3
А по поводу я беру на себя — так это и есть Ваша работа, если за день работы по оптимизации например большой системы статистики можно не ставить новый сервер, а освободить существующий на 90% — это того стоит. Сам имею 8 серверов и под 70 тыс хостов в день + счетчик посещений который обсчитывает пару лямов хитов, и поверьте что MySQL + все эти несложные трюки позволяют легко решать проблемы загрузки
Ранги — проще — на вход самообучающегося алгоритма ранжирования поступают как взвешенные коэффициенты — как раз ранг по сути, так и абсолютные. Более того есть еще вспомогательные коэффициенты. Сейчас около 56 параметров всего — после большой чистки.
Остается обучать алгоритм… Над этим и голову ломаю, когда были просто формулы — все руками забивал
По поводу того что забьется очередь на индексацию — да, конкретно с этим сайтов забьется. Возможно вы правы что можно по url + немного анализа контента выделить еще и значимые страницы, но эта идея будет в списке доделок не первой )
Универсальность всегда неэффективна по сравнению с заточенным под задачу решением, особенно если ее собирать из кусков. Crawler на Perl есть — там как раз модульное, раз в 10 медленнее чем C++ и сокеты низкого уровня.
Календари? Никак. Я беспристрастен — если автор считает что главное что есть на его сайте это ссылки на числа календаря то его право. В топ он может по запросу — конкретной дате — и выйдет, а дальше сам виноват. Поверьте у большинства поисковиков такая же позиция
2. Да, естественно если надо. В своих БД специально проектирую возможность seek к нужной записи и чтобы они лежали подряд
3. Свои БД пишу под конкретные задачи, соответственно и алгоритмы там могу использовать только наиболее эффективные, а не только универсальные
4. Почитаю про кластерные индексы. Всякие деревья кроме AVL не дают ответ достаточно быстро, и все что не Oracle, как-то не очень быстро делает выборку например по индексу в базе с парой миллионов пользователей. Возможно есть стандартное решение, но пока не сталкивался
чисто технически проблема с многопоточностью и обработкой результатов, но она решается
Я рассматриваю только сайты второго уровня + региональные домены немного — у них меньший приоритет
Вы реально думаете что в инете есть контентосодержащих сайтов миллионы? К примеру вычистив promodj.ru третьего уровня я сократил базу в 2 раза. А таких сайтов море. Я их сознательно пока не индексю, с основными то справится бы.
Кроме того ошибки и дубли в эту цифру не входят. Реально проверил из 600 я тысяч 300, которые в индексе больше чем 1-2 страницами
дальше получаем контент — берем все ссылки. все ссылки на другие сайты с текущего попадают в общую очередь — только их главные страницы, все страницы с текущего сайта — в текущую очередь в пределах лимита.
Дорабатывая текущий сайт (лимит или кончились страницы) — берем из общей очереди новый сайт
Соответственно фазы сбора url и их индексации во времени близко стоят, друг за другом, — много ссылок не меняется.
Есть варианты робота на Perl, C++. В основном юзаю C++ — меньше грузит сервер, как понятно
Все неуникальное отрезается — чуть дальше опишу, в этом и есть весь функционал —
запрос — сбор ответа/выделение ссылок на другие страницы — сохранение — анализ всего сайта — отрезание одинакового — сохранение — сортировка очереди
Серверное время останется, ничего не сделать — но таких сайтов единицы.
Товарищи, поймите, там годы работы и экспериментов — я не могу написать сразу все, у меня рук не хватит
LWP и остальные готовые средства делают 1 запрос к ДНС на каждый запрос. Кеша там нет. В моем случае я сначала написал кеш, поработал с ним, потом понял что проще поднять локальный bind чем самому грамотно организовывать всю работу, тестировать ее.
Иметь сильно больше 100 потоков смысла нет — скорости обработки не хватит, надо же это все куда-то складывать.
Сам робот — многопотоковый, сокеты низкого уровня, асинхронные, довольно забавно собираются ответы серверов в целую страницу — но собственно все по спецификации TCP/IP ничего нового
Список ресурсов — проходя по странице все ссылки на другие сайты попадают в 2 очереди — на индексацию и на обновление PR
Ошибка при загрузке понижает рейтинг сайта. 10 ошибок в разное время и ни одной рабочей страницы — и он будет браться из очереди очень редко, считай никогда
Да, инфы море.
Сайтов не 15 млн, это глюки от бесплатных хостингов и умерших доменов. у меня 600 тыс актуальных второго уровня .ru и больше не растет.
Хранить все не обязательно, в принципе если я заберу все 600 тыс то сколько-то десятков терабайт моя база займет (одна итерация, я храню минимум 3-4 для инкрементальной работы). Но в таком виде искать по ней на 1 сервере будет нереально. Эти вопросы решить еще предстоит
А по поводу я беру на себя — так это и есть Ваша работа, если за день работы по оптимизации например большой системы статистики можно не ставить новый сервер, а освободить существующий на 90% — это того стоит. Сам имею 8 серверов и под 70 тыс хостов в день + счетчик посещений который обсчитывает пару лямов хитов, и поверьте что MySQL + все эти несложные трюки позволяют легко решать проблемы загрузки