Tarantool *

Всем привет, меня зовут Алексей Фельде, я IT архитектор направления Омниканальности в «Магните». Это молодое направление. Основная его цель - сформировать единый опыт офлайн и онлайн взаимодействия с покупателем. 

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

Сервис экспресс-доставки стал первым в направлении Омни «Магнита». Поначалу мне казалось, что запуск такого онлайн-сервиса – классическая история с не менее классическим подходом к решению. Однако для ритейла, который более 25 лет затачивал свои бизнес-процессы под офлайн, запуск обернулся настоящей инженерной головоломкой.

В этой статье я расскажу, как в режиме speedrun небольшая инженерная команда запустила онлайн-сервис экспресс-доставки на Golang с помощью Tarantool Data Grid, gRPC и облака Mail.ru Cloud Solutions.

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

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

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

• Вначале посмотрим глазами новичка. Что такое БД в памяти? Какие задачи они решают лучше дисковых БД?
• Потом посмотрим архитектурно. Как обстоит вопрос с производительностью, надёжностью, масштабированием?
• В третьей части лезем в технические вещи поглубже. Типы данных, итераторы, индексы, транзакции, ЯП, репликация, коннекторы.

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

Я работаю в команде, которая занимается разработкой, внедрением и поддержкой готовых решений на основе Tarantool. Для вывода наших приложений в эксплуатацию на контуре заказчика было необходимо не только разобраться в текущих возможностях мониторинга, но и доработать их. Большая часть доработок в результате вошла в те или иные стандартные пакеты. Данный материал является текстовой выжимкой этого опыта, и может пригодиться тем, кто решит пройти по той же тропе.

Привет, меня зовут Иван, и сегодня я расскажу как управлять приложением Tarantool Cartridge в кластере Kubernetes при помощи Tarantool Operator. Мы пройдем полный цикл от разработки до эксплуатации:

• Подготовим инструменты
• Создадим тестовое приложение
• Упакуем его в Docker
• Установим приложение в kubernetes-кластер
• Масштабируем приложение
• Обновим версию приложения
• Разберем возможные проблемы
• Кастомизируем наш кластер
• Разберемся с установкой в закрытом контуре

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