Tarantool *

На фото представлены устройства, использованные для прототипирования. Как видно, за основу взята процессор x86 (Intel Edison)

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

Привет, Хабр! Хочу рассказать историю миграции с Tarantool версии 1.5 на 1.6 в одном из наших проектов. Как вы думаете, нужно ли заниматься миграцией на новую версию, если и так все работает? Насколько легко это сделать, если у вас уже написано достаточно много кода? Как не затронуть живых пользователей? С какими трудностями можно столкнуться при таких изменениях? Какой вообще профит от переезда? Ответы на все вопросы можно найти в этой статье.

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

Итак, у нас есть СУБД, хранящая все данные в оперативной памяти. Как я уже упоминал в моей предыдущей статье, для снятия снимка состояния необходимо все эти данные записать на диск. Это означает, что нам нужно пройтись по всем таблицам и по всем строкам в каждой таблице и записать все это на диск одним файлом через системный вызов write. Довольно просто на первый взгляд. Однако проблема в том, что данные в базе постоянно изменяются. Даже если замораживать структуры данных при снятии снимка, в итоге на диске можно получить неконсистентное состояние базы данных.

Видео доклада

Текстовая Версия

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


Индексы и тела писем составляют 15 % объёма, файлы — 85 %. Место для оптимизаций надо искать в файлах (аттачах в письмах). На тот момент у нас не была реализована дедупликация файлов; по нашим оценкам, она может дать экономию в 36 % всего объёма почты: многим пользователям приходят одинаковые письма (рассылки социальных сетей с картинками, магазинов с прайсами и т.д.). В этом посте я расскажу про реализацию такой системы, сделанной под руководством PSIAlt.

Привет, Хабр! В этой статье я хочу рассказать о системе антиспама в Почте Mail.Ru и опыте работы с Tarantool в рамках этого проекта: в каких задачах мы используем эту СУБД, с какими трудностями и особенностями ее интеграции столкнулись, на какие грабли наступали, как набивали шишки и в итоге познали дзен.

В последний четверг этого лета приглашаем гостей в московский офис Mail.Ru Group на третий Tarantool meetup. Наша компания разрабатывает Tarantool — opensource NoSQL In-Memory СУБД, которая ориентирована на максимально возможную производительность. Об этой базе данных вы неоднократно могли читать в нашем блоге. Мы поговорим об основных отличиях и преимуществах Tarantool, поделимся опытом использования и планами на будущее. Событие будет интересно разработчикам, системным администраторам Unix и другим IT-специалистам, работающим с базами данных. В программе встречи три доклада, подробности и программу встречи читайте под катом.

Tarantool — NoSQL СУБД, которая разрабатывается и широко используется в Mail.Ru Group. Об объемах использования можно сделать вывод по публикациям:

• Под высокой нагрузкой: наши способы применения Tarantool
• Asyncio Tarantool Queue, вставай в очередь

Недавно Mail.Ru Group выпустила виртуальную машину с предустановленным Tarantool для Microsoft Azure:

• Tarantool on Microsoft Azure Marketplace
• Открытая БД Tarantool от Mail.Ru сертифицирована и размещена в Azure Marketplace

Мы решили проверить, насколько хорошо Tarantool работает в Microsoft Azure в сравнении с другими подобными предложениями — Azure Redis Cache, Bitnami Memcached, Aerospike и VoltDB. Под словом «хорошо» будем понимать «быстро», то есть сравнивать будем число обрабатываемых запросов в секунду (Throughput, RPS).

Многие из вас уже слышали о нашем проекте Tarantool. Это СУБД, или, попросту говоря, база данных с сервером приложений внутри. Tarantool — проект с открытым исходным кодом, и с ним может работать кто угодно. Развивается этот проект уже больше восьми лет. В Mail.Ru Group Tarantool активно используется более чем в половине продуктов: в Почте, Облаке, Моём Мире, Агенте и др. Все сделанные нами доработки этой БД мы коммитим обратно на GitHub, и сообществу доступна та же самая версия БД, что и нам. Сейчас у нас есть клиентские библиотеки почти ко всем языкам, мы сильно прибавили в этом направлении за последний год. Часть из них написана сообществом, часть — нами. Если появляется какая-то более эффективная библиотека, то мы просто делаем её официальной. Мы стараемся, чтобы всё было прямо из коробки — и БД, и библиотеки.

Одна из главных особенностей Tarantool заключается в объединении свойств БД и кэша. БД — это нечто надёжное, с транзакциями, серверным языком запросов. А кэш быстрый. И оба этих мира органично сливаются воедино в Tarantool. Эта БД предназначена для использования в высоконагруженных проектах и для работы с горячими данными.

28 января в офисе Mail.Ru Group состоялся Tarantool Meetup, на котором были рассмотрены преимущества и особенности Tarantool, а также рассказано об опыте использования этой СУБД и планах её развития. Под катом вы сможете найти видеозаписи и презентации с этих выступлений.

28 января 2016 года в московском офисе Mail.Ru Group пройдёт вторая встреча Tarantool meetup. Если кто-то ещё не знает: Tarantool — это NoSQL In-Memory СУБД с открытым исходным кодом, создающаяся для обеспечения максимально возможной производительности. На втором митапе мы рассмотрим главные преимущества и особенности Tarantool, расскажем о своём опыте использования этого продукта и планах на будущее. В первую очередь эта встреча будет интересна разработчикам, Unix-сисадминам и прочим специалистам, так или иначе работающим с базами данных. Программу встречи смотрите под катом.

Для чего используются базы данных, ведь есть старые добрые файлы? Чем они хуже базы данных или чем база данных лучше файлов? БД — более структурированное хранилище. Она позволяет делать транзакции, запросы и так далее. Самый простой случай: есть сервер с базой данных и несколько приложений, которые делают запросы к серверу. База данных отвечает, меняет что-то внутри себя, и всё хорошо ровно до того момента, пока нагрузка на неё не вырастает настолько, что база данных перестаёт справляться.

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

Если база не держит нагрузку на запись, то шарды можно добавлять до бесконечности. Шард устроен сложнее, чем реплика, потому что нужно как-то распределить данные по таблицам или внутри таблицы, по хэшу, по range — есть множество разных вариантов. Таким образом, добавляя реплики и шарды, вы можете делить любую нагрузку на базу данных. Казалось бы, больше желать нечего, о чём дальше говорить?

Некоторое время назад в Облаке Mail.Ru появилась возможность проигрывания видеофайлов. Уже в самом начале работы над этим функционалом мы решили, что будем разрабатывать этакий швейцарский нож: требовалась возможность проигрывать любые видеоформаты и функционирование на всех устройствах, где доступно Облако. Загруженные в Облако видеофайлы можно условно разделить на две категории: «фильмы/сериалы» и «видеоролики пользователей», которые люди снимают на телефоны и видеокамеры — для этого случая особенно характерно разнообразие форматов и кодеков. Без предварительной обработки просмотреть все это на любом устройстве невозможно, например, из-за отсутствия нужного кодека или же размер файла окажется слишком большим.

В этой статье я расскажу о том, как устроено проигрывание видеофайлов в Облаке Mail.Ru и каким путем мы шли, чтобы сделать воспроизведение в Облаке «всеядным» на вход и поддержать максимальное число устройств на выходе.

Привет, %хабраюзер%. Команда Тарантула продолжает делиться инсайтами и экспертизой для эффективной работы с данными в высоконагруженных проектах. Сегодня мы попытаемся разобраться, почему же Tarantool — это «два в одном»: не только база данных, но и сервер приложений. Наверное, некоторые слышали о Тарантуле как о сверхбыстром персистентном in-memory хранилище с поддержкой репликации и хранимок на Lua. Представьте, что мы берём кусочки Redis, добавляем замороженный Node.js, сверху заправляем Go, после чего варим, медленно перемешивая, в течение пяти минут после закипания. Казалось бы, при чём здесь Application Server?

Вам знакома такая архитектура? Хоровод демонов, пляшущих между web-server, cache и storage.



Какие минусы такой архитектуры можно отметить? Решая задачи в рамках такой архитектуры, мы сталкиваемся с кучей вопросов: какой язык(и?) взять, какой I/O framework выбрать, как синхронизировать cache и storage? Куча инфраструктурных вопросов. А зачем решать инфраструктурные вопросы, когда надо решить задачу? Безусловно, можно сказать, что нам нравятся некие технологии X и Y, и перевести эти минусы в рамки идеологических. Но нельзя отрицать тот факт, что данные располагаются на неком расстоянии от кода (картинка выше), что добавляет latency, что может уменьшить RPS.

Цель данной статьи — рассказать об альтернативе, которая построена на базе Nginx как web-server, bаlancer и Tarantool как App Server, Cache, Storage.

В одной из своих статей я рассказывал об асинхронной работе с Tarantool на Python. В данной статье продолжу эту тему, но внимание хочу уделить обработке информации через очереди на Tarantool. Мои коллеги опубликовали несколько статей о пользе очередей (Инфраструктура обработки очередей в социальной сети Мой Мир и Push-уведомления в REST API на примере системы Таргет Mail.Ru). Хочу дополнить информацию об очередях на примере решений наших задач, а также рассказать о работе с Tarantool Queue на Python и asyncio. Почему мы выбираем именно Tarantool, а не Redis или RabbitMQ?

На Хабре уже есть статьи о NoSQL СУБД Tarantool и о том, как его используют в Mail.Ru Group (и не только). Однако нет рецептов того, как работать с Tarantool на Python. В своей статье я хочу рассказать о том, как мы готовим Tarantool Python в своих проектах, какие проблемы и сложности при этом возникают, плюсы, минусы, подводные камни и, конечно же, «в чем фишка». Итак, обо всем по порядку.



Tarantool представляет собой Application Server для Lua. Он умеет хранить данные на диске, обеспечивает быстрый доступ к ним. Tarantool используется в задачах с большими потоками данных в единицу времени. Если говорить о цифрах, то это десятки и сотни тысяч операций в секунду. Например, в одном из моих проектов генерируется более 80 000 запросов в секунду (выборка, вставка, обновление, удаление), при этом нагрузка равномерно распределяется по 4 серверам с 12 инстансами Tarantool. Не все современные СУБД готовы работать с такими нагрузками. Кроме того, при таком количестве данных, очень дорого ожидание выполнения запроса, поэтому сами программы должны быстро переключаться от одной задачи к другой. Для эффективной и равномерной загрузки CPU сервера (всех его ядер) как раз нужен Tarantool и асинхронные приемы в программировании.

Не так давно на Хабре была опубликована статья о NoSQL базе — «Tarantool 1.6 от первого лица». Уверен, в своих кругах эта база данных отлично известна и уже завоёвывает популярность. Уверен так же и в том, что есть те начинающие, руки не дошли, кто хотел бы попробовать Tarantool в действии. Именно для таких желающих я приведу несколько простых примеров, помогающих начать знакомиться с этим интересным продуктом. Как понятно из названия статьи — речь идет о версии Tarantool 1.6.

Привет. Это пост о новой версии Тарантула «от автора». Интернет занятно устроен: если поискать про Тарантул, то найдётся статья от 2011 года, о версии 1.3. И ещё какой-то перфоратор, кажется. На форумах-бордах вообще стоит густой туман. Тарантул «ну это как Редис, только»…

Или ещё, недавно сделал для себя открытие, на Тостере кто-то написал «София — это такое append-only хранилище по типу Тарантула». С такими постами я скоро стану фанатом сайта «сделано у нас», автомата Калашникова и Саяно-Шушенской ГЭС. Правда, мне сложно понять, почему мы восхищаемся западными инструментами, при этом представления не имеем о своих. Итак, Tarantool 1.6. В чём фишка?

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

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



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

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

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



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