<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Insight IT</title><link>https://www.insight-it.ru/</link><description></description><atom:link href="https://www.insight-it.ru/tag/netty/feed/index.xml" rel="self"></atom:link><lastBuildDate>Fri, 15 Apr 2011 23:03:00 +0400</lastBuildDate><item><title>Кардинальный переворот в архитектуре поиска Twitter</title><link>https://www.insight-it.ru//highload/2011/kardinalnyjj-perevorot-v-arkhitekture-poiska-twitter/</link><description>&lt;p&gt;Не успел я опубликовать &lt;a href="https://www.insight-it.ru/highload/2011/arkhitektura-twitter-dva-goda-spustya/"&gt;обновление об архитектуре Twitter&lt;/a&gt;, как
они снова перекроили половину проекта =) На этот раз к паре
&lt;a href="/tag/ruby/"&gt;Ruby&lt;/a&gt;+&lt;a href="/tag/scala/"&gt;Scala&lt;/a&gt; активно вплелись технологии из
мира &lt;a href="/tag/java/"&gt;Java&lt;/a&gt;. Наибольшим изменениям подверглась подсистема
поиска твитов , о которой сегодня и пойдет речь.
&lt;!--more--&gt;&lt;/p&gt;
&lt;h2 id="novaia-arkhitektura-poiska-tvitov"&gt;Новая архитектура поиска твитов&lt;/h2&gt;
&lt;h3 id="backend"&gt;Backend&lt;/h3&gt;
&lt;p&gt;Поиск осуществляется теперь не с помощью&amp;nbsp;&lt;a href="/tag/mysql/"&gt;MySQL&lt;/a&gt;-кластера, а посредством версии &lt;a href="/tag/lucene/"&gt;Lucene&lt;/a&gt;, адаптированной для работы в реальном времени. Разработка этой подсистемы началась весной прошлого года, но полноценно использоваться она начала лишь недавно.&lt;/p&gt;
&lt;p&gt;Так как поиск в Twitter является одной из самых часто используемых поисковых систем в мире (более миллиарда поисковых запросов в день), то требования к новой
системе поиска были сопоставимо строгими:
-   Обработка более 12000 запросов в секунду
-   Индексация потока в 1000 новых твитов в секунду
-   Задержка между написанием твита и его появлением в индексе должна
    быть менее 10 секунд&lt;/p&gt;
&lt;p&gt;Lucene была взята за основу, так как на сегодняшний день это одно из
лучших решений для реализации поиска в мире opensource. Но в текущей ее
реализации она не была приспособлена к поиску в реальном времени.
Команде Twitter пришлось переписать существенную часть основных структур
в памяти, особенно списки записей. При этом внешний API Lucene остался
неизменным, что позволило использовать поисковые алгоритмы в практически
неизменном виде. Среди основных изменений в Lucene можно выделить:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;значительно улучшена производительность сбора мусора;&lt;/li&gt;
&lt;li&gt;структуры и алгоритмы более не используют блокировки;&lt;/li&gt;
&lt;li&gt;списки записей с поддержкой обхода в обратном направлении;&lt;/li&gt;
&lt;li&gt;эффективное раннее прекращение обработки запроса.&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;Все вышеперечисленные изменения находятся в процессе публикации обратно
в Lucene, какие-то прямо в основную ветку, какие-то в отдельную для
поиска в реальном времени.&lt;/p&gt;
&lt;p&gt;После внедрения этой системы поиск стал потреблять лишь 5% доступных ему
ресурсов, что оставило приличный запас для роста даже по меркам
невероятно быстро развивающегося Twitter. Новая подсистема индексации
способна обрабатывать в 50 раз больше твитов в секунду, чем они получали
на момент запуска, что также является очень позитивным показателем.
Помимо улучшения производительности, Lucene повысила и качество поиска,
а также открыла простор для новых улучшений в этом направлении.&lt;/p&gt;
&lt;h3 id="frontend"&gt;Frontend&lt;/h3&gt;
&lt;p&gt;Кардинальный переворот в этой части системы можно описать одной
фразой:&amp;nbsp;&lt;a href="/tag/ror/"&gt;Ruby on Rails&lt;/a&gt; заменен на Java-сервер, который они
назвали&amp;nbsp;&lt;a href="/tag/blender/"&gt;Blender&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;За неделю до развертывания Blender, количество поисков по твитам
существенно возросло из-за &lt;code&gt;#tsunami&lt;/code&gt; в Японии. Среднее время поиска
достигало 800-900мс.&lt;/p&gt;
&lt;p&gt;&lt;img alt="Blender и #tsunami" class="left" src="https://www.insight-it.ru/images/blender-tsunami.jpg" title="Blender и #tsunami"/&gt;&lt;/p&gt;
&lt;p&gt;После введения Blender в эксплуатацию среднее время отклика 95% запросов
упало втрое: до 250мс, при этом уровень использования вычислительных
ресурсов на frontend серверах упал вдвое. Тот же поток запросов стало
возможным обрабатывать меньшим количеством серверов.&lt;/p&gt;
&lt;p&gt;Чтобы понять, откуда взялся такой прирост производительности, необходимо
показать в чем были слабые стороны старого поиска на Ruby on Rails. На
каждом frontend сервере было запущено фиксированное количество
однопоточных Rails процессов, каждый из которых занимался следующим:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;обработкой поисковых запросов&lt;/li&gt;
&lt;li&gt;синхронным обращением к серверам с индексами&lt;/li&gt;
&lt;li&gt;агрегацией и составлением результатов&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;Они давно понимали, что синхронные запросы ведут к неэффективному
использованию вычислительных ресурсов. Со временем накопилось много
технически неудачных моментов, что делало все сложнее введение нового
функционала и поддержание надежности системы. Blender позволил
преодолеть эти функции следующим образом:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;strong&gt;Создание полностью асинхронного сервиса агрегации.&lt;/strong&gt; Ни один поток
    не ждет пока осуществятся сетевые операции.&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;Агрегация результатов с различных сервисов:&lt;/strong&gt; индексы поиска в
    реальном времени, топа твитов и гео-информации, а также базы данных
    пользователей и твитов.&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;Элегантная работа с зависимостями сервисов.&lt;/strong&gt; Алгоритм обработки
    запросов автоматически обрабатывает зависимости между используемыми
    сервисами.&lt;/li&gt;
&lt;/ul&gt;
&lt;h3 id="chto-zhe-sobstvenno-predstavliaet-soboi-blender"&gt;Что же, собственно, представляет собой Blender?&lt;/h3&gt;
&lt;p&gt;Это HTTP и &lt;a href="/tag/thrift/"&gt;Thrift&lt;/a&gt; сервер, разработанный на основе
&lt;a href="/tag/netty/"&gt;Netty&lt;/a&gt;, масштабируемой неблокирующей клиент-серверной
библиотеки на Java, позволяющей легко и быстро разрабатывать клиенты и
серверы для различных протоколов. Выбор пал именно на неё, а не на
аналоги (например Jetty или Mina) из-за более чистого API, детальной
документации и, что более важно, так как некоторые другие сервисы в
Twitter уже используют её. Интеграции с Thrift у нее не было, но этот
вопрос решился написанием простого кодека, обрабатывающего сообщения на
низком уровне.&lt;/p&gt;
&lt;p&gt;Обработка поисковых запросов представляет собой цепочку запросов к
внутренним сервисами, обработку ответов и генерацию результата.
Внутренние сервисы имеют зависимости, которые можно представить в виде
ацикличного направленного графа. После топологической сортировки графа
Blender получает последовательность выполнения запросов, которые
назначаются к выполнению в поток Netty, что в совокупности с
обработчиками событий и образует workflow обработки поисковых запросов.&lt;/p&gt;
&lt;h2 id="zakliuchenie_1"&gt;Заключение&lt;/h2&gt;
&lt;p&gt;&lt;img alt="Blender - схема работы" class="right" src="https://www.insight-it.ru/images/blender-workflow.jpg" title="Blender - схема работы"/&gt;
Эта диаграмма демонстрирует текущую архитектуру поиска с использованием
Blender и Lucene: все входящие поисковые запросы проходят через
аппаратный балансировщик нагрузки и попадают в Blender, где они
анализируются и перераспределяются между внутренними сервисами с
использованием workflow для обработки зависимостей и генерации
результатов.&lt;/p&gt;
&lt;p&gt;На моей памяти эти нововведения в Twitter - практически единственный
случай, когда крупный успешный проект настолько кардинально поменял
основную часть стека используемых технологий. Да, они получили
существенный выигрыш в производительности не в ущерб масштабируемости,
но не поменяли же они большую часть команды разработчиков с
Ruby-программистов на Java-программистов... Понятно, что это лишь
инструменты, но довольно приличная часть людей, особенно те, кто в
возрасте, не способны резко переключиться с привычных технологий на
что-то совершенно новое. Хотя, скорее всего, в команде Twitter особо не
было разработчиков "за 40", так что для них это не было особой
проблемой.&lt;/p&gt;
&lt;h2 id="istochnik-informatsii"&gt;Источник информации&lt;/h2&gt;
&lt;ul&gt;
&lt;li&gt;&lt;a href="https://www.insight-it.ru/goto/ecede8b6/" rel="nofollow" target="_blank" title="https://blog.twitter.com/2011/twitter-search-now-3x-faster"&gt;Twitter Search 3x Faster&lt;/a&gt; (cпасибо Сергею Гуляеву за предоставленную ссылку)&lt;/li&gt;
&lt;li&gt;&lt;a href="https://www.insight-it.ru/goto/ddafc7f8/" rel="nofollow" target="_blank" title="https://blog.twitter.com/2010/twitters-new-search-architecture"&gt;Twitter's New Search Architecture&lt;/a&gt;&lt;/li&gt;
&lt;/ul&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Иван Блинков</dc:creator><pubDate>Fri, 15 Apr 2011 23:03:00 +0400</pubDate><guid>tag:www.insight-it.ru,2011-04-15:highload/2011/kardinalnyjj-perevorot-v-arkhitekture-poiska-twitter/</guid><category>Blender</category><category>Lucene</category><category>netty</category><category>Twitter</category></item></channel></rss>