Tarantool *

В современном мире информационных технологий у всех — и у крупных, и у небольших компаний — существует большое количество различных API. И отказоустойчивость, несмотря на многие best practices, чаще всего не позволяет гарантировать 100%-й возможности корректно обрабатывать запросы клиентов, а также восстанавливаться после сбоя и продолжать обработку запросов, утерянных из-за сбоя. Эта проблема возникает даже у больших игроков в интернете, не говоря уже о не очень крупных компаниях.

Я работаю в компании Calltouch, и наша основная цель — добиться отказоустойчивости сервисов и получить возможность управлять данными и запросами, которые клиенты совершали в API-сервис. Нам нужна возможность быстро восстанавливать сервис после сбоя и обрабатывать запросы к сервису, у которого возникли проблемы. Начинать обработку с момента отказа. Всё это позволит приблизиться к состоянию, когда почти невозможно потерять запросы клиентов на нашей стороне.

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

Привет, Хабр! Сегодня хочу поделиться с вами текстовой версией доклада, представленного на Tarantool Meetup второго марта 2017-го года в Mail.Ru Group с поправкой на то, что прошёл уже месяц, и кое-что из обещанного уже было реализовано, поэтому текст будет интересен даже тем, кто видел выступление. Я работаю в компании eVote, которая разрабатывает сервис онлайн-опросов. Мы активно применяем Windows и .NET-технологии в наших продуктах, и в этом посте я расскажу про то, как мы добавили к стеку наших технологий СУБД Tarantool.

Большое спасибо коллегам, друзьям и сотрудникам компании Mail.Ru Group, которые помогали написать эту статью.

Многие уже наслышаны о производительности СУБД Tarantool, её возможностях и особенностях. Например, у него есть классное дисковое хранилище — Vinyl, кроме того, он умеет работать с JSON-документами. Но в многочисленных публикациях обходят стороной одну важную особенность. Обычно БД рассматривают просто как хранилище, но всё же отличительная черта Tarantool — это возможность писать код внутри и очень эффективно работать с этими данными. Под катом рассказ, как мы строили одну систему почти полностью внутри Tarantool, написанный в соавторстве с Игорем igorcoding Латкиным.

Привет, Хабр! Сегодня поделюсь с вами статьёй, написанной по мотивам моего доклада на Tarantool Meetup. Маленькая история, почему в компании Мамба стали использовать Tarantool. Почему мы занялись репликацией из MySQL в Tarantool? Первая причина в том, что в какой-то момент нужно было начинать переходить на MySQL 5.7, но в нём отсутствует handler socket, который активно используется на наших серверах в MySQL 5.6. Мы даже связались с командой Percona, и они подтвердили, что 5.6 — это последняя версия c handler socket.

Вторая причина — мы начали пробное использование Tarantool, и скорость работы нам понравилась: мы просто сравнили memcache и Tarantool как key/value-хранилище, получив прирост производительности — с 0,6 до 0,3 мс на одинаковом железе. В относительном выражении Tarantool в два раза быстрее, в абсолютном выражении это не так круто, но всё же. И третья причина — желание полностью сохранить текущую структуру: есть MySQL Server Master и его Slave’ы, ничего переписывать не хотелось, хотелось оставить максимально близко к той архитектуре, что есть сейчас. Как бы нам сделать так, чтобы вместо Slave’ов MySQL 5.6, на которых используется handler socket, применить что-то другое и полностью не переписывать всю огромную архитектуру?

Недавно в пресс-релизе мы рассказали о том, что запустили Tarantool IIoT — платформу для промышленного интернета вещей. Новость облетела многие электронные издания. Но что такое Tarantool IIoT и как он работает — тема оставалась не до конца раскрытой. Мы решили это исправить. Подробности под катом.

В последнее время на Хабре появляется достаточно много статей про Tarantool — базу данных и сервер приложений, который используется в Mail.Ru Group, Avito, Yota на разных высоконагруженных проектах. И вот, когда в маленьком стартапе, который я иногда консультирую, возникла необходимость разделения прекрасного, но, к сожалению, монолитного приложения на микросервисы, я подумал: а чем мы хуже других компаний? — и решил посмотреть в сторону Tarantool. Однако, в отличие от большинства компаний, где используется Tarantool, в нашем случае разработка проекта ведётся в Visual Studio на Windows. Предполагается, что даже с переходом на микросервисную архитектуру большинство микросервисов будет написано на языке C#. А Tarantool… Стоит зайти на официальный сайт — и сразу понимаешь: Tarantool даже установить на Windows проблематично, так как на эту операционную систему он не портирован. Как я боролся с такими сложностями, для какого именно микросервиса выбрал Tarantool и как вы можете использовать Tarantool в своих .NET-проектах, я расскажу в данной статье. А пока спойлер — практически все трудности преодолимы, и мой опыт можно без сомнений назвать положительным. Например, на то, чтобы скачать и запустить Tarantool, а потом сделать к нему запрос из кода на языке C#, у меня ушло менее десяти минут. И я покажу вам, как это сделать!

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

В первый четверг марта в нашем московском офисе состоится Tarantool Meetup 2017. Пользователи 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?