Компания
954,31
рейтинг
27 августа 2012 в 16:38

Разработка → Поиск@Mail.Ru, часть вторая: обзор архитектур подготовки данных больших поисковых систем

Обзор архитектур подготовки данных больших поисковых систем


В прошлый раз мы с вами вспомнили, как стартовал в 2010 году Go.Mail.Ru, и каким Поиск был до этого. В этом посте мы попробуем нарисовать общую картину — остановимся на том, как работают другие, но сначала расскажем о поисковой дистрибуции.

Как распространяются поисковые системы


Как вы и просили, мы решили подробнее остановиться на основах дистрибуционных стратегий самых популярных поисковых систем.

Бытует мнение, что интернет-поиск – один из тех сервисов, которые большинство пользователей выбирает самостоятельно, и победить в этой битве должен сильнейший. Эта позиция нам крайне симпатична – именно ради этого мы постоянно совершенствуем наши поисковые технологии. Но ситуация на рынке вносит свои корректировки, и в первую очередь сюда вмешиваются так называемые «браузерные войны».

Было время, когда поиск не был связан с браузером. Тогда поисковая система была просто очередным сайтом, на который пользователь заходил по своему усмотрению. Представьте себе —Internet Explorer до 7-й версии, появившейся в 2006-м году, не имел строки поиска; Firefox имел строку поиска с первой версии, но сам он при этом появился только в 2004-м году.

Откуда же взялась строка поиска? Придумали её не авторы браузеров — впервые она появилась в составе Google Toolbar, вышедшего в 2001-м году. Google Toolbar добавлял в браузер функциональность «быстрого доступа к поиску Google» – а именно, поисковую строчку в свою панель:



Зачем Google выпустил свой тулбар? Вот как описывает его предназначение Дуглас Эдвардс, бренд-менеджер Гугла в тот момент, в своей книге «I'm Feeling Lucky: The Confessions of Google Employee Number 59»:

«The Toolbar was a secret weapon in our war against Microsoft. By embedding the Toolbar in the browser, Google opened another front in the battle for unfiltered access to users. Bill Gates wanted complete control over the PC experience, and rumors abounded that the next version of Windows would incorporate a search box right on the desktop. We needed to make sure Google's search box didn't become an obsolete relic».

«Toolbar был секретным оружием в войне против Microsoft. Интегрировав Toolbar в браузер, Google открыл очередной фронт в битве за прямой доступ к пользователям. Биллу Гейтсу хотелось полностью контролировать то, как пользователи взаимодействуют с ПК: множились слухи, что в следующей версии Windows строка поиска будет устанавливаться прямо на рабочий стол. Необходимо было принять меры, чтобы строка поиска Google не стала пережитком прошлого».

Как распространялся тулбар? Да всё так же, вместе с популярным программным обеспечением: RealPlayer, Adobe Macromedia Shockwave Player и т.п.

Понятно, что другие поисковики начали распространять свои тулбары (Yahoo Toolbar, например), а производители браузеров не преминули воспользоваться этой возможностью получения дополнительного источника доходов от поисковых систем и встроили поисковую строчку к себе, введя понятие «поисковик по умолчанию».

Бизнес-департаменты производителей браузеров выбрали очевидную стратегию: браузер — точка входа пользователя в интернет, настройки поиска по умолчанию с высокой вероятностью будут использоваться аудиторий браузера — так почему бы не продать эти настройки? И они были по-своему правы, ведь интернет-поиск — это продукт с практически нулевой «приклеиваемостью».

На этом пункте стоит остановиться подробнее. Многие возмутятся: «нет, человек привыкает к поиску и пользуется только той системой, которой доверяет», но практика доказывает обратное. Если, скажем, ваш почтовый ящик или аккаунт соц. сети по какой-то причине недоступен, вы не переходите тут же в другой почтовый сервис или другую социальную сеть, ведь вы «приклеены» к своим аккаунтам: их знают ваши друзья, коллеги, семья. Смена аккаунта — долгий и болезненный процесс. С поисковиками же всё совсем иначе: пользователь не привязан к той или иной системе. Если поисковик по каким-то причинам недоступен, пользователи не сидят и не ждут, когда он, наконец, заработает — они просто идут в другие системы (например, мы отчётливо видели это по счётчикам LiveInternet год назад, во время сбоев у одного из наших конкурентов). При этом пользователи не сильно страдают от аварии, ведь все поисковики устроены примерно одинаково (поисковая строка, запрос, страница результатов) и даже неопытный юзер не растеряется при работе с любым из них. Более того, примерно в 90% случаев пользователь получит ответ на свой вопрос, в какой бы системе он его ни искал.

Итак, поиск, с одной стороны имеет практически нулевую «приклеиваемость» (в английском языке есть специальный термин «stickiness»). С другой — какой-то поиск уже предустановлен в браузер по умолчанию, и довольно большое количество людей будет использовать его только по той причине, что им удобно пользоваться именно оттуда. И если поиск, стоящий за поисковой строчкой, удовлетворяет задачам пользователя, то он может продолжить его использовать.
К чему мы приходим? У ведущих поисковых систем не осталось другого выхода, кроме как бороться за поисковые строки браузеров, распространяя свои десктопные поисковые продукты — тулбары, которые в процессе инсталляции меняют дефолтный поиск в барузере пользователя. Зачинщиком этой борьбы был Google, остальным пришлось защищаться. Можно, к примеру, прочитать такие слова Аркадия Воложа, создателя и владельца Яндекса, в его интервью:

«Когда в 2006–2007гг. доля Google на российском поисковом рынке стала расти, мы сначала не могли понять, из-за чего. Потом стало очевидно, что Google продвигает себя путем встраивания в браузеры (Opera, Firefox). А с выходом собственного браузера и мобильной операционной системы Google вообще стал разрушать соответствующие рынки».
Так как Mail.Ru – это ещё и поиск, то он не может стоять в стороне от «браузерных войн». Мы просто вышли на рынок немного позже других. Сейчас качество нашего Поиска заметно выросло, и наша дистрибуция является реакцией на ту самую борьбу тулбаров, которая ведётся на рынке. При этом для нас действительно важно, что всё большее количество людей, которые пробуют пользоваться нашим Поиском, остаются довольны результатами.

К слову, наша дистрибуционная политика в несколько раз менее активна, чем у ближайшего конкурента. Мы видим это по счётчику top.mail.ru, который установлен на большей части сайтов рунета. Если пользователь переходит на сайт по запросу через один из дистрибуционных продуктов (тулбар, собственный браузер, сёрчбокс браузера-партнёра), в URL присутствует параметр clid=… Таким образом, мы можем оценить ёмкость дистрибуционных запросов: у конкурента она почти в 4 раза больше, чем у нас.

Но давайте от дистрибуции перейдем к тому, как устроены другие поисковые системы. Ведь внутренние обсуждения архитектуры мы, естественно, начинали с изучения архитектурных решений других поисковиков. Я не буду подробно описывать их архитектуры — вместо этого я дам ссылки на открытые материалы и выделю те особенности их решений, которые мне кажутся важными.

Подготовка данных в крупных поисковых системах


Рамблер

Поисковая система Рамблер, ныне закрытая, обладала рядом интересных архитектурных идей. Например, было известно об их собственной системе хранения данных (NoSQL, как сейчас модно называть подобные системы) и распределённых вычислений HICS (или HCS), использовавшейся, в частности, для вычислений на графе ссылок. Так же HICS позволял стандартизировать представление данных внутри поиска единым универсальным форматом.

Архитектура Рамблера довольно сильно отличалась от нашей в организации спайдера. У нас спайдер был выполнен как отдельный сервер, со своей, самописной, базой адресов скачанных страниц. Для выкачки каждого сайта запускался отдельный процесс, который одновременно качал страницы, парсил их, выделял новые ссылки и мог сразу же по ним пойти. Спайдер Рамблера был сделан значительно проще.

На одном сервере был расположен большой текстовый файл со всеми известными Рамблеру адресами документов, по одному на строку, отсортированный в лексикографическом порядке. Раз в сутки этот файл обходился и генерировались другие текстовые файлы-задания на выкачку, которые выполнялись специальными программами, умеющими только скачивать документы по списку адресов. Затем документы парсились, извлекались ссылки и клались рядом с этим большим файлом-списком всех известных документов, сортировались, после чего списки сливались в новый большой файл, и цикл повторялся снова.

Достоинства такого подхода были в простоте, наличии единого реестра всех известных документов. Недостатки заключались в невозможности пройти по свежеизвлечённым адресам документов сразу же, так как скачивание новых документов могло случиться только на следующей итерации спайдера. Кроме того, размер базы и скорость её обработки была ограничена одним сервером.

Наш же спайдер, наоборот, мог быстро пройти по всем новым ссылкам с сайта, но очень плохо управлялся снаружи. В него было тяжело «влить» дополнительные данные к адресам (необходимые для ранжирования документов внутри сайта, определяющие приоритетность выкачки), трудно было сделать дамп базы.

Яндекс

О внутреннем устройстве поиска Яндекса было известно не так много до тех пор, пока Ден Расковалов не рассказал о нём в своём курсе лекций.

Оттуда можно узнать, что поиск Яндекса состоит из двух разных кластеров:

  • пакетной обработки данных
  • обработки данных в реальном времени (это не совсем уж «реальное время» в том смысле, в котором этот термин используется в системах управления, где просрочка времени выполнения задач может быть критичной. Скорее, это возможность попадания документа в индекс максимально быстро и независимо от других документов или задач; этакий «мягкий» вариант реального времени)

Первый используется для штатной обкачки интернета, второй – для доставки в индекс самых лучших и интересных документов, появившихся только что. Будем рассматривать пока что только пакетную обработку, потому что до обновления индекса в реальном времени нам тогда было довольно далеко, мы хотели выйти на обновление индекса раз в один-два дня.



При этом, несмотря на то, что внешне кластер пакетной обработки данных Яндекса был в чём-то похож на нашу пару качающих и индексирующих кластеров, в нём было и несколько серьёзных отличий:

  • База адресов страниц одна, хранится на индексирующих узлах. Как следствие, нет проблем с синхронизацией двух баз.
  • Управление логикой выкачки перенесено на индексирующие узлы, т.е. узлы спайдера очень простые, качают то, что им указывают индексаторы. У нас спайдер сам определял, что ему и когда скачать.
  • И, очень важное отличие, — внутри все данные представлены в виде реляционных таблиц документов, сайтов, ссылок. У нас же все данные были разнесены по разным хостам, хранились в разных форматах. Табличное представление данных значительно упрощает доступ к ним, позволяет делать различные выборки и получать самую разнообразную аналитику индекса. Всего этого мы были лишены, и на тот момент только лишь синхронизация двух наших баз документов (спайдера и индексатора) занимала неделю, причём нам приходилось останавливать на это время оба кластера.


Google

Google, без сомнений, является мировым технологическим лидером, поэтому на него всегда обращают внимание, анализируют что он сделал, когда и зачем. А архитектура поиска Google, естественно, была для нас самой интересной. К сожалению, свои архитектурные особенности Google открывает редко, каждая статья – большое событие и практически моментально порождает параллельный OpenSource-проект (иногда и не один) реализующий описываемые технологии.

Тем, кому интересны особенности поиска Google, можно с уверенностью посоветовать изучить практически все презентации и выступления одного из самых главных специалистов в компании по внутренней инфраструктуре — Джеффри Дина (Jeffrey Dean), например:

Основываясь на этих выступлениях, можно выделить следуюшие особенности архитектуры поиска Google:
  • Табличная структура для подготовки данных. Вся база поиска хранится в огромной таблице, где ключом является адрес документа, а метаинформация сохраняется в отдельных колонках, объединённых в семейства. Причём таблица изначально сделана таким образом, чтобы эффективно работать с разреженными данными( т.е. когда значения в колонках есть далеко не у всех документов).
  • Единая система распределённых вычислений MapReduce. Подготовка данных (включая создание поискового индекса) является последовательностью mapreduce-задач, выполняемых над таблицами BigTable или файлами в распределённой файловой системе GFS.


Всё это выглядит довольно разумно: все известные адреса документов сохраняются в одной большой таблице, по ней выполняется их приоритезация, вычисления над ссылочным графом и т.п., в неё приносит содержимое выкачанных страниц паук поиска, по ней в итоге строится индекс.

Есть ещё одно интересное выступление уже другого специалиста Google, Дэниела Пенга (Daniel Peng) про новшества в BigTable, позволившие реализовать быстрое, в течение нескольких минут, добавление новых документов в индекс. Эта технология «снаружи» Google была разрекламирована под названием Caffeine, а в публикациях получила название Percolator. Видео выступления на OSDI’2010 можно посмотреть здесь.

Если говорить очень грубо, то это тот же самый BigTable, но в котором реализованы т.н. триггеры, — возможность загрузить свои кусочки кода, которые срабатывают на изменения внутри таблицы. Если до сих пор я описывал пакетную обработку данных, т.е. когда данные по возможности объединяются и обрабатываются вместе, то реализация того же на триггерах получается совершенно иной. Допустим, спайдер что-то скачал, поместил в таблицу новое содержимое; сработал триггер, сигнализирующий «появился новый контент, его нужно проиндексировать». Немедленно запустился процесс индексации. Получается, что все задачи поисковика в итоге могут быть разбиты на подзадачи, каждая из которых запускается по своему щелчку. Имея большое количество техники, ресурсов и отлаженный код, можно решать задачу добавления новых документов быстро, буквально за минуту — что и продемонстрировал Google.

Отличие архитектуры Google от архитектуры Яндекса, где тоже была указана система обновления индекса в режиме реального времени, в том, что в Google, как утверждается, вся процедура построения индекса выполнена на триггерах, а у Яндекса она есть только для небольшого подмножества самых лучших, самых ценных документов.

Lucene

Стоит упомянуть и ещё об одном поисковике – Lucene. Это свободно распространяемый поисковик, написанный на Java. В некотором смысле, Lucene является платформой для создания поисковиков, например, от него отпочковался поисковик по вебу под названием Nutch. По сути, Lucene — это поисковое ядро для создания индекса и поискового движка, а Nutch — это то же самое плюс спайдер, который обкачивает страницы, потому что поисковик не обязательно ищет по документам, которые находится в вебе.

На самом деле, в самом Lucene реализовано не так много интересных решений, которые могла бы позаимствовать большая поисковая система по вебу, рассчитанная на миллиарды документов. С другой стороны, не стоит забывать, что именно разработчики Lucene запустили проекты Hadoop и HBase (каждый раз, когда появлялась новая интересная статья от Google, авторы Lucene пытались применить озвученные решения у себя. Так, например, возник HВase, который является клоном BigTable). Однако эти проекты давно уже существуют сами по себе.

Для меня в Lucene/Nutch было интересно то, как они использовали Hadoop. Например, в Nutch для обкачки веба был написан специальный спайдер, выполненный целиком в виде задач для Hadoop. Т.е. весь спайдер – это просто процессы, которые запускаются в Hadoop в парадигме MapReduce. Это довольно необычное решение, выбивающееся за рамки того, как Hadoop используется. Ведь это платформа для обработки больших объёмов данных, а это предполагает, что данные уже имеются. А здесь эта задача ничего не вычисляет или обрабатывает, а, наоборот, скачивает.

С одной стороны, такое решение подкупает своей простотой. Ведь спайдеру необходимо получить все адреса одного сайта для обкачки, обходить их друг за другом, сам спайдер тоже должен быть распределённым и запускаться на нескольких серверах. Вот мы и делаем мэппер в виде разделителя адресов по сайтам, а каждый индивидуальный процесс выкачки реализуем в виде редьюсера.

С другой стороны, это довольно смелое решение, потому что сайты обкачивать тяжело — не каждый сайт отвечает за гарантированное время, и вычислительные ресурсы кластера тратятся на то, чтобы он просто ждал ответа от чужого веб-сервера. Причём проблема «медленных» сайтов всегда есть при наличии достаточно большого количества адресов на выкачку. Спайдер за 20% времени обкачивает 80% документов с быстрых сайтов, потом тратит 80% времени в попытках обкачать медленные сайты – и практически никогда не может их обкачать целиком, всегда приходится что-то бросать и оставлять «на следующий раз».

Мы некоторое время анализировали такое решение, и в результате отказались от него. Пожалуй, для нас архитектура этого спайдера была интересна как, своего рода, «отрицательный пример».

Подробнее о структуре нашего поисковика, о том, как мы строили поисковую систему, я расскажу в следующем посте.
Автор: @alkalinin

Комментарии (54)

  • +4
    Спасибо за такой сравнительный обзор и ваши выводы — ждем продолжения!
  • 0
    >Если поисковик по каким-то причинам недоступен, пользователи не сидят и не ждут, когда он, наконец, заработает — они просто идут в другие системы (например, мы отчётливо видели это по счётчикам LiveInternet год назад, во время сбоев у одного из наших конкурентов)

    Мне кажется ситуация была ровно обратная, основная часть никуда не перешла.

    Хотя конечно те, что всё же перешли, создали ощутимый эффект на поисковик с небольшой долей.
    • +2
      Вы правы в количественном отношении.
      Я это показывал в выступлении на РИФе, тут есть слайд под номером 5 с иллюстрацией: go.mail.ru/blog/2012/04/27/pochemu-lyudi-menyayut-poiskovik/

      Было 70 тысяч переходов, вместо этого 20-25 тысяч ушли к конкурентам.

      Но в качественном отношении — это же очень много! Когда почта лежит, такого не случается.
      Кроме того, после восстановления работоспособности сервиса, кто-то всё-равно остаётся на новом поисковике.

      Понятно, задачи есть разные, что-то нужно искать прямо сейчас, а что-то и потерпит. Но поведение людей отличается.
  • 0
    На самом деле, в самом Lucene реализовано не так много интересных решений, которые могла бы позаимствовать большая поисковая система по вебу, рассчитанная на миллиарды документов.
    А чего не хватает если по существу? Или просто «Java/gc тормозит»?

    С другой стороны, это довольно смелое решение, потому что сайты обкачивать тяжело — не каждый сайт отвечает за гарантированное время, и вычислительные ресурсы кластера тратятся на то, чтобы он просто ждал ответа от чужого веб-сервера.

    Мы некоторое время анализировали такое решение, и в результате отказались от него. Пожалуй, для нас архитектура этого спайдера была интересна как, своего рода, «отрицательный пример».

    Я так и не понял, вы отказались от этого решения потому что «вычислительные ресурсы клатера тратятся на то, чтобы он ждал ответа от чужого веб-сервера»? Как вы решили эту проблему — отказались от индексирования медленных сайтов вообще или решили тратить вычислительные ресурсы «другого» кластера?
    • +3
      А чего не хватает если по существу? Или просто «Java/gc тормозит»?

      Я лично не считаю Java безусловным недостатком, но на поисковом кластере по-моему логичнее использовать C/C++. Потому что там оптимизация оправдывается, а её выполнять проще на этих языках.

      По существу же ответ тут будет пространный, это же ведь и не недостаток, в общем-то, это просто разные задачи. Lucene — это универсальный движок, а веб-поиск заточен под конкретное применение и в нём, во-первых, много конкретных оптимизаций, сделанных под имеющиеся данные и важные для производительности (реализация эшелонирования как самый простой пример) и, во-вторых, сам движок невелик по отношению ко всякой обвязке, вокруг него накрученной. Тут и организация апдейтов, и failover и т.п. Про это редко рассказывают и, на мой взгляд, это самое интересное.

      В качестве иллюстрации вещей, специфичных для индекса, приведу первое, что приходит в голову — стоп-слова. Как решена проблема стоп-слов в Lucene? Они выкидываются. Но если их выкидывать, то становится сложнее искать цитатные запросы, т.е. выкидывать нельзя (а то [что где когда] не найдётся). А что делать, если не выкидывать? Относиться к ним как к обычным словам нельзя, они же большие, просто так ходить по их координатным блокам — мучение. Вот это уже интересный вопрос, решение которого требует некоторой смекалки и изворотливости.
      (Я, конечно, может и ошибаюсь, я Lucene сильно не изучал, может там всё иначе. )

      Сильная сторона Lucene — API, настройка на разные языки. Возможность внедрить к себе и не задумываться о том, что внутри поиска происходит. Часто именно это и нужно, но в веб-поиске движок дотачивается под поиск.

      И, повторю, из Lucene, наоборот, очень много чего интересного отпочковалось — Hadoop, HBase.

      Я так и не понял, вы отказались от этого решения потому что «вычислительные ресурсы клатера тратятся на то, чтобы он ждал ответа от чужого веб-сервера»?Ну, в реализации Nutch'а это получается так. Если один редьюсер хватает урлы одного сайта, то он будет качать их с паузами (он же «вежливый»?) и слот будет всё это время простаивать.

      Как вы решили эту проблему — отказались от индексирования медленных сайтов вообще или решили тратить вычислительные ресурсы «другого» кластера?

      В некотором смысле, «решили тратить ресурсы другого кластера» :)
      Дело в том, что выкачка это довольно простой процесс и, главное, постоянный. Соответственно процессы, обкачиваю
      • +1
        Не дописал до конца, продолжаю.

        Я так и не понял, вы отказались от этого решения потому что «вычислительные ресурсы клатера тратятся на то, чтобы он ждал ответа от чужого веб-сервера»?

        Ну, в реализации Nutch'а это получается так. Если один редьюсер хватает урлы одного сайта, то он будет качать их с паузами (он же «вежливый»?) и слот будет всё это время простаивать.

        Как вы решили эту проблему — отказались от индексирования медленных сайтов вообще или решили тратить вычислительные ресурсы «другого» кластера?

        Медленные сайты нельзя не качать, теряется полнота поиска.
        Поэтому, «решили тратить ресурсы другого кластера» :) Но он специфический, не такой, какой требуется для вычислительных задач.

        Дело в том, что выкачка это довольно простой процесс и, главное, постоянный. Он требует сетевых ресурсов, диска и, по сути, больше ничего. Hadoop для этого не нужен. Можно очень просто сделать процесс, который качает список урлов в 10000 потоков и сохраняет на локальный диск, сервера под это нужны не очень мощные. Hadoop нужен, чтобы готовить списки документов на выкачку (приоритезация, подавление дублей и т.п.), для сохранения результатов и их последующей обработки.

        В принципе, можно такой же процесс, асинхронно и во много потоков качающий сайты, реализовать и в виде редьюсера. Но, с другой стороны, мне очень не нравится идея запускать «вдруг» процесс, который может съесть значительное количество открытых файловых дескрипторов на сервере. Причём, на случайно выбранном сервере из кластера. А там и так могут быть проблемы с этими дескрипторами, потому что их довольно много требуется для работы регионсерверов HBase.

        То есть, если пойти на принцип, «делаем всё в Hadoop'е», то можно реализовать. Но проще вынести.
        • 0
          А как вы решили проблему noize words, о которой упомянули в контексте lucene?
          • 0
            Сорри, ниже вы как про них пишете
      • 0
        Тут и организация апдейтов, и failover и т.п.
        Ничего стандартного в этом отношение пока нет, но скорее всего потому что условия у каждого разные. Solr Сloud использует ZooKeeper для хранения конфигурации кластера (шарды, лидеры, реплики) и leader election, ElasticSearch zero discovery с броадкастом и тд.

        Как решена проблема стоп-слов в Lucene?
        Можно выкидывать, можно сохранять, можно делать и то и то в разные поля и просто бустить результаты с точным совпадением включая стоп слова. Проблема цитатных запросов со стоп словами решается индексированием N-gram-ов (и соот-ей обработкой запроса в момент поиска). Рассказали бы про ваше хитрое решение — очень интересно.

        но на поисковом кластере по-моему логичнее использовать C/C++. Потому что там оптимизация оправдывается, а её выполнять проще на этих языках.
        Я слышал мнение, что задачу обьединения результатов поиска от разных shards и отдачу пользователю некоторые реализуют на C/C++ потому что паузы GC здесь очень критичны, паузы на самих же поисковых нодах можно просто игнорировать по таймауту и возвращать неполные результаты поиска.

        Если один редьюсер хватает урлы одного сайта, то он будет качать их с паузами (он же «вежливый»?) и слот будет всё это время простаивать.
        Насколько я понимаю один редьюсер держит различные очереди для каждого топ левел домена (или айпи) и обрабатывает их паралельно. Если же осталась одна очередь с медленным сайтом, то наверняка можно решить проблему таймаутами или какой-нибудь эвристикой (дропать или вообще выбирать урлы с учетом скорости сайта?) или уменьшением кол-ва страниц скачиваемых одним редьюсером / увеличением кол-ва редьюсеров. Вообщем, является ли это глобальной проблемой при использовании nutch, которая никак не решилась в вашем случае?
        • +2
          Ничего стандартного в этом отношение пока нет, но скорее всего потому что условия у каждого разные.

          Да, я примерно это и имел в виду. При этом Вы справедливо напоминаете про Solr Cloud — про него я забыл, там действительно есть интересные фишки.

          Рассказали бы про ваше хитрое решение — очень интересно.

          Рассказывать конкретно слишком уж много получится, в общих чертах.

          Вы правильно рассуждаете, про N-граммы. Но ведь просто взять и построить N-граммы для всего потока — это увеличить объём индекса как минимум вдвое (это если индекс не сжатый и если хранить слова и биграммы), а скорее и втрое-вчетверо (но реальное увеличение нужно проверять, индекс биграмм по-моему должен хуже сжиматься, чем индекс слов), а словарь — так на порядок. Поэтому индексировать все N-граммы только для того, чтобы при необходимости представить запрос в виде N-грамм довольно дорого (индекс же кладётся в память; если на диск — то без разницы, но поиск медленный получается).

          Поэтому все N-граммы строить нельзя, надо отбирать нужные. Нужны, очевидно, N-граммы со стоп-словами. Допустим, всё-таки, речь идёт о биграммах, тогда на каждое стоп-слово есть две биграммы (для последовательностей слов A S B, где S — стоп-слово, получается две биграммы, AS и SB). Проблема в том, что если сохранять в индексе обе, то они тоже будут занимать значительное место, 30-50% от объёма индекса. Поэтому нужно отбирать по одной биграмме. Как отбирать — просто так не понять, в каких-то случаях нужны одни биграммы, в других — иные (а неправильно выделенные биграммы начинают мешаться). Например, для запроса [что было бы если футурама], где «что было бы если» это название серии, а «футурама» — название сериала, биграмма «если-футурама» будет вредна и не нужна, т.к. цитатность здесь важна только в первой части запроса, а футурама может болтаться в документе где угодно.

          Поэтому отбор биграмм становится тесно связан с сегментацией запроса на части, выделением объектов из запросов и текстов и т.п.

          Я слышал мнение, что задачу обьединения результатов поиска от разных shards и отдачу пользователю некоторые реализуют на C/C++ потому что паузы GC здесь очень критичны, паузы на самих же поисковых нодах можно просто игнорировать по таймауту и возвращать неполные результаты поиска.

          Нет-нет, это мнение, на мой взгляд, совершенно неправильное и вредное.
          Неполные результаты поиска это очевидное зло, нельзя на него полагаться как на штатную ситуацию. Могу, кстати, сказать, что мы, с 2010-го года, сократили количество неполных результатов в потоке порядка на три, каждый раз считая что вот теперь-то у нас наконец-то стабильный поиск. А когда привыкаешь к низким числам в этой статистике, оглядываешься на старые показатели и думаешь, «вот ужас-то был».

          При этом GC на бэкендах будет возникать в разное время, тем самым неполные результаты будут возвращаться не с частотой запуска GC на одном бэкенде, а помноженное на общее количество бэкендов, Когда их число начинает быть кратным сотням это становится существенным.

          Поэтому служебные действия на бэкендах правильно выполнять синхронно, минимизируя общее время, когда кластер отвечает неполно. В это время можно жить на кеше, можно использовать второй кластер (если он есть) для подстраховки.

          Но насколько я знаю, если такие вещи пишут на Java, то вообще пытаются не полагаться на собственный аллокатор, чтобы не бороться с GC. Выделяют памяти от пуза и уже работают с ней самостоятельно. Но я тут как раз перестаю понимать, зачем пользоваться Java, когда C/C++ есть :)

          Вообщем, является ли это глобальной проблемой при использовании nutch, которая никак не решилась в вашем случае?

          Да мы Nutch не использовали, мы своё писали. И у нас была такая мысль, сделать выкачку на том же кластере, что и всё остальное, «раз платформа есть». Но я просто считаю, что если задача хорошо и просто отделяется, отличается от остальных задач, то её нужно отделять. Выкачка, как я написал выше, очень специфична, ей требуются другие ресурсы. И, в общем, ни разу об этом решении не пожалели.

          А то ведь и сёрчеры тоже можно как-нибудь на Hadoop'е запустить, в принципе.
          • 0
            Про то, что энграммы (или биграммы в простейшем случае) нужно строить хитро если обьемы большие это понятно. Не понятно почему вы сделали вывод, что этого нельзя сделать в Lucene. Вообще, возможности кастомизации анализа текста в Lucene очень гибкие (как компоновкой существующих tokenizer/tokenfilter так и написанием своих компонент).

            Про интерактивные приложения и GC — я не говорю про то, что нужно отказаться от мониторинга/оптимизации GC совсем, только что это не так критично как думают «java is slow» адепты.

            На fetcher кластере все равно нужно
            а) сохранять скачанное (в hdfs/hbase?)
            b) как-то помечать что скачано/что нет (в hbase?)

            Вообщем, мне не понравилось резкость вывода «отрицательный пример» без подробного и вдумчивого анализа. А вообще, правильный способ был бы начать обсуждение в Nutch мэйлинг листе со всеми вашими опасениями и в идеале засабмитить патч (open source way так сказать).
            • +1
              Не понятно почему вы сделали вывод, что этого нельзя сделать в Lucene. Вообще, возможности кастомизации анализа текста в Lucene очень гибкие (как компоновкой существующих tokenizer/tokenfilter так и написанием своих компонент).

              Я же написал — сильная сторона Lucene это API. Сделать через него можно многое, но меня же интересовала конечная архитектура, а не конструктор. Вот реализации того, что я сказал, там же нет? То есть, если я знаю как, я могу это сделать в Lucene. Но знакомятся с чужими проектами для того, чтобы найти новые идеи, посмотреть, как это делается.

              Про интерактивные приложения и GC — я не говорю про то, что нужно отказаться от мониторинга/оптимизации GC совсем, только что это не так критично как думают «java is slow» адепты.

              Алексей, заметьте, это вы написали про GC впервые, а не я. Я же как раз и сказал, что это не так критично, но C/C++ мне кажется в этом месте логичнее.

              На fetcher кластере все равно нужно
              а) сохранять скачанное (в hdfs/hbase?)
              b) как-то помечать что скачано/что нет (в hbase?)

              Нет, это как раз уже вычислительные задачи в моём понимании, т.е. это не «фетчер-кластер», а обычный HBase.

              Вообщем, мне не понравилось резкость вывода «отрицательный пример» без подробного и вдумчивого анализа.

              Это, конечно, отрицательный пример и Вы меня не переубедили. Выше в обсуждении я написал, почему я так думаю — про расход ресурсов, про иные потребности задач.

              А вообще, правильный способ был бы начать обсуждение в Nutch мэйлинг листе со всеми вашими опасениями и в идеале засабмитить патч (open source way так сказать).

              Я же говорю, Nutch мы не используем и он нам не подходит, поэтому обсуждать и, тем более, патчить было бы для нас лишней потерей времени.

              Мы используем HBase и там, да, мы и обсуждаем, и патчим. Вот пример самого эпического патча, повышающего скорость сканов с фильтрами и «перекошенными» по составу колонками в 10-20 раз: issues.apache.org/jira/browse/HBASE-5416. Это полгода тестирования, между прочим, хождения по самым разным граблям. Но это действительно полезный патч, на мой взгляд.
  • 0
    Извините за оффтоп, но давно хотел спросить у представителей Поискаmail.ru, как вы относитесь к тому что ваш Браузер и Спутник распространяется с помощью вирусов, подписанных вашей цифровой подписью, это Ваша политика дистрибуции?
    • +2
      Конечно, нет.
      Пришлите мне, пожалуйста, на kalinin@corp.mail.ru, откуда Вы скачали наши продукты с вирусами.
      • –1
        Куча платных архивов (да-да, те которые раскрываются за смс) ставят тулбар, многие даже без галочек.
        • +1
          Пришлите, пожалуйста, на kalinin@corp.mail.ru примеры таких архивов.
      • 0
        Добрый день! Вот пример сайта откуда можно скачать екзе, подписанный подписью майл ру, который ставит браузер и тулбар. Ранее еще ставил игровой центр.
        skan.ru/software/n10590_flv_converter.html кликаете на кнопочку «Скачать FLV Converter» далее через сайт Loadmoney.ru вас перекидывает на сервера майл ру откуда качается файл, подписанный подписью майл ру, при этом определяющийся многими АВ компаниями — как вирус. Пример скана с вирустотала:
        www.virustotal.com/file/eafad56e117823e9961551c2ff05742051e39d9c86d995685fff5264537faec0/analysis/

        Да, обратите внимание, как завуалированы галочки на этом «загрузчике от майл ру». Кроме того — ставится одновременно и тулбар и ваш «браузер», который обвешивает ярлыками пол рабочего стола — с различными «полезными сервисами от майл ру». Забавно…

        P.S. А потом появляются статьи на роеме вида roem.ru/2012/08/14/mailfalsealarm52810/
        • 0
          PPS: Продублировал сообщение вам на почту.
        • 0
          Конечно же это не они. Обязательно с этим разберутся. Не переживайте.
        • 0
          Это наша большая головная боль.

          Дело в том, что этот файл, на котором срабатывают некоторые антивирусы — это наш загрузчик, он и подписан нашей цифровой подписью. И вирусов там нет.

          Вы посмотрите, что они там детектят, это всё эвристики проактивной защиты. Например, McAfee определяет его как Artemis с какой-то контрольной суммой, т.е. это срабатывание эвристики + контрольная сумма файла, на котором она сработала, вот тут у них больше полутысячи жалоб на неё: community.mcafee.com/community/security/malware_discussion/artemis?view=discussions

          Некоторые пишут что это Downloader — это, в общем, справедливо; он действительно дальше скачивает тот файл, который нужно загрузить. Но это не вирус, не троянский конь.

          С антивирусными компаниями мы общаемся, с некоторыми всё удачно проходит, а некоторые демонстрируют тут какую-то отмороженность, заявляя просто что они нас не любят и поэтому будут срабатывать и дальше. В некотором смысле, это всё те же элементы браузерных войн.
          • +1
            Андрей, получается так, что вы, как бы, ни при делах, это все партнеры гадят, но ведь неправда, что вы никак не способствуете распространению этого треша.
            Создается партнерская программа, которая оказывается порою выгоднее, чем распространение всяких вирусов:
            forum.searchengines.ru/showthread.php?t=709778
            forum.searchengines.ru/showthread.php?t=709778&page=28
            forum.searchengines.ru/showthread.php?t=709778&page=61
            И какие-то люди обсуждают, почему антивирусы на ваш софт ругаются. Да правильно ругаются — там куча PUA, нарушаются все правила и лицензии. Еще отчетливо видно, что эти люди — спамеры, манимейкеры… «Палево, конверт, траф»… это все очень дурно пахнет. И Вы-то понимаете, что это такое.

            Кроме того, есть куча «софт-порталов», где ссылки на скачивание файла ведут не на сам дистрибутив непосредственно, а на некий «download manager». Сперва пользователю устанавливается download manager, по сути дублирующий функционал закачки браузера, который затем скачивает запрошенный файл (а файл не всегда именно то, что вы хотели).

            Как только вы скачиваете и запускаете download manager, в вашем ПК появятся Спутник и Защитник от мейл.ру, при этом никаких галочек — соглашений про установку дополнительного софта, у пользователя не спрашивают.

            Т.о. download manager от Mail.ru не предоставляет пользователю никакого дополнительного полезного функционала, единственная цель его существования — поставить Спутник и Защитник от мейл.ру. На софт, который распространяется с помощью этого де-факто никаких ограничений не накладывается, т.е. это могут быть крякнутые официальные программы, ключи для анлока Win7 и т.п.

            Очевидно, что вы потворствуете созданию огромного количества псевдосайтов, которые предлагают что-то такое скачать. Они низкого качества, с ними рядом ходит всякое мошенничество типа платных смс-архивов и т.п. И если вам кажется, что вы делаете что-то хорошее (типа, школота не вирусы распространяет, а безобидный mail.ru), то вы ошибаетесь. Те же люди, которые участвуют в ваших партнерках, набравшись опыта и заработав денег, через некоторое время все засрут. Экология нарушается, мошенничества становится все больше. Вам это надо? Или плевать на все, лишь бы сейчас бабок срубить, а что после нас хоть потоп? Зачем же так гадить, Андрей?
            • +1
              О, Яндекс.
              Понимаю.

              Сергей, привет!

              Как только вы скачиваете и запускаете download manager, в вашем ПК появятся Спутник и Защитник от мейл.ру, при этом никаких галочек — соглашений про установку дополнительного софта, у пользователя не спрашивают.

              Неправда.

              Остальной плач Ярославны я комментировать не хочу, этическая истерика она такая, бороться с ней себе дороже. Ну что мне сказать тебе, что за партнёрами следят, их отстреливают, и что нам тоже это не надо, боремся с этим?

              Или что каналы дистрибуции не резиновые, и если что-то занял Яндекс или Гугл, то никому туда больше не попасть?

              Но ты же ведь уже вывод сделал:

              Вам это надо? Или плевать на все, лишь бы сейчас бабок срубить, а что после нас хоть потоп? Зачем же так гадить, Андрей?

              И вот только Яндекс, весь в белом…

              Сергей, в общем, не хочу я устраивать тут срач между двумя компаниями. Вам всё мешает: Гугл мешает (см. интервью, которое я процитировал выше), Mail.Ru мешает, вы этими двумя компаниями недовольны. Ну и хорошо, лично я бы очень сильно бы напрягся, если бы ты нас похвалил.
              • 0
                В этом смысле вас хвалить не за что.
                Вот пример неправды, кстати: nero-free.ru/ — инсталл за смс, даже в случае отмены установки без предупреждения устанавливает полный набор от мейл.ру. Очевидно, вам невыгодно отстреливать таких замечательных партнеров :) Или вот: icqskype.com/8-skajp-skachat.html И таких — тьма. Если мы вам пришлем списочек таких сайтов — откажетесь от их услуг?

                Кстати, я вообще из антиспама, я дистрибуцией не занимаюсь. Просто вижу, что плодится большое количество говносайтов специально под ваши партнерки. И если вам от этого польза, то — это временно.

                Что касается каналов дистрибуции… Это как идти расклеивать объявления на столбах, остановках, в метро, электричках и в других неподходящих местах, засирая все вокруг, оправдываясь тем, что на более приличную работу ты не устроился.
                • +1
                  Вот пример неправды, кстати: nero-free.ru/ — инсталл за смс, даже в случае отмены установки без предупреждения устанавливает полный набор от мейл.ру. Очевидно, вам невыгодно отстреливать таких замечательных партнеров :) Или вот: icqskype.com/8-skajp-skachat.html И таких — тьма. Если мы вам пришлем списочек таких сайтов — откажетесь от их услуг?

                  Присылай, конкретика меня интересует. Проверим, а там либо предупредим, либо откажемся. Моя почта у тебя есть, но всё равно: kalinin@corp.mail.ru

                  Что касается каналов дистрибуции… Это как идти расклеивать объявления на столбах, остановках, в метро, электричках и в других неподходящих местах, засирая все вокруг, оправдываясь тем, что на более приличную работу ты не устроился.

                  Смотри, устроить этическую истерику можно по любому поводу. Например.
                  Вот вы ставите тулбар с uTorrent'ом. Для чего используется uTorrent? Что через него качают? Вы, значит, поддерживаете пиратов, крекеров и далее по списку того, что там лежит?
                  И какой дополнительный функционал несёт с собой тулбар, который ставится пользователю?

                  Ну это я так, без надрыва — просто наметил, прошёлся по твоему списку.

                  Но факт остаётся фактом, лидер занимает самые лучшие места, потому что пришёл первым. В России лучшие места заняты Яндексом, а в мире, между прочим, Гуглом. И Волож, к примеру, утверждает, что это недобросовестная конкуренция со стороны Гугла, не пускать туда никого, кроме себя.

                  А работа мне моя нравится, тут интересно.
                  • 0
                    И какой дополнительный функционал несёт с собой тулбар, который ставится пользователю?

                    Ага, и что там с пополнением поискового индекса (урлов) шпионской программой тулбар? Или метрикой? Чем там закончилась эпопея?
                  • –1
                    Интересно, как майл ру всегда в подобного рода вопросах переводит стрелки на конкурентов :)

                    Даже если не брать во внимание то, что яндекс ставит ТОЛЬКО свой тулбар, а Майл ру навязывает 1. тулбар 2. браузер и да, при старте системы ПОСТОЯННО открывает IE со своей стартовой — что очень сильно тормозит загрузку в целом. А при открытии других браузеров вместо одной стартовой открывается ТРИ! И все — майл ру или же одноклассники. Дак вот даже если не брать это во внимание — просто сравните как ставятся «сервисы» от майл ру и от яндекса:

                    Яндекс
                    s2.ipicture.ru/uploads/20120828/ro7Kc641.jpg

                    Маил
                    s2.ipicture.ru/uploads/20120828/VkDVNPMX.jpg

                    Разница видна невооруженным глазом. И да — все дело — именно в СТЕПЕНИ навязываемости, которая у майл ру просто зашкаливает.
                    • +2
                      Интересно, как майл ру всегда в подобного рода вопросах переводит стрелки на конкурентов :)

                      Конкуренты сами пришли. :)

                      Разница видна невооруженным глазом.

                      Ну, обычно оно всё-таки иначе выглядит, как-то так: s2.ipicture.ru/uploads/20120828/9ND7mR32.png

                      По кликам идентично, два клика у нас, два клика у Яндекса.
                      По составу, наш вариант на этом скриншоте, более сильный, да. Мы конечно будем дальше экспериментировать, чтобы он устанавливался более целенаправленно.

                      PS. Про автоматическое открытие браузера — это не мы, это у Вас кто-то другой его открывает.
                      • –4
                        Мне вот интересно — я читаю вашу статью — и вижу там одну манеру общения. Читаю ваши посты — и вижу тут совсем другое :) Это так за вас через ваши уста кто то передает «политику» компании?

                        И да — по поводу скрина — да есть и такой вариант установки яндекс бара. Но согласитесь, он куда более честный, чем какая то малозаметная стрелочка у вас.

                        P.S. И да — хватит уже выгораживать компанию, где вы работаете. Вы ниже сами сказали — что не видите другого способа достучаться до вашего пользователя. А не видите потому — что вы думаете ТОЛЬКО о деньгах, и вам нужно отжать все очень быстро, и с минимальными вложениями. Вот и устроили такой балаган с дистрибьюцией. Вместо того чтобы развивать сервисы, и ЖДАТЬ пока люди сами к вам придут ПОСТЕПЕННО, вы решили действовать агрессивно, не думая о последствиях. Но они будут. Обязательно =)

                        А насчет интернет експлорера — я думаю было бы странно, если бы его кто то открывал кроме вас, на вашей стартовой. Кому это нужно? И это не только на моей машине. Хватит врать.
                        • 0
                          image

                          Ооо да, особенно вот тут, ага
                        • +6
                          image

                          Особенно вот тут, ага
                          • –2
                            А вы тоже в Mail.ru работаете, если не секрет?
                            • +1
                              Пока нет, но все надеюсь. А вы?
                            • 0
                              Вообще, мне тоже временами казалось, что активные участники этого треда имеют какое-то отношение к Яндексу.

                              Но это не так. Вот NFM, к примеру, судя по всему был организатором своих партнёрских программ: forum.searchengines.ru/showthread.php?p=5490475#post5490475
                              forum.searchengines.ru/showthread.php?p=6149319#post6149319
                              Ну, т.е., скорее всего, конкурент той партнёрки, на сайты которой он жаловался.
                              А сейчас занимается, сложно в это поверить, распространением своего тулбара: forum.searchengines.ru/showthread.php?t=658686
                              (nicetest — название старой партнёрки)

                              Тот ещё серпентарий, в общем.
                  • +2
                    Так расклейщикам объявлений, может, тоже интересно. А вот жителям города уже не очень… Ну что ж, твой выбор :)

                    Вот несколько примеров:
                    win-planet.com/office/17-skachat-microsoft-office-2010-na-russkom-yazyke-besplatno.html
                    sozdanie-prezentacii.ru/
                    photoshop-adobe.com/
                    antivirus-ok.com/index.php/antivirus-kaspersky
                    nero-10.ru/
                    download-powerpoint.programma-free.ru/
                    hdfile.ru/810-microsoft-office-full.html
                    down-office.ru/
                    office.programmatut.ru/
                    download-powerpoint.com/

                    + распространение установщика mail.ru под видом другого ПО — openprog.ru/opera

                    Интересно, что с ними станет недели через две :)
                    • 0
                      Openprog.ru как мы видим по ссылке ниже, принадлежит админам партнерской программы которая реселит mail.ru всем желающим вебмастерам.

                      forum.searchengines.ru/showpost.php?p=10779540&postcount=601
                    • 0
                      Я ссылки передал, спасибо.
                      • +2
                        Вы сами вебмастерам и платным архивам дали реселить Спутник и Браузер, а теперь передаете ссылки на проверку? Вам не кажется, что это смешно?))
                        • 0
                          У нас есть требования к партнёрам, если они их не выполняют — мы с ними прекращаем работать. Партнёрскую сеть мы проверяем, а так же разбираемся по жалобам.
                          • +2
                            И да, про вас же уже давно статьи на дрвебе пишут, и про этот openprog и loadmoney. Почитайте: www.ferra.ru/ru/soft/news/2012/08/22/drweb-ZIPPRO/
                            www.ferra.ru/ru/soft/news/2012/08/15/drweb-Trojan-Mayachok-1/

                            Как вообще майл мог докатиться до того, чтобы распространяться ВООБЩЕ без галочек да еще и с БАНКОВСКИМИ ТРОЯНАМИ. Какие черту жалобы? Статьи вон пачками в интернете валяются. Кругом репосты. Погуглите.
  • +2
    Очень интересно. Ждем продолжения.
  • –10
    да у вас поиск от яндекса, о чём вы вообще?
    • +7
      Ваш ник говорит сам за себя. Давай,… ну вы поняли.
    • +5
      Там в начале ссылка на предыдущий пост, где написано про то, как и когда у нас появился поиск.
      Поиск от Яндекса был до 1-го января 2010-го года.
      Потом был наш поиск.
      Потом комбинация нашего поиска и поиска от Google.

      В общем, мы всех запутали, но поиск у нас есть, о нём и рассказываю.
  • НЛО прилетело и опубликовало эту надпись здесь
    • +3
      Я описал причины существования и распространения Спутника в начале статьи.
      Он нужен как минимум в виде ответа на тулбары других компаний.
      • НЛО прилетело и опубликовало эту надпись здесь
        • +4
          Я Вас понимаю.

          Но дело в том, что качеством продукта новых пользователей привлечь нельзя. Качество — это то, что оставляет пользователей у сервиса. То есть, сервис хороший, пользователю понравился, он остался на нём. Сервис не понравился, не привычен — пользователь сбежал.

          Но для того, чтобы этот процесс запустить, пользователь должен увидеть сервис. И вот эта задача для поисковиков и порталов решается, к сожалению, тулбарами и браузерами. Почему так получилось, я написал в статье.

          Для Mail.Ru же здесь довольно интересно — нас не воспринимают (не воспринимали?) как поиск. Средний пользователь РуНета пользуется почтой Mail.Ru и поиском Яндекса. Но люди банально не видят у нас поисковой строчки, не замечают её. Хотя по суммарной аудитории Mail.Ru и Яндекс примерно одинаковы. Как дать людям возможность понять, что у нас есть поиск тогда?
          • –3
            Для Mail.Ru же здесь довольно интересно — нас не воспринимают (не воспринимали?) как поиск. Средний пользователь РуНета пользуется почтой Mail.Ru и поиском Яндекса. Но люди банально не видят у нас поисковой строчки, не замечают её. Хотя по суммарной аудитории Mail.Ru и Яндекс примерно одинаковы. Как дать людям возможность понять, что у нас есть поиск тогда?

            Взгляните на ya.ru — там только поиск, может и вам стоит что-то похожее придумать )
  • –2
    История с дистрибуцией действительно печальная. Выход-то есть? Или «смотрите что ставите, дорогие юзеры», а поисковики так и будут использовать все способы заполучить малограмотную аудиторию?
    • +1
      Выход, судя по всему, не за горами.

      Во-первых, меняются платформы. PC с Windows в его текущем виде это, всё же, профессиональный инструмент. Пользователю, которому нужно ограниченное количество программ он в таком виде не требуется, смартфоны и планшеты с централизированным способом установки стороннего ПО уже удовлетворяют нужды обычных пользователей.

      А в этих платформах всё значительно жёстче, там уже не производитель браузера, а производитель платформы контроллирует поставщика поиска. В iOS в Safari поиск может быть любым, если это Google, Yahoo или Bing. То есть, новая версия Windows, новый способ установки ПО — и всё, все сидят на Bing'е (но это я утрирую, как раз Microsoft'у могут такого и не позволить сделать, монополист, «империя зла» и т.п.).

      Во-вторых, меняется интерфейс поиска. Если посмотреть на тот же Siri, то можно заметить, что это, хоть и пока что не очень функциональный, но прототип «поиска будущего». Ты ему вопрос, а он тебе — ответ. И тогда уже само мобильное устройство превращается в поисковую систему, а что там внутри, в какой реальный поиск оно транслирует запрос, может быть и не очень важно, поисковик (в современном виде) превращаются в какую-то малопонятную деталь под капотом смартфона, куда никто не добирается.

      И тогда «браузерные войны» превратятся уже в «войны платформ».
  • 0
    >Подробнее о структуре нашего поисковика, о том, как мы строили поисковую систему, я расскажу в следующем посте.

    если он уже вышел, сделайте пожалуйста ссылку в конце статьи
  • 0
    В статье есть некоторая неточность.
    Cassanda
    — Наверное все таки имелась ввиду Cassandra.
    Cassandra создана не по подобию BigTable, а по white-paper от Amazon о Dynamo DB.
    • 0
      Спасибо, исправил.

      Cassandra создана не по подобию BigTable, а по white-paper от Amazon о Dynamo DB.

      Да, совершенно верно, но по-моему Dynamo можно считать родственником BigTable — а уж оттуда и родственность Кассандры. Там много отличий, но в целом для наших нужд теоретически подходили все такие решения, поэтому я их и упомянул вместе.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое Разработка