В определенный момент мы приняли решение о переносе всех наших микросервисов внутрь Kubernetes. У нас достаточно активно используется Tarantool, и такая миграция не могла не затронуть сервисы, основанные на Тарантуле.

Как и в случае большинства баз данных, Tarantool очень легко развернуть в Kubernetes в единичном экземпляре, но нет возможности "одной командой" масштабировать сервис по мере повышения нагрузки.

В рамках доклада мы расскажем про то, какие задачи у нас возникли в процессе перехода, какие были сложности, и какие инструменты использовались для их решения. Расскажем про особенности переноса statefull и stateless tarantool'ов, а также про нюансы частичной миграции.

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

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

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

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

Write ahead logging или write behind logging (и, вообще, зачем теперь logging)? Блочный доступ с минимальным размером сектора или байтовый доступ? Есть ли смысл в байтовой адресуемости, если устройство подключено в шину PCI Express? DAX, переход на NVM API или использование переходного ПО без модификаций? Энергонезависимая память по сети — непрактичное упражнение, или пора бежать настраивать?

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

Почему Сбербанк переходит на In-Memory Data Grid (IMDG) технологии?
Архитектура новой платформы.

Как мы тестируем новую платформу на базе GridGain?
* Опыт тестирования Amazon, Twitter, Netflix.
* Этапы тестирования в Сбербанке.
* Fault Injection (внесение неисправностей).
* Кейсы надежности Сбербанка.
* Учения в промышленной среде.

Предпосылки:
- Тупик вертикального масштабирования.
- Рост нагрузки.
- Глобализация.

Технологические вызовы:
- Масштабируемость.
- Географическая распределенность.
- Отказоустойчивость.
- Большая частота изменений.

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

1. Зачем нужен R&D к крупных компаниях? Выход из технологического тупика. R&D должен нарушать правила.
2. Что такое Tarantool и как правильно его готовить.
3. Как нарушать правила и не получать штрафы за увеличение скорости в 100 раз.

- .net - это не только Windows, но ещё и Linux, и OS X. Нет, не mono.
- Использование Tarantool в .net core: плюсы, минусы, проблемы и способы их решения.
- Производительность progaudi.tarantool.
- Возможно ли выжать 2М RPS с одного сервера на .net core?

Tarantool - сервер приложений, а значит, необходимо уметь правильно писать на нём приложения.

В докладе я покажу, как правильно выстроить layout приложения под разные use-case'ы, какие существующие библиотеки и модули помогают сделать жизнь разработчика приложения на Tarantool легче как при разработке, так и при запуске его в production.

Кроме того, рассмотрим, как сделать управление схемой базы данных более простой к пониманию и использованию.

1) Что такое интернет вещей? (коротко, обещаю)
2) Зачем интернету вещей системы управления?
3) Функциональные элементы системы управления: драйвера, action-scripts, timer-scripts, веб-интерфейс, общая шина.
4) При чем тут Tarantool и почему именно он? Почему мы не используем (почти) базу данных?
5) Реализация: архитектура и код.

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

Я расскажу и покажу, как раскрыть этот потенциал: как использовать встроенный в сервер LuaJIT, сокеты, файберы и каналы. Также мы рассмотрим сильные и слабые стороны языка Lua: как писать, чтобы не убить производительность. Всё это будет рассмотрено пошагово на примере создания сервера очередей.

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

Доклад построен по принципу tutorial, то есть слушателям будет предложен ряд примеров и упражнений, которые можно будет выполнить во время доклада.

Презентация

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

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

В рамках доклада пойдет речь о внутреннем устройстве VShard, о его подсистемах и реализации, с примерами использования.

В прошлом году наша команда выпустила новую версию СУБД Taratnool, которая среди прочего имела в своем составе дисковый движок для для хранения данных. В этом году мы сосредоточились на разработке следующей версии Тарантула: 2.0.

В докладе будет представлен обзор новых возможностей, которые мы собираемся добавить в этот major-release: как и в каком объеме будет подержан язык SQL, обзор синхронной репликации, новый подход к шардингу, интерактивные транзакции, а также DDL в транзакциях.