Заходите в гости на наш стенд,
раздаем мерч и разыгрываем призы!
раздаем мерч и разыгрываем призы!
- Стикеры
- Футболки
- Маски
- Силиконовые браслеты
- Металлические значки на рюкзаки
- Покерные фишки номиналом 1 000 000 RPS!
В конце каждого дня конференции мы разыгрываем приз - микрофон Blue Yeti
Приходите на стенд, чтобы поучаствовать в лотерее.
Приходите на стенд, чтобы поучаствовать в лотерее.
СПИКЕРЫ
Ценные знания от экспертов Tarantool
Владимир Перепелица
Как правильно выбирать очередь
Николай Карлов
Угнать за 5 миллисекунд: как мы делали транспорт для торговых ядер Московской Биржи
Ярослав Дынников
Как (не) выстрелить себе в ногу на Lua
Владислав Шпилевой
Изобретая синхронную репликацию
Василий Тюбек
Как мы Change Data Capture делали
Олег Бабин
Как написать свой индекс в Tarantool
НАШИ ДОКЛАДЫ
17 мая
главный зал
10:10
главный зал
10:10
Как правильно выбирать очередь
Владимир Перепелица
На сегодня большинство распределённых приложений требуют в качестве архитектурного элемента в том или ином виде брокер очередей. Их довольно много, при этом каждый обладает плюсами и минусами. В то же время неправильный выбор компонента очереди может поставить крест на масштабируемости или отказоустойчивости вашего приложения. В своём докладе я расскажу, на что нужно смотреть при выборе очереди, а также приведу сравнительные характеристики RabbitMQ, Kafka, NSQ и других кандидатов.
Владимир Перепелица
На сегодня большинство распределённых приложений требуют в качестве архитектурного элемента в том или ином виде брокер очередей. Их довольно много, при этом каждый обладает плюсами и минусами. В то же время неправильный выбор компонента очереди может поставить крест на масштабируемости или отказоустойчивости вашего приложения. В своём докладе я расскажу, на что нужно смотреть при выборе очереди, а также приведу сравнительные характеристики RabbitMQ, Kafka, NSQ и других кандидатов.
17 мая
зал №5
11:30
зал №5
11:30
Как мы Change Data Capture делали
Василий Тюбек, Александр Деулин
Есть нагруженная SQL-база данных известного вендора, есть потребность: получать изменения из этой базы в realtime, желательно, не переписывая все сервисы, которые пишут в эту базу данные, и отправлять их дальше. Расскажем, как мы сделали Change Data Capture из Oracle, какие способы опробовали, какие грабли собрали и как их обошли. Change data capture позволяет получать изменения с базы данных и, например, преобразовывая их в поток событий, отправлять в другие системы. Подписавшись на такой поток, можно создать специализированный поисковый индекс или быстро построить витрину данных адаптированную под конкретную задачу.
Мы сделали change data capture и стриминг событий из Oracle в витрины на Tarantool с использованием GoldenGate и Tarantool. У нас получилось довольно простое и производительное решение, которое встало в существующую архитектуру.
Расскажем:
Василий Тюбек, Александр Деулин
Есть нагруженная 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
зал №3
11:30
Как написать свой индекс в Tarantool
Олег Бабин
Tarantool — это база данных и сервер приложений. В данном случае мы будем рассматривать Tarantool именно как базу данных, а в частности, движок для хранения данных в оперативной памяти — memtx. Tarantool — open source-проект: исходный код находится в открытом доступе, что открывает большие возможности для изучения того, как организованы базы данных, а также дает возможность для написания своих решений и их последующего встраивания. Рассказ пойдет о попытке написать свою структуру данных для поиска (Z-order curve) и её встраивании в существующую экосистему Tarantool.
Данная структура используется для многомерного поиска. Часто в БД для подобных задач применяют R-Tree, но здесь возникло желание реализовать своё экзотическое решение и сравнить его с традиционными подходами. В основе лежит обычное B-дерево, поэтому данный подход должен получиться компактным и быстрым.
В докладе будет рассказано о том, как данный тип индекса был реализован и что из этого получилось. Кроме этого, будут затронуты нюансы работы Tarantool на низком уровне без привязки к конкретной структуре данных — о том, в каком виде физически хранятся внутри Tarantool, как Tarantool работает с данными и как, зная это всё, можно написать свою собственную структуру данных.
Олег Бабин
Tarantool — это база данных и сервер приложений. В данном случае мы будем рассматривать Tarantool именно как базу данных, а в частности, движок для хранения данных в оперативной памяти — memtx. Tarantool — open source-проект: исходный код находится в открытом доступе, что открывает большие возможности для изучения того, как организованы базы данных, а также дает возможность для написания своих решений и их последующего встраивания. Рассказ пойдет о попытке написать свою структуру данных для поиска (Z-order curve) и её встраивании в существующую экосистему Tarantool.
Данная структура используется для многомерного поиска. Часто в БД для подобных задач применяют R-Tree, но здесь возникло желание реализовать своё экзотическое решение и сравнить его с традиционными подходами. В основе лежит обычное B-дерево, поэтому данный подход должен получиться компактным и быстрым.
В докладе будет рассказано о том, как данный тип индекса был реализован и что из этого получилось. Кроме этого, будут затронуты нюансы работы Tarantool на низком уровне без привязки к конкретной структуре данных — о том, в каком виде физически хранятся внутри Tarantool, как Tarantool работает с данными и как, зная это всё, можно написать свою собственную структуру данных.
17 мая
зал №7
15:30
зал №7
15:30
Угнать за 5 миллисекунд: как мы делали транспорт для торговых ядер Московской Биржи
Николай Карлов, Олег Уткин
Рассмотрим одну из базовых задач, которую решает любая мировая биржа — быструю доставку данных о заявках до клиентов. На первый взгляд, задача не выглядит сложной, но есть отягчающие обстоятельства:
В нашем докладе мы расскажем:
Николай Карлов, Олег Уткин
Рассмотрим одну из базовых задач, которую решает любая мировая биржа — быструю доставку данных о заявках до клиентов. На первый взгляд, задача не выглядит сложной, но есть отягчающие обстоятельства:
- поток данных может достигать нескольких сотен тысяч запросов в секунду;
- потребителей может быть сотни, а то и тысячи;
- время между генерацией ордера и попаданием его конечному потребителю должно быть не более 5 мс в 99% случаев.
В нашем докладе мы расскажем:
- о выборе инструмента (или почему стандартные очереди не подходят для этой задачи);
- об архитектуре распределенного хранилища горячих данных
- о структурах хранения данных;
- каким образом добавление троттлинга уменьшает задержку;
- о проблемах, возникающих при горизонтальном масштабировании хранилища данных, и их решении;
- о примененных оптимизациях, в разы увеличивших производительность.
17 мая
зал №3
16:50
зал №3
16:50
Версионирование данных. Теория и практика
Максим Тремпольцев
Обзор подходов к версионированию данных, сравнение достоинств и недостатков. Примеры реализации на Tarantool.
Максим Тремпольцев
Обзор подходов к версионированию данных, сравнение достоинств и недостатков. Примеры реализации на Tarantool.
18 мая
зал №7
12:50
зал №7
12:50
Изобретая синхронную репликацию
Владислав Шпилевой
Репликация базы данных, помимо прочих применений, позволяет поддерживать актуальную копию данных на резервном узле, который в случае отказа главного (пишущего) узла может взять его роль. Без потери времени на перезапуск главного узла. Но если главный узел выполнил транзакцию, успешно ответил клиенту и не успел отправить транзакцию на реплики до своего отказа, то после переключения на резервную реплику с точки зрения клиента транзакция потеряна. Была и пропала.
Так может случиться при асинхронной репликации. Транзакции не ждут своей отправки на реплики, а завершаются сразу после записи в журнал. Это очень неприятная проблема при хранении особо чувствительных данных (например, информации о деньгах). Репликация может быть синхронной. Транзакции ждут своей отправки и подтверждения на резервных узлах до того, как завершаются и их изменения становятся видимы. Это гарантирует, что при переключении главного узла подтвержденные изменения не будут потеряны.
Обычно синхронная репликация реализуется через протокол Raft. Он проверен временем, его корректность доказана. Но у него есть ограничения:
В версии 2.5.1 был создан новый алгоритм. Он берет за основу Raft и делит его на две независимые части: репликация и выборы лидера. При этом можно выбирать, какие транзакции синхронные, а какие — нет. Это позволяет платить за синхронность только для действительно критичных изменений. Журнал при этом полностью совместим со старыми версиями, и открыта возможность реализации синхронной мастер-мастер-репликации в будущем. Доклад прольет свет на удивительную историю синхронной репликации в Тарантуле, закончившуюся изобретением нового алгоритма, и на схему его работы в части репликации.
Владислав Шпилевой
Репликация базы данных, помимо прочих применений, позволяет поддерживать актуальную копию данных на резервном узле, который в случае отказа главного (пишущего) узла может взять его роль. Без потери времени на перезапуск главного узла. Но если главный узел выполнил транзакцию, успешно ответил клиенту и не успел отправить транзакцию на реплики до своего отказа, то после переключения на резервную реплику с точки зрения клиента транзакция потеряна. Была и пропала.
Так может случиться при асинхронной репликации. Транзакции не ждут своей отправки на реплики, а завершаются сразу после записи в журнал. Это очень неприятная проблема при хранении особо чувствительных данных (например, информации о деньгах). Репликация может быть синхронной. Транзакции ждут своей отправки и подтверждения на резервных узлах до того, как завершаются и их изменения становятся видимы. Это гарантирует, что при переключении главного узла подтвержденные изменения не будут потеряны.
Обычно синхронная репликация реализуется через протокол Raft. Он проверен временем, его корректность доказана. Но у него есть ограничения:
- не предполагается наличие мастер-мастер-репликации ни в каком виде;
- журнал транзакций (WAL, Write Ahead Log) должен удовлетворять определенным свойствам.
В версии 2.5.1 был создан новый алгоритм. Он берет за основу Raft и делит его на две независимые части: репликация и выборы лидера. При этом можно выбирать, какие транзакции синхронные, а какие — нет. Это позволяет платить за синхронность только для действительно критичных изменений. Журнал при этом полностью совместим со старыми версиями, и открыта возможность реализации синхронной мастер-мастер-репликации в будущем. Доклад прольет свет на удивительную историю синхронной репликации в Тарантуле, закончившуюся изобретением нового алгоритма, и на схему его работы в части репликации.
18 мая
зал №7
14:10
зал №7
14:10
Как (не) выстрелить себе в ногу на Lua
Ярослав Дынников
Lua — простой язык. Базовые вещи можно выучить минут за 20 без преувеличения. Но несмотря на всю свою простоту, Lua всё-таки может преподнести сюрприз неопытному разработчику. А чтобы писать хороший код, хорошо бы понимать, что происходит за кулисами.
Одна из причин простоты языка заключается в том, что в Lua есть всего один композитный тип данных — таблицы. Таблицы призваны подойти для любых целей — их можно использовать и как массив (если ключи целочисленные), и как key-value-хранилище. А еще таблицам присуще свойство undefined behavior — о нем и рассказ:
Ярослав Дынников
Lua — простой язык. Базовые вещи можно выучить минут за 20 без преувеличения. Но несмотря на всю свою простоту, Lua всё-таки может преподнести сюрприз неопытному разработчику. А чтобы писать хороший код, хорошо бы понимать, что происходит за кулисами.
Одна из причин простоты языка заключается в том, что в Lua есть всего один композитный тип данных — таблицы. Таблицы призваны подойти для любых целей — их можно использовать и как массив (если ключи целочисленные), и как key-value-хранилище. А еще таблицам присуще свойство undefined behavior — о нем и рассказ:
- Для массивов с "дырками" не определено свойство длины, на результат может влиять внутреннее представление и фаза Луны.
- Добавление новых элементов во время итерирования может нарушить порядок итерации.
- Порядок итерации pairs() не детерминирован даже для массивов.
Пройдите опрос, чтобы сделать
Tarantool лучше!
Tarantool лучше!
