О чём расскажут на Hydra: параллельность и распределённость от введения до хардкора26.05.2022 21:16

У конференции Hydra в этом году кое-что меняется: кроме двух онлайн-дней, будет ещё и офлайн-день в Петербурге, позволяющий по-настоящему собраться вместе и как следует пообщаться.

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

Но главное остаётся прежним:

• Конференция посвящена разработке параллельных и распределенных систем.

• На ней сходятся вместе IT-индустрия и академический мир (тут можно познакомиться и со свежими теоретическими результатами, и с «историями из продакшна»).

• Доклады на английском.

О чём будут доклады в этот раз? Хотя на сайте их описания даны на английском, для хабрачитателей перевели эти описания на русский.

Оглавление

Concurrency

Intro to Concurrent Programming: часть 1, часть 2, часть 3

В целом Hydra рассчитана на опытных специалистов, но даже тем, кто еще не погрузился в сферу очень глубоко, там будет что послушать. Никита подготовил целую серию из трёх докладов под общим названием «Введение в многопоточное программирование».

В первой части он расскажет про классические алгоритмы стека и очереди. Во второй — покажет, как применить эти знания и построить быстрые и масштабируемые очереди, которые используют fetch-and-add и технику flat combining. А в третьей части поговорит о структурах данных с relaxed-семантикой и их применимости в различных параллельных алгоритмах. 

В рамках этой мини-серии вы познакомитесь как с классическими, так и с современными многопоточными алгоритмами. 

Thread pools: variety of algorithms and features

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

Станислав познакомит вас с пулами потоков, которые были реализованы в Java, .NET и прочих рантаймах. В ходе доклада мы:

• Рассмотрим решаемые ими задачи и научимся понимать проблемные места.

• Создадим свой пул потоков, после чего добьёмся его максимальной производительности.

Fusing Efficient Parallel For Loops with a Composable Task Scheduler

Если мы хотим эффективнее использовать процессор в больших многоядерных системах, нам нужно выжать максимум параллелизма на всех возможных уровнях всех компонентов приложения. Для это нужны вложенные, компонуемые, динамические, но при этом эффективные многопоточные системы. Параллелизм на основе задач, как в OneTBB от Intel, решает проблему oversubscription и дает эти три желаемых свойства, но имеет и свои ограничения, которые влияют на эффективность по сравнению с классическим подходом OpenMP.

Антон расскажет, как они с командой впервые столкнулись с этими ограничениями при разработке среды выполнения Intel OpenCL для архитектур CPU и MIC. Им удалось значительно сократить разрыв с OpenMP. Даже сегодня их производительность остается непревзойденной, если сравнивать с PoCL (реализацией с открытым исходным кодом).

Сегодня параллелизм на основе задач набирает популярность даже в области HPC. Всё это — благодаря новым спецификациям OpenMP и таким технологиям, как BOLT и OmpSS. Но и количество процессорных ядер продолжает расти, что, в свою очередь, снова возвращает к тем же вопросам.

Java PathFinder: going to Mars without bugs and deadlocks

Александр рассмотрит известный инструмент для поиска тонких проблем в конкурентности: Java PathFinder, разработанный в NASA. По сути своей это специальная JVM, которая использует метод проверки моделей, чтобы найти в Java-коде проблемы со взаимной блокировкой или состояния гонки. Спикер расскажет про сам инструмент, его применение и ограничения, а также сравнит его с JCStress и Lincheck.

Exploring Traffic Jams in Your Data Flows

Все мы каждый день сталкиваемся с очередями и пробками. Мы ждем, пока машины в заторе поедут, кассир пробьет покупки человека перед вами, ОС передаст диску наши запросы на запись и чтение, а API-шлюз пропустит наши запросы на микросервисную ферму. Во многих случаях мы даже не подозреваем, что внутри каких-либо систем есть очередь или буфер. На самом деле волны «пробок» могут существенно снижать производительность.

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

What about Binary Search Trees?

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

Distributed

A sledgehammer to crack a nut: why blockchain is not (always) a good idea

Петр обсудит спорные моменты, связанные с блокчейном. Не оказывается ли его применение «стрельбой из пушки по воробьям»? Можно ли реализовать криптовалюту (самое популярное применение блокчейна) гораздо проще и эффективнее, чем это делают? Какая еще проблема есть у традиционных блокчейн-реализаций? А затем он объяснит, как эти вопросы могут помочь в проектировании надежных реплицированных сервисов.

Self-stabilizing Population Protocols

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

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

Making a desktop IDE distributed and collaborative

Решения Gateway и Code With Me от JetBrains предназначены для удаленной и коллаборативной разработки. Оба они основаны на том, что делят ранее единый процесс IDE на клиентскую и серверную части, взаимодействующие друг с другом. Каждая часть, по сути, представляет собой IDE на платформе IntelliJ.

Традиционные решения для удалённой разработки (например, «поделиться экраном») страдают от плохого качества видео, сетевых задержек, большого объёма трафика, несовпадающих хоткеев. Здесь же вместо видеопотока идёт обмен лишь конкретными действиями, сводя данные к минимуму, и коммуникация асинхронная.

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

Scaling Raft

ScyllaDB — распределенная база данных c eventual consistency, совместимая с Cassandra. Константин работает над различными БД ещё с тех времен, когда MiniSQL была популярнее MySQL, а сейчас работает именно над ScyllaDB.

В Scylla, начиная с версии 5.0, стали активно использовать протокол Raft. И в этом докладе о масштабированиии Raft Константин обсудит сложности поддержки сотен инстансов этого протокола на одном узле и о том, как получилось уменьшить нагрузку на сеть и диск, которые создает каждая из Raft-групп (благодаря тому, что работа по обнаружению отказов и персистентности была разделена между разными группами).

Distributed transactions implementation trade-offs

Какие сложности несет в себе распределенная система транзакций? В чем важность ACID-характеристик транзакций? Как они используются в распределенных базах данных с шардированием и репликацией? На эти вопросы ответит Артём Алиев из Huawei. 

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

Parallel Asynchronous Replication between YDB Database Instances

Асинхронная репликация — это хорошо известный метод обеспечения независимой копии базы данных для различных целей, включая аварийное восстановление, георепликацию или масштабирование нагрузки чтения. Как правило, журнал изменений исходной реплики рассматривается в качестве входных данных для базы данных целевой реплики. Если исходная и целевая реплики являются распределенными базами данных с высокой рабочей нагрузкой, то свести все обновления в один журнал изменений может быть практически невозможно. Например, YDB — это распределенная база данных SQL, которая построена из надежных компонентов, называемых таблетками, каждая таблетка имеет свой собственный журнал восстановления, и обновление пользователя может изменять данные в разных таблетках в одной транзакции. Транзакции с несколькими таблетками обеспечивают гарантии ACID через внутренний механизм распределенного выполнения транзакций. 

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

• Поток изменений из исходной базы данных разделяется между несколькими персистентными очередями, что позволяет нам масштабировать журнал изменений базы данных;

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

Solving Raft’s practical problems in Tarantool. What, how and why

Tarantool — это платформа для in-memory вычислений, а технически — СУБД и сервер приложений. База данных поддерживает два движка хранения данных: в памяти (с персистентностью с помощью ведения журнала и снапшоттинга) и на диске (на основе LSM деревьев).

Изначально в Tarantool была только асинхронная репликация, однако позже решили добавить в Tarantool синхронную, а также встроенный механизм автоматического фейловера. Изучив возможные альтернативы решения данных задач, выбрали Raft. И тут выяснилось, что между реализацией Raft и production-ready реализацией Raft есть довольно большая разница. От системы в продакшне требуют больше, чем может предоставить канонический Raft.

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

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

А также должна быть возможность ручного вмешательства в работу кластера и назначения лидера извне. Иначе в популярной схеме, когда кластер размещается в двух ЦОДах, по половине узлов в каждом ЦОДе, потеря ЦОДа гарантированно означает невозможность выбрать лидера и записать хоть что-нибудь.

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

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

Database Internals

How ScyllaDB makes LSM-tree compaction state-of-art by leveraging RUM conjecture and controller theory

Механизмы LSM-деревьев обеспечивают высокую пропускную способность записи, поскольку они позволяют добавлять новые данные в неизменяемые файлы — Sorted String Table (aka SSTable). Со временем в таких системах возникает read amplification, и поэтому подсистемам хранения нужен процесс фонового сжатия. Существует несколько политик сжатия, каждая из которых подходит для работы с определенной нагрузкой. Например, leveled-политика подходит для нагрузок, выполняющих перезапись и чувствительных к задержке считывания, но она приводит к увеличению write amplification. А tiered-политика улучшает производительность записей в базу ценой повышения стоимости чтения и space amplification. Также существуют смешанные подходы, сочетающие обе эти политики.

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

OK S3

Одноклассники уже долгое время эксплуатируют собственные распределённые отказоустойчивые хранилища данных. Для хранения и обработки почти эксабайта бинарных данных (видео, фото, музыка и др.) используются one-blob-storage и one-cold-storage. В качестве транзакционных хранилищ развернуты десятки нагруженных кластеров NewSQL на базе Cassandra, распределенных по трем или пяти датацентрам. Команда успешно переживает аварии вплоть до выхода из строя датацентра без деградации обслуживания, в том числе в час пик.

Помимо своих систем в Одноклассниках эксплуатируют множество готовых продуктов для хранения артефактов сборки и тестирования, библиотек, образов, пакетов, логов, бэкапов и т. д. Единственным общим знаменателем в качестве подключаемого бэкенда хранения для всех этих сервисов является Amazon S3, который предоставляет высокоуровневый API для работы с объектами, а также обладает развитой экосистемой инструментов и SDK для многих языков.

Спикер рассмотрит реализацию совместимого с S3 сервиса в Одноклассниках поверх уже существующих NewSQL и хранилища блобов: архитектуру и схему данных, особенности и компромиссы, оптимизации и производительность, а также встреченные по пути сложности и неожиданности.

Описанные в докладе решения и опыт могут оказаться полезными архитекторам и разработчикам распределенных сервисов хранения данных, особенно S3-подобных и/или на основе Cassandra, вне зависимости от используемых языков и платформ.

HTAP Workloads: Challenges and Solutions

Илья в своем докладе разберет задачу, как реализовать HTAP-нагрузку в СУБД. HTAP (Hybrid Transactional & Analytical Processing) должна эффективно поддерживать одновременно два вида запросов:

• Транзакционные OLTP-запросы, которые нужно выполнять с максимальной пропускной способностью и низкой задержкой.

• Аналитические OLAP-запросы, которым для выполнения нужно считать и анализировать много строк.

В качестве решения спикер предложит сразу несколько приемов: персистентные деревья и их параллельные версии, подход MVCC (его версия fork+COW) и смену формата хранения данных при репликации.

Pragmatic Code Generation for Efficient Execution

Сатьям Шехар расскажет о движке NetSpring на основе генерации кода для эффективного вычисления операторов. Он начнет с базовых сведений о SQL-движках и подходах, популярных в прошлом (Volcano), затем перейдет к различиям и ограничениям векторных систем и систем, основанных на генерации кода, а в конце попробует найти между ними золотую середину.

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

© Habrahabr.ru