На это у нас двадцать причин :-)
Во первых, нет снарядов :-) мы некоторые числа не можем считать в реальном времени, а счетчик в обратную сторону "тикать" у нас не обучен.
Во вторых, нам не очень хочется давать обратную связь этим самым накрутчикам.
Правильно, но лишь отчасти :-))
Сейчас попробую расписать поподробнее.
Как некоторые уже, наверное, знают, робот Рамблера "стаскивает" страницы из Интернета в локальное хранилище, а вся последующая работа идет уже с этим хранилищем. Хранилище состоит из 50-мб кусков, в которых "свалены" сжатые HTML-ки.
Страницы в хранилище живут вечно, до тех пор, пока не появится новая версия страницы или не придет от робота запись о том, что на момент времени t страницы больше не существует (это у нас называется антидокумент). Но вернемся к делу.
Итак, когда на прошлой неделе мы собрались запустить индексатор, оказалось, что в хранилище накопилась дельта объемом 130 Гб. То есть, примерно 520 Мб несжатых HTML (коэффициент сжатия 3.9).
Мы запустили на 29 серверах по 2 процесса индексирования, которые занимаются тем, что в цикле обращаются к специальному балансировщику, получают от него очередную 50-мб порцию из хранилища (копируют по сети) и ее обрабатывают - распаковывают, разбирают HTML, детектируют кодовую страницу, морфологизируют, выполняют небольшой синтаксический анализ, строят информацию для цитирования, "душат" спаммерские фрагменты и т. д. В результате каждый из процессов порождает поисковый индекс по своей части хранилища. Индексы по формату идентичны "боевому" поисковому индексу.
130 Гб дельту эта группа серверов "смолотила" за 20 часов. Запустили вечером, а дорботала - на следующий день, к обеду. При этом сервера еще и запросы поисковые отрабатывали. На выходных индексирование должно идти побыстрее.
После того, как частичные индексы построены, запускается специальная программа "сливатор", которая параллельно читает отсортированные списки, из которых, собственно, и состоят индексы, и строит результирующий суммарный индекс. Время работы сливатора в основном зависит от размера результата: нам более-менее все равно, сколько частичных индексов доливать к основному. Сливатор работает примерно
25-30 часов. Иногда таблицы перенумерации документов, которые он строит и затем использует, становятся настолько большими, что перестают помещаться в памяти. Тогда нам приходится строить промежуточные индексы (четвертьфинал, полуфинал, финал, суперфинал и т. д.). В этом случае время слияния увеличивается пропорционально количеству уровней.
Скорость работы сливатора нас вполне устраивает, так как там интеллектуальной обработки никакой не планируется - только головоломный алгоритм слияния документов с перенумерацией, склейкой дублей, удалением "умерших" страниц и т. д. А вот скорость индексирования (того, чем занимались 29 серверов) для нас имеет большое значение, так как именно в это место и хочется положить побольше "умных" алгоритмов. Например, мы можем отфильтровывать дизайн (повторяющиеся на всех страницах сайта куски HTML) или исполнять JavaScript. Да мало ли еще чего.
Эксплуатировать такой комплекс индексатор/сливатор довольно удобно - нам почти все равно, добавить дельту в существующий индекс, или выкинуть его и построить все "с чистого листа". Поэтому мы можем, например, менять его формат. Что мы, собственно, и делаем - сейчас выкатим индекс в немного обновленном формате, а через 2-3 недели - в сильно переделанном (если успеем все ошибки в новом коде исправить. Не успеем - еще 2 недели поживем на существующем формате).
Именно это событие мы и пиарили - 130 Гб дельты из хранилища 58 процессов индексирования, исполнявшиеся параллельно на 29 серверах, заиндексировали за 20 часов. Если интересно, могу аналогично расписать и без малого 7 миллионов страниц, которые наши роботы скачали 24 ноября.
С уважением,
Влад
Представьте себе систему трубопроводов, где течет вода.
Суммарный объем воды известен - 8 миллионов единиц.
Известна конфигурация трубопровода (граф ссылок). Все
трубы - немного дырявые так как люди ходят не только по
ссылкам. Теперь зафиксируем поток воды в нескольких точках
и зададим правила течения воды по таким трубопроводам.
Дальше строим систему линейных уравнений и решаем ее.
Если сайт убирает внешние ссылки (становится аппендиксом),
то и потоки воды в нем ведут себя соответственно.
Вплодь до аппендоктомии :-)
Что же касается накрутки - да, действительно, и такую
штуку можно накрутить, как и все другие алгоритмы
ранжирования за исключением статических HTML, которые
редактор написал вручную.
Но мы над этим работаем :-)
В отличие от рейтинга top100, здесь можно дать себе
больше свободы с подсчетом числа посетителей, произвольно
менять алгоритмы фильтрации и т. д. Top100 не позволяет,
например, считать назад (в ней нет "антипосетителей"). В
подсчете коэфф. популярности мы можем дать накруточным
посетителям знак минус.
Про content-length - сказали
GET /forum/ HTTP/1.1
Host https://searchengines.guru/
Connection: close
User-agent: такой-то
получили content-length в заголовке, больший, чем длина HTML.
Про сайт тату и прочих - обратитесь в техподдержку.
В субботу робот на этот сервер жаловался - Content-length был больше, чем реальный размер HTML. По идее это признак обрыва соединения раньше времени. Сейчас проверил - стало нормально. Временные неполадки?
А вот зачем вообще на странице, генерируемой скриптом, считать content-length - этого я не постигаю. Все равно пока страницу не сгенерируешь и все баннеры в нее не впихнешь, размер не узнаешь. Намного приятнее для пользователей отдавать ее по частям, в процесе генерации.
По поводу 13 страниц - это, наверное, действительно динамика или глюки web-сервера какие-нибудь. Обратитесь в техподдержку. Мы, кстати, запреты на динамику потихоньку ослабляем.
Кстати про backup - те страницы, которые Рамблер скачал, у нас хранятся в кэше (весь HTML текст, со всеми HTTP заголовками и т. п). Причем хранятся вечно - пока не будет скачана более свежая версия страницы. Ну, или пока не узнаем, что страница больше не существует (в этом случае страница "поживет" еще несколько недель до прочистки кэша). Так что, если сайт перестал работать, вполне реально восстановить его страницы из нашего кэша. Когда-нибудь будем этот кэш писать на DVD, но пока не пишем.
P.S. ух ты! появилась кнопка TRANSLIT. А сделал бы кто-нибудь текстовую версию сайта, или хотя бы чтоб все картинки были с пустыми alt - а то на экран не влезает.
P.P.S. да, Gray, поглядите на досуге, какой Content-length выдается для страниц форума - он считается не совсем точно. В отдельных случаях это может приводить к неправильной обработке страниц.
2. Количество уникальных документов.
Начнем с конца - в Яндексе БОЛЬШЕ документов. БОЛЬШЕ. За счет двух вещей:
1) выкачка динамики и более мягкие правила отсева URL (нет дискриминации по портам и т. д.)
2) автоматическое хождение в зоны .com, .net, .org и т. д. за русскими документами.
А вот делать выводы из срвнения автолюбой нужно с осторожностью, так как разница этих чисел в 40% для пользователей может быть незаметна. И уж конечно, нельзя говорить, что полнота поиска ниже на 40%.
В том внутреннем документе сделано было вот что:
1) взяты списки найденного по однословным запросам (в том числе, конечно же, сигариллы, переверсия и т. д.). Было 10 тыс. URL. Взяты, конечно же, не со стандартной ответной страницы, а со страницы, где результаты не группированы по сайтам - так заметнее дубли.
2) с соответствующих серверов взят robots.txt и выполнена прочистка. Кстати, были хосты с некорректными robots.txt (на одном хосте даже выдавалась главная страница сайта) и был сайт, где Яндексу можно было ходить в каталог /cgi-bin/, а рамблеры - нет. Пришлось для этого сайта притвориться Яндексом :-)
3) выкачаны страницы. Таймауты в 300 секунд считались отсутствием документа. Так, конечно, нельзя, основной наш робот такие страницы удаляет только когда они несколько раз подряд тайм-аутятся, но в рамках эксперимента это, думаю, все же допустимо.
4) напущен наш индексатор и подсчитано, сколько раз он сказал "document is not text" и сколько "наклеил" дублей. Отсюда и числа.
Как видите, отличия от Автолюбы небольшие, но есть.
Отсев URL на каждом этапе - вещь совершенно нормальная. Она показывает, насколько поисковик отличается от идеального, в котором информация обновляется мгновенно. На Рамблере, кстати, сегодня будет намеряно одно число, а к выходным - другое (к выходным должна "выкатиться" новая база).
Еще пример из жизни - был терабайт, выполнили прореживание дублей и стало на 7% меньше. Запустите автолюбу до - получите одно число, после - совсем другое.
Поэтому плохо, когда журналист берет два поисковика, дает им одно и то же слово, и говорит, что в Яндексе в два раза больше информации, не задумываясь о том, что вся, скажем, 30-ая страница Рамблера содержит мусор, а 47-ая страница Яндекса - сплошные дубли.
Чистый от даких явлений эксперимент - запросы, по которым Яндекс хоть что-то находит, а Рамблер - нет. Пример: дефлограция.
3. Все/не все слова запроса
Я проделал простой эксперимент - взял частотные двух-трехсловные запросы, по которым находится небольшое количество документов. В ответной странице Яндека появились "нестрогие соответствия". Конечно же, нечеткий поиск во многих случаях очень полезен - найдется хоть
что-нибудь. Мы в этом смысле хуже - просто говорим, что ничего не найдено и оставляем пользователя наедине с его запросом.
Только вот плохо, когда по числу найденных по таким запросам документов судят о полноте базы (автолюба, этого, разумеется, не делает).
В заключение: я регулярно спрашиваю всех своих знакомых каким поиском они пользуются и почему. Так вот, половина народа говорит, что им нравится желтый цвет, а синий - раздражает, а другая половина - что желтый цвет раздражает, а синий - наоборот, нравится. Вот и оптимизируй после этого поиск :-))
P.S. Спайлоговский счетчик "только поиск" стоит кроме ответной страницы еще и "на голове" (его номер, если я не ошибаюсь, 9940). Он же - и на ya.ru. Вот и сравнивай после этого статистики.
Илья, благодарю за замечания и поправки. Сожалею, если своими высказываниеми задел Вас и команду разработчиков Яндекса.
Основной недостаток текста на runet.ru даже не в том, что он излишне эмоционален, а в том, что там все вырвано из контекста. Я сам, честно говоря, очень удивился, когда прочитал его там в таком виде. Ну да ладно, постараюсь восстановить утерянное.
Основное, о чем я там говорил - это то, что числа, которые показывают поисковики, нельзя напрямую сравнивать. Повторю свои тезисы более развернуто - с учетом Ваших поправок.
1. Нельзя сравнивать количество найденных серверов.
При одинаковом количестве найденных хостов то, что Рамблер называет "сайтами" и то, что Яндекс называет "серверами" - разные вещи и их количество нельзя сравнивать.
Мы в один элемент списка найденного всегда склеиваем документы с сайта www.xxxx.ru и xxxx.ru на этапе поиска. Поэтому у нас 2 найденных хоста (www.xxxx.ru и xxxx.ru) считаются одним найденным сайтом. Да, это не совсем корректно, есть случаи, когда xxxx.ru и www.xxxx.ru содержат разную информацию. Но сейчас наш способ подсчета
найденных сайтов работает именно так. Кстати, и разные порты одного хоста мы также объединяем. Также мы на runtime клеим и зеркала, хотя и не очень эффективно.
Яндекс, насколько я могу судить об этом снаружи, устроен по другому - там есть отдельный робот, который ходит по сети независимо (или почти независимо) от основного и принимает решения, что такие-то сервера суть зеркала и один из них не надо больше показывать. Это очень хорошее техническое решение, мы сейчас дополнительно к нашему сегодняшнему механизму делаем ровно такую же штуку, но из этого с
очевидностью следует, что пока этот дополнительный робот "зеркалатор" не добрался до кого-нибудь, сайты "живут" несклеенные. На первой странице такое случается редко, пользователи действительно не страдают, но на подсчете отражается.
Я когда-то сделал очень простую вещь - автолюба-образной программой вытащил списки найденного и построил список хостов, отсортировав его как в Зализняке - начиная с последней буквы. Там такие повторы хорошо заметны. Я сейчас специально подобрал запрос, на котором это можно увидеть:
http://www.yandex.ru/yandsearch?text=%C2+%FD%F2%E8+%EF%FF%F2%FC+%EA%E8%EB%EE%E1%E0%E9%F2+%E2%E5%E1-%E4%E8%E7%E0%E9%ED%E5%F0+%E4%EE%EB%E6%E5%ED+%F3%EC%E5%F1%F2%E8%F2%FC+%E2%F1%E5+html-%F4%E0%E9%EB%FB
http://vokruginfo.ru/news/news268.html
http://www.vokruginfo.ru/news/news268.html
Бывает и обртное - мы считаем сайтом подкаталог, начинающийся с тильды
(www.chat.ru/~vasya/...) и поэтому на некоторых запросах при одинаковом количестве найденных хостов мы "насчитаем" больше сайтов, чем Яндекс - серверов.
Осенью собираемся оперативно качать часто посещаемые страницы, на которых расставлен счетчик. Пока на "подмешивание" аннотаций и названий ресурсов в результат поиска это не отразится - только на полноте индекса и оперативности появления в нем той информации, которая интересна пользователям именно сегодня. Мы расчитываем, что если что-нибудь в мире утонет или взорвется, то информация об этом будет появляться в поиске быстрее, чем сейчас.
Да, в общем, так же, как и Яндекс - деваться нам от вас, злостных спаммеров, некуда :-).
Часть ссылок мы сможем исключать из рассмотрения алгоритмически,
а часть - придется вести еще один стоп-лист.
