Грубо говоря выход Crawler-а это файл для каждого сайта для последующей индексации. По мере их появления (10 роботов могут класть удаленно файлы в каталог для индексации) их берет индексатор и уже делает кусочек индекса — который потом добавляется к основному. Про индексатор и методику инкрементального построения индекса тоже напишу подробно
Вероятность что 10 crawler'ов будут индексить один сайт весьма мала — сайты выбираются из очереди исходя из даты начала индексации (чем больше прошло тем лучше), весов, кол-ва страниц и тд. Т.е. начиная очередной сайт crawler просто проставляет текущую дату и следующий робот уже этот сайт не возьмет.
Собственная БД. Вернее одна из собственных — в одной индекс, в другой инфа по страницами и словам разнообразная, в третьей PR, в четвертой тексты. Но для упрощения можно считать что просто пишу на диск в хитрую структуру каталогов и файлов с быстрым последовательным доступом. Тоже расскажу, я реально просто не могу все описать за 1 день :)
Да, правда опыт внедрения на сервера в ДЦ как-то не сильно порадовал — канал иногда тупит больше чем 20Мб дома. Пока на 3 серверах работают разные модули
Сложно сказать — все вместе
Надо собрать хотя бы 1000 страниц, это 10-100 мб, распарсить-сохранить, ссылки в очередь добавить
Возможно нужен просто пустой сервак для чистоты эксперимента, возможно винч не успевает. Если иметь сильно больше сайтов в параллель растет загрузка по отработке очереди
Основная то работа по сохранению, а не по загрузке
Ну согласитесь, что искать по энциклопедиям, умея искать по огромному кол-ву разных документов, будет намного проще. Меня просто на все не хватит. Первоначально я занимался параллельным поиском и по файлам в файловых хостингом, и в новостях, и в торрентах, и в вакансиях — благо многие базы у меня есть и обновляются самостоятельно, но меня просто на все не хватило. Я выделил наиболее интересный кусок для себя.
Я сейчас не занимаюсь доведением процесса поиска до высшего абсолюта — надо понимать что по сути это проект для себя, для того чтобы сделать его проектом для всех — нужны бюджет, люди, инвестиции.
Я обязательно раскрою предложенную Вами тему, но пока мне жаль, что она остается только в моей голове.
Одно из уже реализованных, но пока не оптимизированных под нормальную быструю работу в связке с поиском — кластеризация результатов — то что делает clusty.com и nigma.ru. Только в отличие от последней, я могу это делать по всему массиву документов, а не по 400 сниппетам. И я не успел тогда прикрутить это раньше нигмы — они меня опередили наверное месяца на 4-5
Трудный вопрос. Показывать проект не всегда работающий хотя бы «средне» я не готов — ведь все что вы увидите это результаты поиска, с ними я еще борюсь.
Ну согласитесь, что искать по энциклопедиям, умея искать по огромному кол-ву разных документов, будет намного проще. Меня просто на все не хватит. Первоначально я занимался параллельным поиском и по файлам в файловых хостингом, и в новостях, и в торрентах, и в вакансиях — благо многие базы у меня есть и обновляются самостоятельно, но меня просто на все не хватило. Я выделил наиболее интересный кусок для себя.
Я сейчас не занимаюсь доведением процесса поиска до высшего абсолюта — надо понимать что по сути это проект для себя, для того чтобы сделать его проектом для всех — нужны бюджет, люди, инвестиции.
Я обязательно раскрою предложенную Вами тему, но пока мне жаль, что она остается только в моей голове.
Одно из уже реализованных, но пока не оптимизированных под нормальную быструю работу в связке с поиском — кластеризация результатов — то что делает clusty.com и nigma.ru. Только в отличие от последней, я могу это делать по всему массиву документов, а не по 400 сниппетам. И я не успел тогда прикрутить это раньше нигмы — они меня опередили наверное месяца на 4-5
хорошая идея, но и повысить загрузку сервера, кроме того по умолчанию, насколько я знаю, в апаче опция отключена.
проверю вечерком работает ли, с другой стороны это повысит загрузку моего сервера — а он не резиновый, и так под завязку
ну вас можно только поздравить вы получили бы сейчас скорость минимум 1гб в минуту, или 133 mbit/s полезной инфы, учитывая что не более 40%-60% канала реально можно занять полезной инфой, и даже не учитывая время на запросы ДНС, поскольку объем одной страницы сейчас в среднем около 100кб до отрезания всего.
Да, и я хорошо представляю себе счет за перерасход траффика за несоблюдение соглашения по соотношению 1:3 минимум…
Мой потолок — 200 тысяч страниц в час без проверки контента
если про нормализацию то мысль не ясна. БД остается нормализованой, даже более чем была.
К примеру: у половины форумов primary index в таблицах состоит из нескольких полей, чтобы было удобно было делать JOIN для 10 таблиц туда запихнуты все нужные поля — id юзера, группы, топика, и тд… причем все это чтобы выбрать 1 сообщение к примеру — данного юзера в данном топике, да еще и фотку юзера и тд
однако если сделать один код-CRC или даже несколько и выбирать по нему просто последовательно из 10 таблиц то можно получить ту же инфу в 10 раз быстрее. Просто этот код и стоит сделать PRIMARY INDEX заместо того что было
Я уж не говорю что проще было бы сложить все фотки юзеров по их ID: photos/ID_USER.jpg
и вообще не надо было бы делать лишнюю выборку — если отходить от СУБД немного.
Конечно это если это все касалось пункта 4, и я правильно понял
да, я начинал когда она еще работала. Правда основную инфу искал про гугл. turtle насколько я помню был аналогом рамблера в той версии без ссылочного ранжирования
согласен, проблема. Избавляюсь — если она встречена больше чем на 10% страниц сайта ее не будет в индексе — блоком одной инфы считаются законченый блок тегов — т.е. ряд в таблице подходит.
Вообще вопрос конечно интересный, но пока что я не встречался с проблемами в выдаче из-за дублей похожих но не одинаковых страниц. Вообще борьба с ними описана у сегаловича — хитрый подсчет нескольких CRC по фрагментам текста.
У меня в конце статьи написана динамика, я уже не помню где (слишком много комментов) давал свою оценку — десятки терабайт если иметь в виду объем сопоставимый с яндексом (скорее гуглом) — несколько миллиардов страниц в индексе (у яндекса половина страниц из их миллиардов ищется по ссылкам). короче мне осталось раз в 100-500 вырасти.
Это цифры на одну итерацию — надо хранить несколько чтобы процесс индексации шел непрерывно
Вероятность что 10 crawler'ов будут индексить один сайт весьма мала — сайты выбираются из очереди исходя из даты начала индексации (чем больше прошло тем лучше), весов, кол-ва страниц и тд. Т.е. начиная очередной сайт crawler просто проставляет текущую дату и следующий робот уже этот сайт не возьмет.
Это в двух словах
У меня самообучающаяся функция типа яндексовой
Надо собрать хотя бы 1000 страниц, это 10-100 мб, распарсить-сохранить, ссылки в очередь добавить
Возможно нужен просто пустой сервак для чистоты эксперимента, возможно винч не успевает. Если иметь сильно больше сайтов в параллель растет загрузка по отработке очереди
Основная то работа по сохранению, а не по загрузке
Я сейчас не занимаюсь доведением процесса поиска до высшего абсолюта — надо понимать что по сути это проект для себя, для того чтобы сделать его проектом для всех — нужны бюджет, люди, инвестиции.
Я обязательно раскрою предложенную Вами тему, но пока мне жаль, что она остается только в моей голове.
Одно из уже реализованных, но пока не оптимизированных под нормальную быструю работу в связке с поиском — кластеризация результатов — то что делает clusty.com и nigma.ru. Только в отличие от последней, я могу это делать по всему массиву документов, а не по 400 сниппетам. И я не успел тогда прикрутить это раньше нигмы — они меня опередили наверное месяца на 4-5
Я сейчас не занимаюсь доведением процесса поиска до высшего абсолюта — надо понимать что по сути это проект для себя, для того чтобы сделать его проектом для всех — нужны бюджет, люди, инвестиции.
Я обязательно раскрою предложенную Вами тему, но пока мне жаль, что она остается только в моей голове.
Одно из уже реализованных, но пока не оптимизированных под нормальную быструю работу в связке с поиском — кластеризация результатов — то что делает clusty.com и nigma.ru. Только в отличие от последней, я могу это делать по всему массиву документов, а не по 400 сниппетам. И я не успел тогда прикрутить это раньше нигмы — они меня опередили наверное месяца на 4-5
проверю вечерком работает ли, с другой стороны это повысит загрузку моего сервера — а он не резиновый, и так под завязку
Да, и я хорошо представляю себе счет за перерасход траффика за несоблюдение соглашения по соотношению 1:3 минимум…
Мой потолок — 200 тысяч страниц в час без проверки контента
К примеру: у половины форумов primary index в таблицах состоит из нескольких полей, чтобы было удобно было делать JOIN для 10 таблиц туда запихнуты все нужные поля — id юзера, группы, топика, и тд… причем все это чтобы выбрать 1 сообщение к примеру — данного юзера в данном топике, да еще и фотку юзера и тд
однако если сделать один код-CRC или даже несколько и выбирать по нему просто последовательно из 10 таблиц то можно получить ту же инфу в 10 раз быстрее. Просто этот код и стоит сделать PRIMARY INDEX заместо того что было
Я уж не говорю что проще было бы сложить все фотки юзеров по их ID: photos/ID_USER.jpg
и вообще не надо было бы делать лишнюю выборку — если отходить от СУБД немного.
Конечно это если это все касалось пункта 4, и я правильно понял
больше я не смог заюзать — есть машины и 100 и 1000, все равно не успеваю отрабатывать
Вообще вопрос конечно интересный, но пока что я не встречался с проблемами в выдаче из-за дублей похожих но не одинаковых страниц. Вообще борьба с ними описана у сегаловича — хитрый подсчет нескольких CRC по фрагментам текста.
никак не отсеиваю — в основном пара коэффициентов при поиске — показатели тошноты слов
Это цифры на одну итерацию — надо хранить несколько чтобы процесс индексации шел непрерывно