Команда Tarantool
на конференции HighLoad++
17 — 18 мая

Заходите в гости на наш стенд около зала №4,
у нас есть мерч!

  • Стикеры
  • Футболки
  • Маски
  • Силиконовые браслеты
  • Металлические значки на рюкзаки
  • Покерные фишки номиналом 1 000 000 RPS!
В конце каждого дня конференции мы разыгрываем приз - микрофон Blue Yeti

Приходите на стенд, чтобы поучаствовать в лотерее.
СПИКЕРЫ
Ценные знания от экспертов Tarantool
Владимир Перепелица
Как правильно выбирать очередь
Николай Карлов
Угнать за 5 миллисекунд: как мы делали транспорт для торговых ядер Московской Биржи
Ярослав Дынников
Как (не) выстрелить себе в ногу на Lua
Владислав Шпилевой
Изобретая синхронную репликацию
Василий Тюбек
Как мы Change Data Capture делали
Олег Бабин
Как написать свой индекс в Tarantool
НАШИ ДОКЛАДЫ
17 мая
главный зал
10:10
Как правильно выбирать очередь

Владимир Перепелица


На сегодня большинство распределённых приложений требуют в качестве архитектурного элемента в том или ином виде брокер очередей. Их довольно много, при этом каждый обладает плюсами и минусами. В то же время неправильный выбор компонента очереди может поставить крест на масштабируемости или отказоустойчивости вашего приложения. В своём докладе я расскажу, на что нужно смотреть при выборе очереди, а также приведу сравнительные характеристики RabbitMQ, Kafka, NSQ и других кандидатов.

17 мая
зал №5
11:30
Как мы Change Data Capture делали

Василий Тюбек, Александр Деулин


Есть нагруженная SQL-база данных известного вендора, есть потребность: получать изменения из этой базы в realtime, желательно, не переписывая все сервисы, которые пишут в эту базу данные, и отправлять их дальше. Расскажем, как мы сделали Change Data Capture из Oracle, какие способы опробовали, какие грабли собрали и как их обошли. Change data capture позволяет получать изменения с базы данных и, например, преобразовывая их в поток событий, отправлять в другие системы. Подписавшись на такой поток, можно создать специализированный поисковый индекс или быстро построить витрину данных адаптированную под конкретную задачу.

Мы сделали change data capture и стриминг событий из Oracle в витрины на Tarantool с использованием GoldenGate и Tarantool. У нас получилось довольно простое и производительное решение, которое встало в существующую архитектуру.

Расскажем:
  • что такое и зачем нужен change data capture;
  • варианты встраивания в существующую архитектуру;
  • как мы делали загрузку и репликацию данных из Oracle в Tarantool;
  • про грабли и как мы их побороли.
17 мая
зал №3
11:30
Как написать свой индекс в Tarantool

Олег Бабин


Tarantool — это база данных и сервер приложений. В данном случае мы будем рассматривать Tarantool именно как базу данных, а в частности, движок для хранения данных в оперативной памяти — memtx. Tarantool — open source-проект: исходный код находится в открытом доступе, что открывает большие возможности для изучения того, как организованы базы данных, а также дает возможность для написания своих решений и их последующего встраивания. Рассказ пойдет о попытке написать свою структуру данных для поиска (Z-order curve) и её встраивании в существующую экосистему Tarantool.

Данная структура используется для многомерного поиска. Часто в БД для подобных задач применяют R-Tree, но здесь возникло желание реализовать своё экзотическое решение и сравнить его с традиционными подходами. В основе лежит обычное B-дерево, поэтому данный подход должен получиться компактным и быстрым.

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


17 мая
зал №7
15:30
Угнать за 5 миллисекунд: как мы делали транспорт для торговых ядер Московской Биржи

Николай Карлов, Олег Уткин


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

В нашем докладе мы расскажем:
  • о выборе инструмента (или почему стандартные очереди не подходят для этой задачи);
  • об архитектуре распределенного хранилища горячих данных
  • о структурах хранения данных;
  • каким образом добавление троттлинга уменьшает задержку;
  • о проблемах, возникающих при горизонтальном масштабировании хранилища данных, и их решении;
  • о примененных оптимизациях, в разы увеличивших производительность.
17 мая
зал №3
16:50

Версионирование данных. Теория и практика

Максим Тремпольцев


Обзор подходов к версионированию данных, сравнение достоинств и недостатков. Примеры реализации на Tarantool.

18 мая
зал №7
12:50
Изобретая синхронную репликацию

Владислав Шпилевой


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

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

Обычно синхронная репликация реализуется через протокол Raft. Он проверен временем, его корректность доказана. Но у него есть ограничения:
  • не предполагается наличие мастер-мастер-репликации ни в каком виде;
  • журнал транзакций (WAL, Write Ahead Log) должен удовлетворять определенным свойствам.
Это сильно усложняет внедрение Raft в существующую БД без поломок обратной совместимости в журнале и без запрета мастер-мастер-репликации. Именно эта задача появилась в СУБД Тарантул. Годами продолжались попытки реализовать чистый Raft или что угодно на его замену. Задача нетривиальна, так как мастер-мастер в Тарантуле поддерживается, из-за чего его журнал имеет очень специфичный формат, использующий векторные часы.

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

18 мая
зал №7
14:10
Как (не) выстрелить себе в ногу на Lua

Ярослав Дынников


Lua — простой язык. Базовые вещи можно выучить минут за 20 без преувеличения. Но несмотря на всю свою простоту, Lua всё-таки может преподнести сюрприз неопытному разработчику. А чтобы писать хороший код, хорошо бы понимать, что происходит за кулисами.
Одна из причин простоты языка заключается в том, что в Lua есть всего один композитный тип данных — таблицы. Таблицы призваны подойти для любых целей — их можно использовать и как массив (если ключи целочисленные), и как key-value-хранилище. А еще таблицам присуще свойство undefined behavior — о нем и рассказ:

  • Для массивов с "дырками" не определено свойство длины, на результат может влиять внутреннее представление и фаза Луны.
  • Добавление новых элементов во время итерирования может нарушить порядок итерации.
  • Порядок итерации pairs() не детерминирован даже для массивов.
Доклад полон примеров, отсылкам к стандарту и объяснениями причин. Но даже "опасный" код может работать без сюрпризов, главное — знать, когда на это можно рассчитывать.

Пройдите опрос, чтобы сделать
Tarantool лучше!
This site was made on Tilda — a website builder that helps to create a website without any code
Create a website