StasFomin: /* «Универсальный поиск вертикального поиска». Протасов Сергей, Плошихин Виктор (Рамблер) */

2010-08-18T16:37:49Z

‎«Универсальный поиск вертикального поиска». Протасов Сергей, Плошихин Виктор (Рамблер)

Новая страница

<blockquote>
Замечания и предложения высказывайте [http://alekseev-aleksey1.moikrug.ru/ автору].
</blockquote>

Отчет о посещении «[http://highload.info РИТ: Высокие нагрузки 2008]».

= День первый =

== «Что такое нагрузка?» Анатолий Орлов (Яндекс) ==

Первый доклад, который был фактически, вводным.
Анатолий Орлов (руководитель отдела инфраструктуры поиска яндекса) рассказывал об основных понятиях и проблемах работы нагруженных систем.
Было выделено три основных узких места: CPU, память и диск.

Самая решаемая, как я понял, проблема, это диск. Суть в том, что, во-первых, нужно учитывать специфику работы с диском. Основные тормоза — от «прокрутки» диска до нужного места, то есть все зло исходит от непоследовательно хранящихся данных.

Во-вторых, нужно купить несколько десятков дисков и заставить их работать параллельно.

Про память я плохо помню.
* Во-первых, многопоточность не ест много памяти в отличии от многопроцессорности, и разумно стараться обрабатывать каждую задачу в отдельном потоке, а не процессе.
* Во-вторых, сказано было, что вообще можно писать программы, чтобы самые важные куска данных хранились в кеше, причем отслеживать так ли это с помощью пацанских профилировщиков [http://valgrind.org/ Valgrind] и [[EnPedia:VTune|VTune]].

Про CPU сказали, что для систем, работающих над «real-time» задачами, желательна не полная загрузка процессора, а оставлять некоторый запас. Примером такой системы является, собственно, поиск яндекса.
Для остальных систем наоборот показателем эффективности является высокая (желательно 100 %) загрузка процессоров. Как правило, такие системы что-нибудь вычисляют сложное.

Еще была озвучена формула Димы Тейблюма:
число потоков = число ядер + число дисков + 5
(вместо пяти может быть произвольная константа).

== «Подходы к оптимизации производительности MySql». Григорий Рубцов (MySql, AB) ==

Доклад был адекватным. Докладчик явно в курсе, как работает система, и без стеснения называл недостатки. Да так, что после окончания доклада я понял, что от MySql нужно убегать.

Первый недостаток это запрос вида
Select … From … Where … Order by … Limit 1.

Этот запрос сначала создает временную таблицу, в которую складываются данные, удовлетворяющие условиям. Затем данные сортируются, причем если в таблице есть текстовое поле, то временная таблица создается на диске!!! Кэширование запросов происходит с учетом регистра символов в запросе.
Подзапросы не кэшируются.
Другие недостатки не помню, но они были.
Обещали половину проблем как-то устранить в шестой версии.

Сказал, чтобы не жалели память на <tt>query-cash</tt>, использовали индексы при необходимости, и активно пользоваться денормализацией.

== «Как писать высокопроизводительные сервера». Антон Самохвалов (Яндекс) ==

Существуют две концепции написания быстрых http-серверов. Первый — FSM, для обработки всех запросов в одном процессе и даже в одном потоке. При этом сервер подписывается на события и их обрабатывает. Примером является [[EnPedia:nginx|nginx]].

Вторая концепция, которую и пропагандирует докладчик — многопоточные сервера. Каждая задача обрабатывается в своем потоке. Примером является <tt>apache2.*</tt>. При этом пошли дальше и написали свои легкие «зеленые» треды — ''co-routine’s'', со своим переключение контекста. Основное преимущество в том, что при переключение только зеленых тредов не работает планировщик. Сказали, что обычных потоков можно запустить 10000, а зеленых и вовсе миллион. На этих зеленых тредах написаны метапоиск яндекса, и робот.

Дальше развернулась дискуссия между сторонниками первого и второго подхода. Минусы первого подхода, это плохая читаемость кода. Минус второго подхода — программа не должна генерировать исключений, и сложность отладки (с последним я не согласен). В процессе дискуссии сошлись, что скорость работы второго подхода равна скорости первого. Вообще преимущество самодельного http-сервера <tt>5-10 %</tt>, и писать его стоит только если очень припрет, пусть это и очень увлекательно.

== «HCS — система хранения данных в Рамблере». Павел Уваров (Рамблер) ==

Поисковые системы сначала выкачивают контент, его обрабатывают, а потом выдают пользователю. В рамблере обработка, вроде, работает на одной машине, и не требует конкурентной работы. Видимо, это и объясняет плохое качество Рамблера. Вся система достаточно простая, работает на файлах. Сортировка производится внешняя, операций удаления конкретных записей практически нет. Поэтому система работает намного быстрее СУБД. Докладчик приводил десятикратные и более преимущества в скорости его системы.

== «Проблемы работы с большими объемами реляционно слабо связанных данных в высоконагруженных веб-проектах». Илья Космодемьянский (SUP-Fabrik) ==

Очень неадекватный доклад, ИМХО. Ничего не понял.

== «Масштабирование системы баннерной рекламы с централизованной базой данных». Сергей Нековаль (Грамант) ==
Тоже очень странный доклад. Есть большое количество баннеров, есть еще большее их число показов. Каждый показ надо посчитать и потребовать за него денег.

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

= День второй =

== «DDOS, эволюция ботнетов и атак». Руслан Стоянов ==

Я опоздал минут на 10 и пожалел, доклад был местами очень интересным. Были всякие общие вещи, но самое интересное, это средства защиты, которые они предлагают, когда дидос уже постучался в дверь.

Пассивная защита. Это, во-первых, какие-то железяки, которые сами умеют регулярно очищать забитый канал. Во-вторых, пытаются на глаз отличить пакеты ботов, от пакетов обычных людей и устанавливают фильтр. А еще можно отключить <tt>UDP</tt>, и <tt>ICMP</tt>, если не требуется для работы, и целые классы атак станут невозможны.

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

Еще была пара интересных вопросов.
* Первый, могут ли простые люди писать ''abuse''. Докладчик сказал, что могут, но кто их будет слушать, и вообще это главное, за что им платят деньги.
* Второй интересный вопрос был про ботнеты без командного центра, на что было сказано, что этого они сильно боятся, и вообще придет глобальный коллапс, если конкуренты такие атаки действительно будут друг на друга натравливать.

== «Организация асинхронной обработки задач». Яков Сироткин (Яндекс-Деньги) ==

Доклад был минут на пять, вместо запланированного получаса. Из того, что понял, ничего интересного, ИМХО, не рассказали. Есть у них СУБД Oracle. Необходимо достаточно быстро обрабатывать изолированные задачи. Для этого их складывают в очередь и исполняют. У каждой задачи есть время, когда она должен выполниться, если не смогли выполнить, то увеличиваем это время в два раза. Сказал, что умножать на два это гениально, так как если еще их никто не прибил за то, что не исполнили задачу, значит и еще подождут. Да, еще сказал, что <tt>Oracle</tt> у них потому, что они не верят в ''Open Source'' (и денег много).

== «Практическое применение Hadoop в системе интернет-статистики». Михаил Яхшин, Spylog ==

Суть задачи в том, что у них есть много счетчиков на каких-то сайтах. Эти сайты посещает достаточно большое количество людей. Необходимо подсчитать количество показов страниц (сайта?) людям. Причем должны быть доступны разные виды отчетов, такие как подсчет уникальных посетителей, посетителей из заданного города и т д. Информации у них очень много, так показов у них порядка 400 млн в день, если не перепутал. Понятно, что ни в какой СУБД это не обработаешь и они применят для это распределенные вычисления, а именно
[[EnPedia:Hadoop|Hadoop]], ''Open Source''-продукт. Вообще это очень интересный продукт. Он предоставляет возможность распределенного хранения данных и организации распределенных вычислений в парадигме Map-Reduce. Проект пишут 16 программистов на Java, и он имеет порядка 4 млн строк кода!!
Его активно используют интернет-гиганты Yahoo, Facebook, и т. д. У Google своя подобная система, по аналогии с которой Hadoop и делался.

Докладчик очень внятно рассказал, как они борются с проблемами генерации отчетов о посещении. У них есть кластер из 12 машин, с 8 ядрами и 8 гигами на борту у каждой, если не ошибаюсь. Раз в час они запускают вычисления, в два прохода.
В первый проход из access-логов извлекается информация и представляется в удобном и экономном виде.
Во втором проходе, собственно, и подсчитывается статистика.
Причем у них есть три вида (или чуть больше) отчетов, для каждого из которых выбрана система координат (аналитик) 2-4, и для всех вариантов значений этих координат вычисляются суммы. Потом эти, уже маленькие, отчеты грузят в БД и отдают пользователям.

Было еще несколько слов про всякие проблемы: уникальные пользователи, которые не принимают или удаляют куки, и правильная склейка пользователей, из предыдущего и текущего часа.

== «CAS — сервер приложений на C++» Андрей Шетухин (Sup’Fabrik) ==

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

== «Виртуализация в среде highload servers». Вячеслав Вирняк (Parallels) ==

Рассказали, что бывают виртуализация двух типов.
Первый тип — система, которая сама распределяет ресурсы, и второй — надстройка на ОС.
Рассказывал докладчик, про второй тип виртуализации. Ничего про архитектуру вроде не было, а было про какие-то настройки.
Рассказал, что почти все квоты на процессор, память и жесткий диск можно менять на лету.

== «Контраварийные меры обеспечения работоспособности ресурсов при резком росте посещаемости». Дмитрий Криков (Мастерхост) ==

Доклад был посвящен сисадминам, у которых есть проект, а денег на его рефакторинг и переделку нет.
И ко всем бедам добавляется всплеск посещаемости.
Какие средства есть для повышения быстродействия продукта.
В общем, интересная тема, но писать про этот доклад долго.

== «Методики нагрузочного тестирования». Тимур Хайрулин (Яндекс) ==

Доклад был в стиле «каждый конкретный случай сложный, думайте головой».
Но было несколько интересных моментов.
* Во-первых, для каждого проекта команда думает над тем, что может произойти при работе системы. Для каждого события они оценивают вероятность. Потом сортируют по вероятности и для 10 самых вероятных событий пишут «What If». То есть что они будут делать, если это событие случится.
* Во-вторых, для проектов, которые они делают пиковая нагрузка на проект в π<sup>3</sup> больше, чем средняя нагрузка. Еще рассказал, что, прочитав книгу по теории вероятности, больше стал понимать в нагрузочном тестировании. Кто-то спросил про инструментарий для нагрузочного тестирования, сказал, что нормальный стоит бешеных денег, а для небольших проектов посоветовал [[EnPedia:JMeter|JMeter]].

== «Оптимизация производительности поисковой системы с учетом ранжирования». Михаил Костин (mail.ru) ==

Докладчик является создателем поисковика [http://gogo.ru/ GoGo.ru].
Все поисковики работают примерно одинаково. Получив запрос, они находят, в каких документах (или ссылках на документы) есть указанные слова, и для них высчитывается релевантность запросу, учитывающая сотни различных факторов. Затем документы сортируются по релевантности и выдаются пользователю.

Релевантность высчитывает тяжело, и если пользователь ввел часто встречаемое слово, то такой запрос будет обрабатываться долго, так как документов, содержащих это слово очень много.
Для оптимизации работы делается два прохода.
Во время первого прохода откидываются документы, которые «точно» не релевантные по какому-то правилу, а на втором проходе уже для оставшихся документов вычисляется тяжелая релевантность, учитывающая все признаки. При первом проходе используется модифицированный вариант BM25 (подробности можно найти в википедии), учитывающий зоны документов. Берется первые N документов, для которых уже производятся более тяжелые вычисления. Стоит сказать, что N, вообще говоря, не константа, а зависит от запроса, и количества найденного (вроде). Но N порядка нескольких десятков тысяч. Понятно, хотя нескорые в зале сомневались, что это практически не отражается на качестве поиска. На первых страницах все почти тоже самое.

Пообщался с Михаилом в кулуарах, спросил, как это работает для крылатых фраз, широко растиражированных в Рунете. Решили, что тут могут быть проблемы, но думаю, что победить их не трудно, Также предложил ему вариант идеи Стаса про управление выдачей или какими-то ее элементами простыми людьми. Вроде все его сомнения у меня уже возникали, и я на все вроде предложил какие-то решения. Будем ждать, вдруг решаться….

{{note}} [[Участник:StasFomin|Стас Фомин]]: Это мои идеи, которые я так [http://forum.yandex.ru/yandex/improve.xhtml?message_id=1108699 мечтал продать Яндексу], и которые даже в Гугле не сработали (сдохший SearchWiki).

== «Универсальный поиск вертикального поиска». Протасов Сергей, Плошихин Виктор (Рамблер) ==

Суть вертикального поиска в том, чтобы облегчить работу пользователю с информацией (НАКОНЕЦ-ТО!!!). Сделано все не ахти, но я думаю, что это только начало. Решил рамблер сделать так, чтобы можно было искать объявления о вакансиях и автомобилях по всему интернету из рамблера, да еще и указывая параметры. Для этого необходимо научиться извлекать информацию из html-страниц. Например, из объявлений сайта auto.ru необходимо научиться извлекать объем двигателя, цену, регион, пробег, мощность двигателя, и т. д.

Некоторые сайты шаблонно у себя размещают эти объявления, поэтому для них делается специальный парсер, который просто каждому токену сопоставляет позицию в документе. Затем выбирается какое-то множество хорошо структурированных сайтов и, кажется, руками размечается, какой из шаблонов чему соответствует. Для каждого сайта такой шаблон свой. Затем из всего сайта извлекается информация, и так накапливаются словари. Первый шаг был самый непонятный, наверное, он и самый трудоемкий. Вроде как, для остальных сайтов (не помеченных руками) такой шаг как-то автоматизирован. Выделяются группы эквивалентности, и (может с помощью словарей?) выделяют, какая из групп к чему относится. Сказали, что такой подход дает полноту 50 %.
То есть для половины сайтов, представляющих такую информацию, удается ее правильно разобрать.

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

И последний шаг использование машинного обучения.
Выделяется множество разрезов в тексте, то есть концы слов.
Для каждого разреза в тексте мы можем, учитывая большее количество факторов определить, к какому классу относится предыдущий токен. Насколько я понял, учитывается какой путь в html -дереве мы проходим к этому токену, и что у него за соседи. Используют Байеса и SVM. Байес чуть хуже, но быстрее. После этого шага получают полноту 90 %, и на этом успокаиваются. Рассказал я все примерно, так как доклад, на мой взгляд, был не очень внятным, и я некоторые тонкие места не могу до конца понять.

Вопросов было много, но интересных не очень.
Главное, что они не показывают контактную информацию, и пользователь идет на станицу-первоисточник.
То есть и сами сайты должны быть заинтересованы в качестве этого поиска.
Некоторые даже отдают XML.
Пока это выглядит очень перспективно, но они долго (вроде больше полугода) не могут никак выкатить эту бету.
Будем ждать, а пока это можно попробовать на beta.rambler.ru.

{{ActualBanner}}
[[Категория:РИТ: Высокие нагрузки-2008]]
{{replicate-from-custiswiki-to-lib}}

РИТ:Высокие нагрузки 2008 (Отчет Алексеева Алексея) - История изменений

BenderBot: 1 версия

StasFomin: /* «Универсальный поиск вертикального поиска». Протасов Сергей, Плошихин Виктор (Рамблер) */

← Предыдущая	Версия 00:02, 19 августа 2010
(нет различий)