В последние несколько дней по интернету стали ходить статьи с заголовками вроде “Dropbox небезопасен”, “Обнаружена серьезная уязвимость в Dropbox” и т.п. Я, как пользователь дропбокса, решил разобраться, в чем же тут дело. Русскоязычные источники информации, как это обычно бывает, пестрят громкими заявлениями в духе “Все пропало!!!!!!!!”, а ссылку на первоисточник указывать считают дурным тоном. Под катом я расскажу, как дело обстоит на самом деле.

Phaser (Этапщик) — мощная и гибкая реализация паттерна синхронизации Барьер. Включен в JDK 7 в составе пакета java.util.concurrent.

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

Задача Яндекса – найти ответ на вопрос пользователя. Но технологии поиска этого самого ответа бывают разными. Скажем, поиск по интернету и по письмам очень сильно различаются. Поиск по почте – это особенный продукт, уникальный и сложный.

В первую очередь, Яндекс.Почта – это огромный объём данных. У нас хранится около 10 миллиардов писем – это почти столько же, сколько страниц в индексе веб-поиска Яндекса. При этом поисковых запросов примерно в 1000 раз меньше, чем запросов к поиску по интернету.

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

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

Архитектурные особенности

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

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

Когда система работает в штатном режиме (все серверы функционируют, все дата-центры доступны), половина поисков отправляется на сервер в одном ДЦ, а вторая половина – на сервер в другом ДЦ. Благодаря этому поисковая производительность увеличивается в два раза.

Технологические особенности

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

Другой вариант – все пользователи в одном индексе. Однако этот вариант ненадёжен: если произойдёт сбой, то сразу миллионы пользователей останутся без поиска, а восстановление системы займёт значительное время.

1-й вариант решения: Индекс размером до 10 Гб
Мы попробовали промежуточный вариант: выбрали максимальный размер каждого индекса 10 Гб. Следовательно, на каждом сервере получилось по 50-100 индексов, которые создаются в порядке поступления писем, а данные пользователя, таким образом, могут находиться в любом из индексов. Но письма часто содержат большое количество однотипной информации («привет», «пока», «@yandex.ru»), которая подходит под 46% всех запросов к поиску по Почте. Получалось, что ответ на такой запрос требовал поднять около 20% всех писем, хранящихся на сервере — это занимало десятки секунд.

2-й вариант решения: Префиксный индекс
Мы оставили максимальный размер индекса равным 10Гб, но перед каждым словом добавили ID пользователя. В результате каждый поиск сразу ограничивался количеством и размером писем в почтовом ящике текущего пользователя. Это снизило объем находимых данных и на порядок ускорило поиск. Но когда на диске – сотни индексов, то из-за большого числа дисковых операций поиск занимает несколько секунд. Наша же цель – десятые доли секунд.

3-й вариант решения: Шардирование по пользователям
Все индексы на сервере были разделены на 1000 сегментов (шардов). В каждом из них – от пяти до двадцати индексов размером до 1 Гб, и данные конкретного пользователя всегда находятся в определённом сегменте. В результате число дисковых операций было снижено до 20 раз по сравнению со вторым вариантом. Скорость поиска также увеличилась в разы. Так мы получили поиск за доли секунд.

Онлайн-индексация
Для того чтобы все поступающие письма практически сразу появлялись в результатах поиска, мы разработали специальный инкрементальный индекс в памяти. Особенность индекса в том, что в него можно добавлять по одному документу, а после добавления документ сразу появляется в поиске.
Процесс индексации выглядит так:
Поступающие письма попадают в инкрементальный индекс в памяти. Когда в памяти накапливается определенное количество писем или занят определенный объем,  запускается процесс переноса данных из индекса в памяти в дисковый индекс.  В этот же момент прекращается индексация в памяти №1 и создается индекс в памяти №2.

Конечно, это – лишь часть того, что мы делаем для улучшения качества нашего поиска по Яндекс.Почте. Может быть, у вас есть какие-то вопросы? Мы с радостью на них ответим.

Вступление:

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

Цель моего анализа — сравнить двух основных игроков в мире облачных вычислений, Google App Engine (GAE) и Amazon Web Services (AWS). Оба неслабо разогнались за последние годы, но кто из них больше мне подойдёт? Давайте разбираться.

Знакомо ли вам такое состояние, когда вы настолько увлечены идеей, что полностью погружаетесь в процесс ее реализации, забывая о времени и окружающем мире? А завершив, испытываете радость и даже счастье? Значит, у вас есть опыт потоковых состояний – особых ресурсных состояний сознания, когда все внимание сфокусировано на цели, и в результате замечательные идеи рождаются сами собой, и время концентрируется, вмещая гораздо больше, чем в обычном состоянии.
Тема эффективности потоковых состояний для работы и творчества уже несколько раз поднималась на Хабре, и в этой статье мы хотим обсудить практическую часть – что необходимо для того, чтобы вызывать это состояние «на заказ»?

StartupPoint начинает серию Поинтов с участием крупных стратегических инвесторов: 24-ый Поинт в Москве (8 апреля) и Поинт на РИФ+КИБ 2011 (20-22 апреля).

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

На 24-ом Поинте (08.04 в Digital October) будут присутствовать представители крупных интернет-компаний: Алексей Черняк, Groupon; Григорий Бакунов, Яндекс; Сергей Мартынов, Mail.ru; Сергей Зарипов, СКБ Контур.

[Предыдущий пост]

Введение

Вот и ожидаемое, или не очень, продолжение. Сегодня мы проглотим синюю пилюлю, гордо олицетворяющую FP (functional programming), и погрузимся в функциональную часть F# еще глубже. Поговорим о функциях, рекурсии, pattern matching'е и еще о нескольких интересных вещах. Интересно? Тогда глотаем таблетку и начинаем погружение.

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

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

Увидела свет новая версия UMPlayer 1.0

UMPlayer — это кроссплатформенный мультимедия проигрыватель. В данный момент есть версии для Linux, Windows и Mac Os.
UMPlayer по сути это форк SMplayer, и так же как и родитель тоже является фронтендом для Mplayer.
Немного интересного под катом.

Только что вернулся с конференции ПАВТ 2011 и хотел бы познакомить уважаемое хабрасообщество с современным состоянием дел в области высокопроизводительных вычислений.
Постараюсь по возможности ссылаться на первоисточники — а именно, на статьи из журнала "Суперкомпьютеры" и материалы конференции.

Зачем это все нужно

Суперкомпьютеры традиционно использовались в военных и научных целях, но в последние годы в их применении произошли революционные изменения, связанные с тем, что их мощность «доросла» до моделирования реальных процессов и предметов при доступной для бизнеса стоимости.
Все, наверное, знают, что в автомобилестроении расчеты на суперкомпьютерах используются для повышения безопасности, например так получил свои 5 звезд Ford Focus. В авиапромышленности выпуск нового реактивного двигателя по традиционной технологии — дорогостоящее удовольствие, например создание АЛ-31 для СУ-27 заняло 15 лет, потребовало создать и разрушить 50 опытных экземпляров и стоило 3,5 млрд. долларов. Двигатель для Сухой Супержет, спроектированный уже с участием суперкомпьютеров, сделали за 6 лет, 600 млн евро и было построено 8 опытных экземпляров.
Нельзя не отметить и фармацевтику — большая часть современных лекарств проектируется с помощью виртуального скрининга , который позволяет радикально снизить затраты и повысить безопасность лекарств.
Дальше — больше.
Сегодня в развитых европейских странах:
47,3% высокотехнологической продукции производится с использованием имитационного моделирования фрагментов проектируемых сложных систем или изделий;
32,3% продукции производится с использованием имитационного моделирования мелкомасштабных аналогов проектируемых систем и изделий;
15% продукции производится с использованием полномасштабного имитационного моделирования проектируемых систем и изделий;
и лишь 5,4% проектируемых сложных систем и изделий производится без имитационного моделирования.

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

Иногда полезно представить граф в графической форме, так чтобы была видна структура. Можно привести десятки примеров, где это может пригодиться: визуализация иерархии классов и пакетов исходного кода какой-нибудь программы, визуализация социального графа (тот же Twitter или Facebook) или графа цитирования (какие публикации на кого ссылаются) и т.д. Но вот незадача: количество ребер в графе зачастую настолько велико, что нарисованный граф просто невозможно разобрать. Взгляните на эту картинку:



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