Доклады секции "Базы данных и системы хранения"

Никогда такого не было, и вот опять! Спустя 15 лет после появления S3 пользователям всё ещё нужны кластерные ФС под сценарии использования, близкие к тому, на что обычно рассчитано S3. А именно: большую/бесконечную ёмкость, низкую стоимость хранения, крупноблочный доступ, масштабируемость.

А можно ли сделать из S3 ФС? Обычный ответ: можно, но будет очень медленно. Казалось бы, файл — это «именованная последовательность байтов» и объект в S3 — тоже. Однако ФС плохо работает как S3, а S3 обычно плохо работает как ФС. Но почему?

Наш ответ в том, что если половина этой проблемы — действительно архитектурные вопросы различий между ФС и S3 (о которых мы, кстати, тоже поговорим, например, рассмотрим вопрос «а что, вообще, такое POSIX-совместимость ФС?»), то оставшаяся половина — исключительно вопросы реализации, которые оказалось не так уж сложно решить.

И решены они в GeeseFS https://github.com/yandex-cloud/geesefs. GeeseFS — это ещё одна утилита для монтирования S3 через FUSE в виде локальной ФС, но, в отличие от всех остальных реализаций, достаточно POSIX-совместимая и достаточно быстрая, чтобы её можно было использовать без слёз. 🙂

Понятное дело, все проблемы «S3 как ФС» без расширения протокола на стороне сервера не решишь, так что в наши дальнейшие планы входит именно расширение протокола. Конечная цель — оптимизация использования S3 в сценариях, где традиционно «рулят» ФС.

Что реализовано в части нашей S3-ФС уже сейчас, что запланировано на будущее, а также как другие решают ту же задачу (скрещивания ужа и ежа) — обо всём этом мы и поговорим в докладе.

Не нужно рассказывать о том, насколько хороша СУБД Oracle и сколько задач решается с ее помощью. Однако, тема использования альтернативных СУБД сегодня становится все более актуальной.

Сотни хранимых процедур с кучей бизнес-логики, десятки терабайт данных, высокая связность с другими системами — разве могут быть варианты, кроме Oracle?

Да, конечно! Этот доклад — о проекте миграции систем промышленных масштабов с Oracle на отечественную СУБД PostgresPro.

Замена СУБД — непростая задача: нужно заменить фундамент, но так, чтобы не рухнули стены. В докладе расскажу о том, как мы переносили бизнес-логику из Oracle PL/SQL на PLPG/SQL на примере системы, которой пользуются граждане нашей страны.

Сторадж — фундаментальный инфраструктурный сервис, хранящий и раздающий данные почти всех продуктовых сервисов Яндекса (Диск, Почта, Карты, Поиск, Маркет и т.д.), — критическая часть компании с высочайшими требованиями к надежности и доступности. Он обрабатывает миллион запросов в секунду, хранит эксабайты данных и раздает терабит трафика в пике. Под капотом он содержит сотни тысяч hdd в тысячах серверах, размещенных в нескольких ДЦ, и десятки тысяч фоновых процессов, нагружающих железо.

Чтобы все это эффективно работало, необходимо балансировать read- и write-нагрузку между серверами и дисками. Для этого нужно учитывать множество факторов: ломающееся железо (от отдельных дисков до ДЦ целиком), разную "горячесть" данных разных сервисов (от cold до hot), сторонние источники нагрузки в лице фоновых процессов, гетерогенность железа (от 1-гигабитных старых серверов до 50-гигабитных новых) и т.д.

В докладе расскажу, как устроена балансировка read- и write-нагрузки в системе хранения; какие подходы работают, а какие нет; какие трудности могут возникать в процессе эксплуатации и какие особенности есть в multitenancy-хранилищах.

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

Мы хотим рассказать про свой опыт в решении проблем и попробуем ответить на вопросы:
* почему index scan / index only scan могут тормозить при адекватном плане запроса?
* что за странные ожидания LWLock'а SubtransControlLock или ClientRead видны в pg_stat_activity?
* высокая system-time-утилизация CPU в системе процессами PostgreSQL. Кто виноват?

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

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

Проблемы эксплуатации MySQL в облаках.

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

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

В своем докладе я расскажу про наш переход из batch в streaming. Предпосылками для перехода были следующие факты:
* Быстрый учет изменений и событий продуктово важен. В том числе виден на экспериментах в ключевых метриках (отдельные ускорения могут давать до нескольких процентов денег/конверсий).
* Дальнейшее ускорение требовало экспоненциального роста потребляемого CPU (десятки тысяч ядер), либо упиралось в ограничения MapReduce-модели.
* Сложность поддержки большого количества железных машин (~1000 хостов) и самописных систем синхронизации
Сегодня наша контент-система обрабатывает миллионы событий и изменений в секунду, а суммарный размер стейтов со всеми репликами занимает несколько петабайт.

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

Скала^р — это производитель ПАК-ов, которые мы называем Машинами

Одна из наших Машин — МБД.П — это как Oracle Exadata, только про PostgreSQL.
Мы расскажем, как устроена наша Скала МБД.П, как мы пришли к такой конфигурации, каких показателей производительности и надежности удалось добиться.

А ещё Скалой надо управлять не только инженерам высочайшей квалификации, но и пользователям, и мы придумали систему управления для нее — Спектр (не спрашивайте, почему так;-)
Сначала мы хотели делать его как <s>Oracle Enterprise Manager только без глюков и с комьюнити-версией</s>, но потом поняли что архитектура решения не всегда получается с первого раза и без ошибок.

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

В завершение немного расскажем про наш опыт импортозамещения и постараемся заглянуть в будущее.

Мы расскажем, как уже давно пытаемся в Yandex Cloud начать горизонтально масштабировать PostgreSQL.
Stateless Postgres Query Router — новая система для горизонтального масштабирования PostgreSQL через шардирование — роутинг запросов по диапазонам. Система работает по протоколу Postgres, предполагает управление перемещением данных между шардами. Поддерживает работу как в сессионном, так и в транзакционном режиме пуллинга запросов.

Cassandra является основным хранилищем (мета)данных в Одноклассниках. У нас развёрнуты сотни высоконагруженных кластеров из сотен узлов и тысяч клиентов, распределённых по нескольким дата-центрам. Мы используем и активно развиваем собственный форк Cassandra 2.x. Помимо фиксов множества багов и многочисленных оптимизаций, мы реализовали глобальные индексы (которые работают), поддержали партиционированные транзакции (NewSQL), полностью автоматизировали эксплуатацию в production и многое другое. Но в этом докладе мы сконцентрируемся на подходе FatClient, который используется в наших системах повсеместно.

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

В докладе мы подробно рассмотрим собственную реализацию асинхронного транспорта Cassandra, которая позволила нам существенно сэкономить ресурсы и упростить жизнь разработчиков. Новый транспорт основан исключительно на Java SDK и лаконичной, но эффективной реализации Actor Model. Помимо устройства нашего решения, поговорим про различные оптимизации, возникшие по пути проблемы, а также переключение на асинхронный транспорт нагруженных кластеров Cassandra в production.

Мы создали агент и назвали его rdsync по аналогии со своими другими решениями (pgsync — для PostgreSQL, mysync — для MySQL). Пропатчили Redis, чтобы можно было делать failover/switchover безопасно. Обложили это всё множеством функциональных и jepsen-тестов. Сделали отдельный демон, который может повторять протокол sentinel с точки зрения взаимодействия с клиентами (https://redis.io/docs/reference/sentinel-clients/).

В докладе подробнее расскажу, чем не устроил вариант «из коробки», как мы поддерживали обратную совместимость, как тестируем и проверяем, что решение не теряет данные.

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

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

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

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

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

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

Один из ключевых механизмов любой СУБД — это возможность предоставить согласованное состояние данных в базе в виде "снимка" или "снапшота". Этот механизм используется в первую очередь для организации изоляции транзакций: каждая транзакция видит свою версию состояния базы данных. В сочетании с другими механизмами это порождает технологию MVCC, когда транзакции независимо и одновременно видят каждая свое собственное состояние БД и работают в нем. Помимо этого, снимок состояния базы данных (записанный в файл) можно использовать для восстановления после перезапуска, а также для инициализации реплики.

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

В этом докладе я на примере In-Memory-СУБД Tarantool в памяти расскажу, как устроены снимки данных и MVCC, как и почему эволюционировали эти алгоритмы, во что обходится поддержание этих структур пользователю, как правильно использовать и что ожидать от этих механизмов.

База данных в оперативной памяти или in-memory-db — понятие не новое. На сегодняшний день сложилась довольно сильная ассоциация подобных решений со словами «кэш», «неперсистентный» и «ненадёжно».

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

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

Цель моего доклада — показать, что in-memory-технологии уже достаточно зрелые и надёжные, чтобы быть основным хранилищем данных в вашем продукте.

Клиент-серверное взаимодействие высоконагруженных приложений и распределенных баз данных имеет ряд особенностей. Так, необходимо оперативно выяснять и отслеживать изменения топологии кластера базы данных, балансировать запросы по узлам (нодам) этого кластера, корректно обрабатывать возникающие ошибки.
Драйвер распределенной базы данных существенно отличается от драйверов традиционных (нераспределенных) баз данных. Главная отличительная особенность распределенных баз данных - необходимость работать со множеством нод СУБД. Для равномерной нагрузки на ноды БД в YDB используется как клиентская, так и серверная балансировка. Для баз данных, работающих в режиме 24/7 и допускающих различные сценарии отказа, драйвер должен быть готов к ошибкам разного рода. Это влияет на то, каков должен быть драйвер распределенной базы данных. В докладе мы расскажем про наш опыт разработки драйверов для распределеной БД на разных языках, про проблемы, с которыми сталкивались и решали или митигировали, а также про вынесенные уроки и принятые решения.

Многие системы, стараясь описать свое поведение в ненадежной сети, прибегают к терминам CAP-теоремы и описывают себя либо как AP, либо как CP.

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

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

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

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

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

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

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

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

Доклад посвящен особенностям настройки БД и хранимых процедур после успешного перехода с Oracle PL/SQL на Postgres pl/pgSQL, о котором я рассказывал на прошлогодней конференции.

С тех пор накопился опыт лечения детских болезней в области производительности БД, плавно перетекающий в профилактику и лечение хронических заболеваний в этой же области.

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

"Кассандра — прошлый век", — говорили они, — "Переходите на Сциллу". Написана на плюсах, быстрая, надежная, с шардированием из коробки. Как тут удержаться и не попробовать? Тем более в условиях, когда вендоры других популярных баз данных того и гляди закроют поддержку для российских пользователей. Всё-таки хочется иметь под рукой пару-тройку запасных вариантов.

Решились! Нашли время, ресурсы и провели исследование одноглазого монстрика в диких условиях кровавого энтерпрайза. Что из этого вышло — опыт, лайфхаки и выводы о целесообразности использования Сциллы — в моём докладе.

Спойлер: зверушка у нас прижилась :)

В последние годы алгоритмы распределённых транзакций значительно эволюционировали — Spanner, Calvin, Ceasar, Tempo. В докладе я расскажу про ограничения, которые пытаются преодолеть авторы протоколов, и остановлюсь на протоколе Accord, который недавно был предложен в экосистеме Cassandra. Протокол работает без выделенного лидера и позволяет избежать большого числа конфликтов при обновлении "горячих" данных, что делает его пригодным для наиболее высоконагруженных сценариев.