Tarantool *

Мы в Почте Mail.Ru постоянно сталкиваемся с необходимостью работать с историей пользователей. Учитывая, что ежемесячная аудитория проекта составляет более 40 миллионов человек, история всех их действий – это порядка петабайта данных. Потребность в поиске по логам у нас возникает сотни раз в день, а на получение нужной информации в среднем уходило несколько часов. При этом, по нашим предположениям, извлечение информации из логов можно было ускорить до нескольких секунд.

Чтобы оценить целесообразность разработки системы для оптимизации поиска по логам, мы воспользовались вот этой таблицей с XKCD:



(на самом деле нет, но нам она все равно нравится).

Итак, мы всерьез взялись за оптимизацию. Итогом нашей работы стала разработка системы, благодаря которой мы можем поднять историю действий примерно в 100 000 (сто тысяч, это не опечатка) раз быстрее. Мы разработали big-data сервис, который позволяет хранить петабайты информации в структурированном виде: каждому ключу у нас соответствует лог каких-то событий. Хранилище устроено так, что оно способно работать и на самых дешевых SATA-дисках, и на больших многодисковых хранилищах с минимальным количеством процессорного времени, при этом оно полностью fault-толерантно — если вдруг какая-то машина выйдет из строя, это ни на что не влияет. Если в системе заканчивается место, в нее просто добавляется сервер или несколько: система автоматически увидит их и начнет записывать данные. Чтение данных происходит почти моментально.

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



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

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

В начале декабря в Санкт-Петербурге при партнерстве Mail.Ru Group прошел полуфинал чемпионата мира по программированию ACM ICPC. В рамках чемпионата я встречался с участниками и рассказывал о том, как сделать веб-сервис системой реального времени; а сейчас хочу поделиться своим докладом на Хабре.

Говоря о системе реального времени, мы представляем атомную станцию, самолет или нечто подобное, где от скорости реакции информационной системы зависит жизнь людей. Если в системе реального времени команда будет тормозить 10 секунд из-за сборки мусора, последствия могут быть более чем плачевными. Реакция должна быть моментальной, причем за гарантированное время.

При работе веб-сервиса, конечно, жизнь человека не зависит от того, насколько быстро он открыл письмо в почте, но требования к веб-сервису почти такие же. Еще 15 лет назад, когда пользователь кликал на ссылку, он ожидал реакции 10 секунд; для медленного интернета того времени это было нормально. Современный интернет – это широкие каналы, быстрые компьютеры. У пользователей все работает быстро, и они ждут от сервисов того же.

Когда пользователь куда-то кликает, он ожидает моментально получить реакцию на свой клик. Что такое моментально? Для человека комфортной задержкой считается время отклика порядка 200 миллисекунд, хотя на самом деле человеческий глаз различает время около 10 миллисекунд. Веб-сервис должен реагировать на действия пользователя не более чем за 200 миллисекунд — чем меньше, тем лучше.

Итак, современный веб-сервис, по сути, должен быть системой реального времени. Как сделать так, чтобы он отвечал этому требованию, я расскажу на примере Почты Mail.Ru.

Доклад «Tarantool: как обрабатывать 
1,5 млрд запросов в сутки?» — очередной в серии расшифровок с Форума Технологий Mail.Ru 2011. Подробности о том, как работает система расшифровки докладов — см. в статье «Изнанка» Форума технологий Mail.Ru: Хай-тек в event-management. Там же, а также на сайте Форума (http://techforum.mail.ru) — ссылки на расшифровки других докладов.

(Скачать видеоверсию для мобильных устройств — iOS/Android H.264 480×368, размер 170 Mb, видеобитрейт 500 кбит/с, аудио — 64 кбит/с )

(Скачать видеоверсию большего разрешения H.264 624×480, размер 610 Mb, видеобитрейт 1500 кбит/с, аудио — 128 кбит)

(Скачать слайды презентации, 520К)

Представлять данного докладчика тяжело, потому что его все знают. Каждый из вас, я уверен, пользуется продуктами, к которым Костя приложил руку. Это, в первую очередь, MySQL. Костя на протяжении многих лет занимался разработкой этой популярной базы данных, которую используют если не 100%, то 90% российских сайтов точно. Сегодня Костя работает в компании Mail.Ru Group. Костя нам сегодня расскажет о том, что мы сделали, как это работает и главное — какую производительность это позволит получить на ваших сервисах.

Добрый день. Вас сегодня очень много. Cпасибо, что пришли! Меня уже представили, поэтому я бы только хотел добавить, что я в душе и по делу все-таки инженер. Я, скорее, не руковожу, а активно участвую в разработке Tarantool, поэтому, если вам это интересно, у вас сегодня есть возможность узнать про него абсолютно всё. Так или иначе, этот доклад, помимо философствования на тему будущего СУБД, о Tarantool.