Кстати, о масштабах расчетов

OFF: Надо уже на блог вешать надпись типа “многие посты сделаны благодаря поддержке Яндекса” 🙂
Я несколько удивился, когда в хостграфе оказалось не 380, а 5 миллионов хостов.
Но когда начал считать дальше, вообще опупел. Из этих сайтов только около 10% – известны Яндексу, т.е., скачаны! 90% хостов имеют указание на то, что это найденная ссылка.
А из них (известных) еще около половины – “висящие” (“dangling”, т.е., не имеют внешних ссылок с себя).
Итого, одна итерация расчета Siterank по 250 000 хостов занимает чуть больше минуты на моем компе. На тормозном perl, конечно. 🙂 В свете того, что 50 итераций достаточно, думаю не заморачиваться расчетом на Сях.
Вот и думаю. А так ли страшен черт, как его малютка? 500 тыс сайтов… Новым поисковикам в для старта надо совсем мало… Это если по 1000 документов с сайта, по 7К плейнтекста каждый – получается … [upd: эээ… блин, тыщу в килобайтах забыл, губу раскатал] 3.5 терабайта получается. Фак. 🙁

Кстати, о масштабах расчетов: 9 комментариев

  1. 3.5 терабайта получается. Фак.

    400гб Seagate Barracuda (SATA) = 280$
    2800$ надо новому поисковику для старта. 🙂

  2. 3.5 терабайт … есть мысли как обойти дисковые ограничения, возникают, правда, другие траблы, но это уже другая история … Продолжать?

  3. Конечно, продолжай…
    Кроме того, размер индекса должен быть плюс где-то 1/3-1/4 от размера плейнтекста. Но плейнтекст хранить надо – для выдачи сниппетов. Итого плюс треть.

  4. Ok, но вначале маленькое отступление. Речь пойдет о некоторой измененной схеме построения поисковой системы, в которой дисковое пространство обсуждается также наравне с другими моментами. Мысли в письменном виде излагаются впервые, поэтому прошу прощения за возможную несвязность или даже путаницу.
    Как можно кардинально увеличить скорость индексирования и размер индекса? Что нужно сделать, чтобы новому поисковику не пришлось вкладывать астрономические суммы в трафик, обслуживание и железо? Давайте обсудим идею модифицированного пирингового поисковика. Пиринговый поисковик – идея не новая (см. перечень хотя бы здесь: http://www.searchtools.com/info/peer-to-peer.html), новое, как мне кажется, в состоит в «модификации» – почему бы не совместить пиринговый поисковик и браузер? Вначале я попытаю описать некий принцип действия такой системы, а потом можно будет взвесить все «за» и «против».
    Пиринговый поисковик лучше всего делать как плагин к браузеру. И позиционировать его в первую очередь для поиска по кешу браузера и только потом как поисковик в интернете (до Google Desktop Search и иже с ними многие сталкивались с ситуацией, когда проще вспомнить, что было на странице которую посещал день, неделю назад, чем адрес такой страницы).

  5. В то время как пользователь ходит браузером по страничкам, плагин добавляет в индекс содержимое загруженных страниц. Когда нужно найти что-либо в кеше – набираем строку поиска в окошке, аналогичном окну запросов Яндекс.Бара или Firefox`а, плагин ищет по индексу и выдает в новом окне или закладке результаты (но первом этапе можно даже без морфологии и сниппетов). Дальше начинается самое интересное – поиск в сети. Для начала узнаем свои внешние ip-адреса (к примеру 213.146.50.82) и начинаем бродкастом рассылать по соседним ip запросы вроде http://213.146.50.**:OpenPortNumber/keyword1…/keywordN?type=person в надежде, что там сейчас работает браузер с таким же плагином. В режиме запроса извне плагин делает тот же поиск в кеше по запросу keyword1…/keywordN, делает предварительное ранжирование результатов, отдавая назад к примеру только 3 самых релевантных URL или все, если таковых меньше. Если запрашивающему плагину повезло и рядом нашлись браузеры с подобными плагинами и у них в кеше нашлось то, что мы искали, то к нему начинают поступать первично отранжированные результаты, теперь его задача провести вторичное ранжирование в зависимости от количества повторяющихся URL. Вот и все.
    Прежде чем перейти к преимуществам и недостаткам нужно отметить, что жизнеспособность такого browser-SE зависит прежде всего от наличия некоторого критического количества пользователей. Пока предположим, что маркетинговыми ухищрениями мы набрали нужное количество пользователей системы.

  6. О преимуществах browser-SE.
    1. Большая скорость индексации
    2. Практически неограниченный размер индекса
    3. В индекс попадают «более качественные» страницы, т.к. они отобраны человеком (даже если человек нашел их большими SE)
    4. Результаты поиск чаще всего уже «локальные», т.к. найдены соседями по офису или языку – очень отдаленная аналогия «Near me» у msn.com или Google Local.
    5. Возможность создавать поисковые сообщества по интересам. К примеру, все кто интересуется SEO, часто заходят на searchengines.ru, можно модифицировать алгоритм поиска партнерских ip т.о., что бы вначале перечень ip запрашивался с серверов-координаторов (к примеру http://searchengines.ru/communitysearch/),”>http://searchengines.ru/communitysearch/), и только потом расширялся «от себя» (в нашем примере от 213.146.50.82), сервер-координатор может просто отдавать перечень ip-адресов, с которых шли запросы от клиентов на протяжении нескольких часов (К примеру если с 213.146.50.82 запросили http://searchengines.ru/communitysearch/ и вернулся пустой список, то следующий клиент, который запросит через 5 минут http://searchengines.ru/communitysearch/ получит уже список, в котором будет как минимум 1 адрес – 213.146.50.82)
    О недостатках browser-SE
    1. При маленьком количестве пользователей поиск не сдвинется дальше собственного кеша.
    2. Положительная обратная связь – чем более популярна страница, тем выше она в результатах поиска, тем более она популярна. Трудней будет найти уникальный контент.
    3. Новые возможности для вирусописателей и хакеров.

  7. NULL, у меня скептические настроения по этому поводу. Как бы ты оценил время поиска? И число счастливцев, установивших (добровольно!) эту тулзу?

  8. У меня самого скептическое отношение – поэтому стадия интенсивного программирования еще не началась.
    Согласен, что время поиска будет не маленькое, да и повторяемость SERP невысокая.
    Некоторые "счастливцы" устанавливали бы тулзу (к примеру я, если бы такая была) только ради поиска по кешу, т.к. конфликты GDS со сниферами уже достали, но в общем это тоже слабое место – согласен. С другой стороны, представь, что ты поставил такую тулзу, внес в настройки http://searchengines.ru/communitysearch/ и задал в строке для поиска "sandbox" – мне кажется, что результат подходил бы под твои ожидания больше, чем в SERP других SE. Плюс к тому же скрипты-координаторы – это еще один "коммюнити-образующий" инструмент для владельцев сайтов.

  9. Кроме того, размер индекса должен быть плюс где-то 1/3-1/4 от размера плейнтекста. Но плейнтекст хранить надо – для выдачи сниппетов. Итого плюс треть.

    Плейнтекст ведь жмется очень хорошо. Так что в сумме можно обойтись 1/2 объема думаю. А такой объем реально вообще в 1U сервер запихать. 🙂

Комментарии запрещены.