Не так давно я опубликовал пост, в комментариях к которому было высказано мнение, что у астериска есть некоторые проблемы с механизмом realtime. Так вот, на данный момент, вынужден согласиться с этим утверждением, более чем полностью. Как следствие, встал на путь разочарования asterisk'ом как платформой-"конструктором". Почему и как это произошло и при чём тут tarantool, а самое главное, что со всем этим можно сделать? Давайте разбираться под катом.

Tarantool *
Tarantool — middleware for data
Разработка системы аутентификации на Java+Tarantool

Меня зовут Александр, я программист в отделе архитектуры и пресейла в Mail.ru Group. Я расскажу, как построить систему аутентификации на основе Tarantool и Java. Нам в пресейле очень часто приходится делать именно такие системы. Способов аутентификации очень много: по паролю, биометрическим данным, SMS и т.п. Для наглядности я покажу, как сделать аутентификацию по паролю.
Статья будет полезна тем, кто хочет разобраться в устройстве систем аутентификации. На доступном примере я покажу все основные части архитектуры, как они связаны между собой и как работают в целом.
Как я сократил код для нагрузочного тестирования в три раза

Главная концепция нагрузочного тестирования — автоматизировать все, что можно. Берёте инструмент, пишете конфиг и сценарий, запускаете имитацию реальной нагрузки. Чем меньше кода, тем лучше.
Автоматизировать нагрузочное тестирование не так сложно, как может показаться на первый взгляд. Для этого нужен правильный инструмент.
Я расскажу, почему мне не подошел Яндекс.Танк в связке с Pandora и как я в три раза сжал код своей утилиты тестирования без потери производительности.
Архитектура in-memory СУБД: 10 лет опыта в одной статье

База данных в оперативной памяти — понятие не новое. Но оно слишком плотно ассоциируется со словами «кэш» и «не персистентный». Сегодня я расскажу, почему это не обязательно так. Решения в памяти имеют гораздо более широкое поле применения и гораздо более высокий уровень надежности, чем кажется на первый взгляд.
В статье я рассуждаю об архитектурных принципах решений в оперативной памяти. Как можно взять лучшее от in-memory мира — производительность невероятного уровня — и не жертвовать достоинствами дисковых реляционных систем. В первую очередь, надежность — как можно быть уверенным в сохранности данных.
Этот рассказ сжимает 10 лет опыта работы с in-memory решениями в один текст. Порог входа максимально низкий. Чтобы получить пользу от прочтения, вам не нужно иметь столько же лет опыта, достаточно базового понимания IT.
Tarantool и кодогенерация на Lua

Довольно часто на практике попадается класс задач, когда требуется обойти какую-то структуру или преобразовать формат данных из одного в другой. И в самом общем случае выполнение таких действий приводит к большому числу проверок и аллокаций памяти. Одним из примеров является парсинг JSON. При этом схема данных обычно задана, и мы ожидаем данные вполне определенного формата.
Мой рассказ будет посвящен кодогенерации — подходу, который обычно позволяет ускорить работу алгоритма и избавиться от излишних проверок и аллокаций.
Чем Tarantool круче Redis'а для IoT-сервисов

Киберпанк 2077 уже наступил. Уровень развития технологий — это почти полное воплощение в реальность мечтаний писателей-фантастов. Умные устройства, «интеллектуальная» среда обитания, автоматизация ручного труда и управление техникой сквозь время и пространство. Полное торжество кибернетики, отложенного старта и дистанционного управления.
Эти «воспоминания о будущем» можно найти как у отечественных писателей, так и у зарубежных. Братья Стругацкие, Сергей Снегов, Кир Булычёв, Рей Брэдбери, Артур Кларк, Станислав Лем предсказали нам то, что мы называем Internet of Things, интернет вещей.
Технологии мотивируют бизнесменов, инженеров, изобретателей и мечтателей придумывать новые задачи и продукты. А новые продукты требуют соответствующих технологий. Этакий замкнутый круг!
Я расскажу о том, как компания Ready For Sky применила Tarantool, чтобы воплотить «воспоминания о будущем» у вас дома.
Tarantool vs Redis: что умеют in-memory технологии

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

Привет! Я продолжаю разрабатывать распределённые системы на основе Tarantool. За последний год наша команда вывела в прод 17 новых систем. В прошлый раз я рассказал, как мы наладили автоматический деплой. В этой статье я покажу, как упростить обслуживание приложений на Tarantool Cartridge.
Деплоим Tarantool без людей

Как сделать так, чтобы любой разработчик мог быстро накидать решение своей проблемы и гарантированно доставить его в прод? Деплоить приложение просто. Сделать из него полноценный продукт, чтобы десяток команд использовал его на сотне инстансов — сложнее. А если речь про мастер-систему на несколько терабайт, то уровень тревожности повышается, руки потеют, а база трещит по швам (может быть).
Я хочу поделиться способом деплоить без простоя и без отказа в обслуживании. Пайплайн на Jenkins, ноль посредников, 500 инстансов в production-среде за 60 минут. Всё это в опенсорсе. За подробностями приглашаю под кат.
Менеджер транзакций для базы данных в оперативной памяти

В этот статье я хочу еще раз пройтись по особенностям работы транзакций в Tarantool, применительно к движку в памяти и дисковому движку. И главное — расскажу про новый менеджер транзакций, который появился в Tarantool версии 2.6, про его особенности, преимущества и устройство.
Когда меня спрашивают, что такое Tarantool, я отвечаю давно въевшееся в мозг: «Tarantool — persistent in-memory noSQL СУБД с хранимыми процедурами на Lua». Но всë не так просто. Вот in-memory — да, в основном в Tarantool используется memtx engine, движок в памяти, однако дисковый движок (vinyl) тоже давным-давно есть, и у него множество нюансов и особенностей. Или noSQL — да, в основном Tarantool используется как noSQL БД, но SQL он тоже умеет, точнее, какую-то его часть, а какую именно — это надо почитать.
Даже с хранимыми процедурами не совсем всё просто: то, что затевалось как способ сделать JOIN в noSQL БД, обросло кооперативно-многозадачной инфраструктурой для работы с сетью, файлами, HTTP, массой модулей и документации; сейчас Tarantool именуют сервером приложений с БД на борту. Да и хранимые процедуры бывают не только на Lua, но и на C.
Но это, в общем, скорее приятные оговорки, дескать, что поделать, Tarantool сложный и поэтому есть много деталей. А когда меня кто-нибудь спрашивал, есть ли в Tarantool’е транзакции и какой у них уровень изоляции, то я отвечал: «есть, serializable, но...» И далее следовали оговорки мелким шрифтом, которые портили радужную картину и время от времени вызывали негодование пользователей.
Больше никаких оговорок, пора рассмотреть новый менеджер транзакций под микроскопом.
Синхронная репликация в Tarantool

Tarantool — это платформа для in-memory вычислений, где упор всегда делался на горизонтальную масштабируемость. То есть при нехватке мощности одного инстанса нужно добавить больше инстансов, а не больше ресурсов одному инстансу.
С самого начала из средств горизонтального масштабирования в Tarantool была только встроенная асинхронная репликация, которой для большинства задач хватало. При этом у нас не было синхронной репликации, заменить которую в некоторых задачах нельзя никаким внешним модулем.
Задача реализации синхронной репликации стояла перед командой разработчиков Tarantool долгие годы, к ней было совершено несколько подходов. И вот теперь в релизе 2.6 Tarantool обзавёлся синхронной репликацией и выборами лидера на базе алгоритма Raft.
Raft в Tarantool. Как это работает и как этим пользоваться

В прошлом году в Tarantool была проведена колоссальная работа по реализации синхронной репликации. При этом мы придерживались алгоритма Raft. Вся работа была разделена на два крупных этапа: так называемую кворумную запись, то есть синхронную репликацию, и автоматические выборы лидера.
Синхронная репликация появилась в релизе 2.5.1, а в конце октября в релизе 2.6.1 появилась поддержка автоматических выборов лидера на основе Raft.
Меня зовут Сергей Петренко, и я участвовал в разработке этих больших фич. Сегодня я расскажу, как они устроены, а также коснусь конфигурирования выборов лидера и новых возможностей, которые алгоритм Raft даёт пользователям Tarantool.
Мониторинг Tarantool: логи, метрики и их обработка
Tarantool — это платформа in-memory вычислений с гибкой схемой данных. На её основе можно создать распределённое хранилище, веб-сервер, высоконагруженное приложение или, в конце концов, сервис, включающий в себя всё вышеперечисленное. Но какой бы ни была ваша промышленная задача, однажды настанет момент, когда её решение придётся мониторить. В этой статье я хочу дать обзор существующих средств для мониторинга приложения на базе Tarantool и пройтись по основным кейсам работы с ними.
Я работаю в команде, которая занимается разработкой, внедрением и поддержкой готовых решений на основе Tarantool. Для вывода наших приложений в эксплуатацию на контуре заказчика было необходимо не только разобраться в текущих возможностях мониторинга, но и доработать их. Большая часть доработок в результате вошла в те или иные стандартные пакеты. Данный материал является текстовой выжимкой этого опыта, и может пригодиться тем, кто решит пройти по той же тропе.
Ближайшие события
Руководство по использованию Tarantool Cartridge в Kubernetes
Привет, меня зовут Иван, и сегодня я расскажу как управлять приложением Tarantool Cartridge в кластере Kubernetes при помощи Tarantool Operator. Мы пройдем полный цикл от разработки до эксплуатации:
- Подготовим инструменты
- Создадим тестовое приложение
- Упакуем его в Docker
- Установим приложение в kubernetes-кластер
- Масштабируем приложение
- Обновим версию приложения
- Разберем возможные проблемы
- Кастомизируем наш кластер
- Разберемся с установкой в закрытом контуре
Как мы внедряли распределенный кеш на Tarantool в одной АБС

Разработка любого достаточно серьезного софта, будь то калькулятор матриц или ИИ беспилотного автомобиля, — это всегда какая-то своя предметная область, определенные технологии, алгоритмы и структуры данных, архитектура кода, процесс разработки и еще много разных умных терминов из мира IT.
В этой статье представлено одно из решений в мире высокой производительности и распределенных систем. Под катом вы найдёте описание всего лишь небольшого ряда задач и проблем, с которыми мы столкнулись, а также некоторые интересные алгоритмы, подходы к построению архитектуры системы, методы оптимизации запросов, ну и немного о процессе разработки и тестирования решения на базе Tarantool — платформы in-memory вычислений с гибкой схемой данных для эффективного создания высоконагруженных приложений.
Расчет перцентилей для мониторинга высоконагруженных систем
Привет, меня зовут Игорь, и я разработчик решений на Tarantool в Mail.ru Group. Я работаю над витринами маркетинга в реальном времени для Мегафона. При мониторинге часто требуется использовать перцентили. Они позволяют понять, как система работает бóльшую часть времени, в отличие от усреднения значений, которое сильно подвержено влиянию выбросов. Если 9 из 10 запросов выполняются за 1 секунду, а один за 10 секунд, то среднее будет 1,9 секунды, а 50-перцентиль — 1 секунда. Это лишь один пример того, что среднее значение не подходит для мониторинга. Возникает необходимость считать перцентили, для этого мы добавили в tarantool/metrics Summary-коллектор.
Работа с памятью в Tarantool: Small — Specialized Memory ALLocators

Tarantool — это персистентная NoSQL СУБД в памяти с хранимыми процедурами на Lua. В него встроен SQLite и дисковый движок (Vinyl). Также для Tarantool написано очень много расширений, поэтому многие считают его «сервером приложений». Здесь есть индексы разных типов, а в одном спейсе кроме первичного индекса может быть множество вторичных. Также в Tarantool есть один transaction thread, который выполняет все транзакции в памяти, есть сетевой thread и WAL thread.
Как же устроена работа с памятью в этой СУБД?
Тестируем играючи: мастер-мастер репликация в Tarantool
В качестве примера мастер-мастер кластера Tarantool я предлагаю сделать небольшую текстовую мультиплеер-игру, где каждый участник стремится набрать большее число очков.
Каждый игрок будет некоторым узлом, который меняет данные в игровом мире. Эти данные реплицируются между узлами. Таким образом, репликация Tarantool будет являться своего рода транспортом для игрового процесса.
Архитектура S3: 3 года эволюции Mail.ru Cloud Storage
Storage Corridor by St-Pete
Всем привет! Я Mons Anderson, архитектор платформы Mail.ru Cloud Solutions, расскажу, как мы построили наше S3-хранилище, как оно работает, какие решения оказались удачными, а какие стоило изменить, если бы мы начали такой же проект с нуля сейчас.
Статья подготовлена на основе доклада на @Databases Meetup by Mail.ru Cloud Solutions & Tarantool. В статье поговорим:
- как было устроено хранилище Mail.ru, поверх которого мы строили S3-хранилище;
- что мы добавили, чтобы сделать Mail.ru Cloud Storage;
- как работает объектная модель хранения и какие сделаны шаги для выхода в продакшен;
- про доработки боевой системы: фейловер и масштабирование;
- как мы реализовали шардирование и решардинг;
- а также про работу с SSL-сертификатами.
Если не хотите читать, можно посмотреть.
Кэши Tarantool и репликация из Oracle

Меня зовут Александр Деулин, я работаю в отделе развития собственной разработки «Фабрика микросервисов» в компании МегаФон. И хочу рассказать о тернистом пути появления кэшей Tarantool в ландшафте нашей компании, а также о том, как мы внедряли репликацию из Oracle. И сразу поясню, что под кэшем в данном случае подразумевается приложение с базой данных.
Вклад авторов
codesign 303.0danikin 284.4sergepetrenko 224.0KAPANDR 214.0michael-filonenko 184.0kostja 147.0yngvar_antonsson 143.0relevance_17 143.0bit_10 141.0HeadphoneActor 117.0