Приходи на стенд Tarantool на конференции Highload ++
Наш стенд находится в павильоне №3 комплекса Крокус Экспо возле зала h5
Заходи в гости и забирай магический мерч у Оракулов Распределенных Систем!
24-25 ноября
Стикеры из будущего — новый дизайн Tarantool уже на Highload ++!
Приходи
на стенд Tarantool на конференции Highload ++
Наш стенд находится в павильоне №3 комплекса Крокус Экспо возле зала h5
Заходи в гости и забирай магический мерч у Оракулов Распределенных Систем!
Стикеры из будущего — новый дизайн Tarantool уже на Highload ++!
24-25 ноября
Покерные фишки номиналом 1 000 000 RPS — придадут уверенности в прохождении код-ревью
Амулеты Силы — защитят твой код на любом демо команды
Носки из Туманности Tarantool — согреют в часы переработок
Футболка Tarantool придаст неуязвимости в любом стеке технологий!
Пройди опрос от Оракулов Распределенных Систем
Испытай удачу и выиграй наушники — Mysound BH-13 ANC!
Разгадай тайну Туманности Tarantool, попытай удачу в гадании на Технологический Стек и выиграй магический мерч!
Попробуй на себе проверенные методы предсказаний наших Экспертов
Пройди опрос от Оракулов Распределенных Систем
Испытай удачу и выиграй наушники — Mysound BH-13 ANC!
Разгадай тайну Туманности Tarantool, попытай удачу в гадании на Технологический Стек и выиграй магический мерч!
Попробуй на себе проверенные методы предсказаний наших Экспертов
Наши докладчики на Highload++ 2022
Владимир Перепелица
Архитектор Tarantool и VK Cloud Storage
Архитектура надёжной In-Memory СУБД на примере Tarantool
Распределенные системы и микросервисные архитектуры провоцируют использовать In-Memory СУБД. И если вы на гребне волны и в вашей разработке активно используется Tarantool, то этот доклад для вас: вы познакомитесь со внутренностями архитектуры СУБД и сможете более уверенно использовать ее в работе.

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

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

— Я рассмотрю устройство Tarantool от входящего запроса до работы синхронной репликации и транзакционного механизма на скорости в 1 000 000 RPS.

Цель моего доклада — показать, что in-memory-технологии уже достаточно зрелые и надёжные, чтобы быть основным хранилищем данных в вашем продукте.
24 ноября
Зал «h3: Яндекс Трек»
13:30
Александр Горякин
Разработчик высоконагруженных систем хранения данных,
Tarantool
Репликация между SQL- и NoSQL-базами данных: туда и обратно
В последнее время в рабочих процессах очень часто сталкиваемся с проблемой переноса данных между базами разных типов: реляционными, NoSQL, документоориентированными, колоночными и др. Для этого существует несколько подходов. На основе некоторых из них разработаны решения.

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

Tarantool — платформа in-memory-вычислений с гибкой схемой данных для эффективного создания высоконагруженных приложений. VK — это больше 200 технопроектов. Свыше 10 000 человек создают и развивают одни из самых популярных и высоконагруженных интернет-сервисов в стране. Делают комфортнее, легче и интереснее жизнь сотне миллионов людей.
24 ноября
Зал «h3: Яндекс Трек»
11:10
Сергей Останевич
Архитектор репликации, Tarantool
Повышаем живучесть Raft в реальных условиях
Доклад будет интересен всем, кто интересуется распределенными системами. Это отличная возможность освежить в памяти понимание работы протокола RAFT, узнать проблемы, присущие канонической реализации, послушать про улучшения протокола, которые пришлось реализовать в Tarantool.

Алгоритм Raft стал весьма популярен в последние годы. Описание алгоритма достаточно ясно, имплементации появляются во все большем количестве проектов. Однако все выглядит хорошо на бумаге — будь то математика или рекламные статьи, а при практическом применении все оказывается сложнее.

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

Итак, на практике мы ожидали от Raft следующего.

Во-первых, кластер должен оставаться доступным и на запись и на чтение при частичной потере связности в сети. Канонический Raft не даёт таких гарантий, и это привело к инциденту в Cloudflare в 2020, когда одна из реплик не видела лидера и на протяжении 6,5 часов постоянно устраивала новые выборы, не давая лидеру поработать хоть сколько-нибудь.

Решение проблемы с доступностью кластера при частичной потере связности создает еще одну: при определенных условиях кластер будет неспособен выбрать нового лидера даже при наличии достаточного количества живых и соединенных между собой узлов, в то время, как предыдущий лидер уже не имеет достаточного количества живых соединений и более неспособен произвести запись. Чтобы это исправить, необходимо, чтобы лидер “слагал полномочия” в случае потери кворума живых соединений. Кроме этого, добровольное снятие полномочий позволяет обеспечить уникальность лидера в кластере: к моменту, когда будет выбран новый лидер, старый лидер уже сложит полномочия.

В конце концов, хочется, чтобы после смерти старого лидера кластер стал снова доступен на запись (выбрав нового лидера) максимально быстро (через 10-15 секунд).

24 ноября
Зал «h4»
11:10
Сергей Петренко
Разработчик репликации, Tarantool
AP и CP: пытаемся усидеть на двух стульях и боремся с последствиями
Многие системы, стараясь описать свое поведение в ненадежной сети, прибегают к терминам CAP-теоремы и описывают себя либо как AP, либо как CP.

Алгоритм Raft является классическим примером CP — обеспечивает линеаризуемость в случае разделения сети, но это в определенных случаях приводит к временной потере доступности и на запись, и на чтение до восстановления связности.

Да, на бумаге всё хорошо. Берём нечётное количество узлов и наслаждаемся работоспособностью кластера и консистентностью данных до тех пор, пока большая часть узлов работает. Однако, эта схема использования идёт вразрез с самой популярной схемой установки БД: равное число узлов в двух ЦОД-ах. Для Raft это значит, что потеря одного ЦОД-а сразу приведёт к недоступности кластера на запись.

Отсюда возникает необходимость переключения между надёжностью и доступностью: если пользователь видит, что один из двух ЦОД-ов неработоспособен, он может решить продолжить обслуживать запросы в живом ЦОД-е без участия второго ЦОД-а, то есть превратить CP-систему в AP. Мы дали пользователю такую возможность в реализации Raft в Tarantool и столкнулись с условиями потери консистентности данных, с которыми бы никогда не встретился канонический Raft.

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

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

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

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

В этом докладе поговорим о методах, которые мы применили, чтобы обнаруживать такие расхождения и обеспечивать консистентность данных после периода работы в разделенной сети.
25 ноября
Зал «h6»
10:00
Александр Ляпунов
Разработчик СУБД, Tarantool
Как работает MVCC в in-memory СУБД
Один из ключевых механизмов любой СУБД — это возможность предоставить согласованное состояние данных в базе в виде "снимка" или "снапшота". Этот механизм используется в первую очередь для организации изоляции транзакций: каждая транзакция видит свою версию состояния базы данных. В сочетании с другими механизмами это порождает технологию MVCC, когда транзакции независимо и одновременно видят каждая свое собственное состояние БД и работают в нем. Помимо этого, снимок состояния базы данных (записанный в файл) можно использовать для восстановления после перезапуска, а также для инициализации реплики.

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

В этом докладе я на примере In-Memory-СУБД Tarantool в памяти расскажу, как устроены снимки данных и MVCC, как и почему эволюционировали эти алгоритмы, во что обходится поддержание этих структур пользователю, как правильно использовать и что ожидать от этих механизмов.
25 ноября
Зал «h3: Яндекс Трек»
14:40
Сергей Бронников
Разработчик,
Tarantool
Что я говорю, когда говорю о фаззинге LuaJIT
Любая программа, запущенная на компьютере, была создана компилятором и, так как компиляторы являются важной частью инфраструктуры для создания программного обеспечения, их корректность имеет первостепенное значение. Чтобы проверить и повысить правильность поведения компиляторов, значительные усилия во время разработки направлены на тестирование компиляторов.

В Tarantool за поддержку языка Lua отвечает LuaJIT, который включает в себя как среду исполнения языка, так и трассирующий JIT-компилятор. Мы решили использовать фаззинг-тестирование для LuaJIT, потому что стандартное тестирование не позволяет выявить все проблемы во время разработки. Несмотря на популярность рандомизированного тестирования и множество доступных инструментов для фаззинга, нам пришлось изучить методы, показавшие эффективность при тестировании других компиляторов, и разработать собственные инструменты. Мы попробовали фаззинг без грамматики, фаззинг с грамматикой на основе LibFuzzer и LibProtobufMutator, собственный мутатор для Lua-программ и проверку оптимизаций с помощью SMT-решателя.

В докладе я расскажу про различные аспекты проблемы тестирования корректности компилятора, в том числе то, как генерировать случайные программы, какие тестовые оракулы использовать для определения того, правильно ли ведет себя компилятор, как эффективно выполнять тесты компилятора и эффективных методах тестированиях компиляторов на основе нашего опыта тестирования LuaJIT.
24 ноября
Зал «h4»
10:00
Пройди опрос, чтобы сделать Tаrantool лучше!
© Tarantool 2022 г. Все права защищены.
Подписывайтесь на канал, чтобы быть в курсе последних событий и пообщаться в чате.
Подписывайся на наш канал Tarantool
Follow the white rabbit
Политика конфиденциальности
Группа пользователей Tarantool