SWIM - это протокол обнаружения и мониторинга узлов кластера, распространения событий и данных между ними. Протокол особенен своей легковесностью, децентрализованностью и независимостью скорости работы от размера кластера.

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

Согласно протоколу, участники кластера делают широковещательные и точечные ping-запросы. Широковещательные обнаруживают новые узлы, точечные проверяют доступность уже известных.

Вторая задача — распространение событий в кластере. Событие — это отказ узла, смена его UUID или IP-адреса, появление нового узла. Бывает, что пользователь вводит свои собственные типы событий. Когда о событии узнают один или несколько узлов, им надо его распространить, чтобы у нем узнали все. Протокол SWIM описывает алгоритм обнаружения и распространения событий, которому требуется:
- константное время, чтобы хотя бы один узел узнал о событии;
- время, логарифмическое от размера кластера, чтобы о событии узнали все.

В докладе рассказывается о том, как устроен протокол SWIM, как и с какими расширениями он реализован в Тарантуле.

В этом докладе я расскажу про новый подход в структурировании и поставке приложений в Tarantool:
- как управлять зависимостями (rockspec + друзья);
- как писать и запускать юнит- и интеграционные тесты;
- покажу превью нового тестового фреймворка для приложений;
- как паковать приложения вместе с зависимостями (и почему мы выбрали статическую линковку);
- как задеплоить в продакшн с systemd.

Учитывая отсутствие на сегодня внятных инструкций про это, вам точно будет интересно.

Многие сталкиваются с проблемой, что их текущая модель данных, унаследованная от древнего Enterprise'а, начинает не выдерживать возрастающие нагрузки. И всё бы ничего, если бы заказчик не приходил всё с новыми и новыми доработками для данного кейса.

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

Предлагаемый доклад — это пошаговая инструкция, как вывести часть реляционной БД в NoSql-хранилище данных.

1. Вызовы современных бизнес-систем уровня предприятия.
2. Четырехуровневая архитектура и цифровые экосистемы.
3. Для чего применяются in memory DB и noSQL БД в Enterprise.
4. Опыт применения Tarantool и других нереляционных БД в МегаФон.

Tarantool Enterprise - это не только ценный мех, но ещё и богатый фичами SDK. В своём докладе я расскажу, чем он отличается от opensource-версии и какую пользу может принести. А отличий в нём немало: это и инструментарий администрирования кластером, и готовый workflow разработки, и статическая сборка, не требовательная к настройке окружения.

В Сбертехе мы используем Tarantool для модуля авторизации. Это много разных данных и специфические паттерны использования: например, мы хотим, чтобы в одном бакете лежали разные данные, которые мы модифицируем в одной транзакции. Мы форкнули vshard и сделали несколько полезных нам модификаций: map/reduce, возможность писать в реплики, проброс собственных ошибок и еще по мелочам. В докладе расскажу о результатах этого эксперимента и предложу оценить, насколько наше opensource-решение может быть полезно для ваших задач.

- Зачем нужен MDM?
- Зачем нужен риалтайм?
- Data Science - это не только Jupyter Notebook.
- Плюсы Tarantool.
- Lua больше в разработке, приятно в проде.

С выходом серии 2.x Tarantool закончил свой подростковый период: SQL, vinyl, шардинг делают возможным построение практически любых решений. Сообщество только начинает использовать эти возможности, но преимущество основателя проекта - возможность раньше других увидеть то, как изменится использование продукта в будущем.

Tarantool имеет уникальные отличия от других СУБД: высокое соотношение простоты использования эффективности и скорости к реализуемым возможностям. Гармоничное сочетание возможностей классических СУБД, таких как ACID-транзакции и возможностей NoSQL, таких как горизонтальное масштабирование и LSM-деревья в одном продукте. Наличие высокоэффективного сервера приложений на борту.

В чём же состоит уникальный ДНК продукта, и каков должен быть критерий включения возможностей в roadmap? Какие именно задачи Tarantool решает лучше других, и что нужно для того, чтобы он делал это ещё лучше?

Над очевидными и наиболее востребованными изменениями уже ведётся работа. Удобство управления репликацией: автоматическое переключение реплик; параллельная, синхронная репликация; возможности шардинга "из коробки"; запланированные улучшения в SQL, application server и storage engines.

По возможности, для каждого изменения я расскажу о том, какие изменения они несут для пользователей продукта и как устроены изнутри.

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

Тинькофф - крупная IT-компания, и мы используем очень много сложной аналитики для работы с данными.

Транзакционные базы не могут обрабатывать сложные аналитические запросы, поэтому для аналитики мы используем хранилище данных на основе GreenPlum. При наших объемах данных реплицировать с Oracle в GreenPlum - нетривиальная задача, но с помощью Tarantool мы смогли сократить количество запросов к аналитическим базам всего до 3-х за один batch и обеспечить задержки менее четырех часов.

В докладе я расскажу, как мы организовали такую систему, и поделюсь накопленным за годы опытом.

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

В этом докладе я расскажу, как новый продукт на базе Tarantool - ChannelControl - позволяет решить задачи автоматизации коммуникаций для обеспечения омниканальности.

* Из чего возникла потребность в кэшах. Какие особенности есть в Enterprise. Vendor lock и кэши.
* Какие есть способы получения данных из закрытых подсистем.
* Варианты репликации данных из Oracle: CQN, GG. Какой вариант мы выбрали и почему.
* PIM - кэш продуктов абонента. Как прочитать 10 млрд записей из Oracle и не уронить систему.
* Подробно про схему репликации, холодную загрузку и штатную работу репликации ORACLE-Tarantool

Архитектура инвестиционного бизнеса Альфа-Банка была заложена в начале 2000-х годов. С тех пор мир пережил финансовый кризис 2008 года, появление криптовалют и mobile-first-революцию. Мир ценных бумаг и финансов стал доступен каждому, число торговых операций выросло на несколько порядков, усилилось регулирование рынка ценных бумаг.

В своем докладе мы:
- расскажем о том, зачем инвестиционному бизнесу Альфа-Банка понадобилось кардинально менять свою архитектуру и переходить на In-Memory СУБД;
- рассмотрим задачи, которые стояли перед нашей командой, и какую ценность инфраструктурный проект может принести бизнесу;
- поделимся опытом внедрения и тестирования прикладного решения на базе Tarantool;
- поговорим о том, какие бизнес-задачи уже решены, а также какие планируется решать на новой платформе в ближайшее время.

В докладе я расскажу, как использовать Intel Optane вместе с Tarantool. Будут рассмотрены эффекты от использования Non-Volatile-режима для записи транзакционных логов, возможность вертикального масштабирования In-Memory-движка в связке с Volatile-режимом Intel Optane, хорошие и плохие профили нагрузки с точки зрения пропускной способности и задержек. Еще я расскажу про разные реализации Intel Optane и сравню их применительно к Tarantool.

Документация по Tarantool рассказывает, как использовать Tarantool в качестве базы данных, но крайне мало информации о том, как делать приложения.

В докладе я расскажу о подходах, которые были сформированы командой Облака Mail.ru и MCS в течение 6 лет эксплуатации Тарантула в качестве разнообразных приложений, а также о модулях, которые могут быть полезны при создании приложений.

Мы не используем Tarantool как базу данных (ну, почти). У нас нет мощных серверов, резервирования, больших баз данных и кучи запросов. Но зато у нас есть задачи, от которых удивляются разработчики самого Тарантула (проверено в чате).

Три основные темы моего рассказа:
1) Tarantool на прокачку: как запускать пользовательские скрипты внутри Tarantool, и зачем это вообще может хоть кому-то понадобиться?
2) Братья наши меньшие: Tarantool и встраиваемые системы на процессорах ARM.
3) Не тратя лишнего: как сделать CI/CD и debian-репозиторий на базе открытых бесплатных инструментов и GitHub.

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