Как открытый исходный код меняет современные СУБД

Несмотря на то, что YDB как технологии уже почти десять лет, это все еще довольно молодой возраст для СУБД — отказоустойчивые и масштабируемые системы такого класса называются NewSQL, «новым» SQL. В начале 2000-х годов в индустрии начало распространяться осознание того, что системы, работающие на одном, даже самом дорогом сервере, ненадежны и сильно ограничены в вычислительных ресурсах. Однако при изначальном проектировании распространенных сегодня СУБД вроде MySQL, PostgreSQL и их предшественников кластерный режим работы отсутствовал и соответствующие возможности повышения надежности стали позже добавляться посредством различных расширений, форков и прочих ухищрений «сбоку». У YDB путь проектирования изначально начался с учетом масштабных надежных инсталляций, что позволило этой СУБД быстро занять одну из ключевых ролей во внутренней инфраструктуре «Яндекса» в транзакционных сценариях использования. Затем YDB доросла до публичного управляемого сервиса в Yandex Cloud, позже обзавелась бессерверным (serverless) режимом работы [1]. Сегодня СУБД YDB переживает следующий этап развития — выход в Open Source и адаптация к новым реалиям.

Почему вообще Open Source?

Если следить за рынком СУБД, да и более широким рынком программного обеспечения в целом, то легко заметить, насколько огромный вклад в скорость развития индустрии делает именно культура открытого исходного кода. Сегодня сложно найти компанию, которая делает какой-либо программный продукт без использования компонентов с открытым исходным кодом: в качестве операционной системы в промышленных условиях стандартом де-факто является Linux, миры машинного обучения и фронтенда завоевали открытые фреймворки вроде TensorFlow и React, а компилятор или интерпретатор вашего любимого языка программирования тоже, почти наверняка, открытый.

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

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

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

Экосистемность

Как и в любой большой компании, внутри «Яндекса» множество внутренних инструментов и сервисов, но их ассортимент относительно стабилен и стандартизован — на ранних этапах развития YDB важно было вписываться именно в этот ландшафт. При первом выходе на публику в составе Yandex Cloud сразу появился новый ассортимент соседних облачных сервисов, с которыми необходимо интегрироваться, обеспечивая для коммерческих пользователей легкие и прозрачные сценарии взаимодействия с необходимым им подмножеством сервисов. Инкарнация YDB в виде программного обеспечения с открытым исходным кодом, а не сервиса продолжает эту тенденцию, но на этот раз границы вовсе отсутствуют — пользователи могут использовать продукт в любом, совершенно непредсказуемом окружении.

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

Похожую связующую роль играет и так называемый механизм Change Data Capture (CDC) — предоставление потока сообщений об изменениях внутри базы данных в поддерживаемые системы передачи. Их можно использовать как в сценариях, когда в компании используется несколько систем хранения и обработки данных и есть необходимость в частичной или полной синхронизации, так и просто для потребления в других компонентах системы, например, если используется микросервисная архитектура. Эта функциональность уже доступна в стабильных релизах YDB, предназначенных для использования в производственном окружении.

Также важными аспектами выхода в Open Source являются веб-интерфейс и инструменты для эксплуатации кластера. Если в облачном сценарии использования в распоряжении пользователя всегда есть продвинутая веб-консоль всего Yandex Cloud, а эксплуатация и вовсе делегируется команде управляемого сервиса, то в мире самостоятельно эксплуатируемого программного обеспечения это одна из наиболее востребованных тем.

В контексте предоставляемых инструментов эксплуатации план развития возник естественным образом благодаря обилию устоявшихся лидирующих открытых инструментов и стандартов. В частности, если вы используете Kuberentes, то с помощью YDB Kubernetes Operator можно как сделать изначальное развертывание кластера, так и автоматизировать рутинные операции в процессе его дальнейшей работы. Логи YDB по умолчанию пишутся в journald, а метрики предоставляются в формате Prometheus. Также есть преднастроенные дашборды для Grafana (рис. 1).

Рис. 1. Преднастроенный дашборд YDB в Grafana

Развертывание YDB в Kubernetes заслуживает особого внимания. Исторически Kubernetes получил репутацию решения, специализирующегося на оркестрации выполнения контейнеризированных приложений, не обладающих состоянием (stateless), таких как веб-серверы, микросервисы и пр. Но у систем управления базами данных, по определению, сами пользовательские данные являются состоянием, из-за чего в индустрии сложился стереотип, что им в Kubernetes не место, и многие компании до сих пор даже если внедрили Kubernetes, но держат все базы данных «сбоку» на виртуальных машинах или физических серверах. Тем временем сейчас у любой серьезной СУБД есть свой Kubernetes-оператор, а то и несколько, и для новых проектов зачастую рекомендуется использовать именно их. В случае YDB оператор берет на себя основные аспекты правильной конфигурации кластера — начиная от различных режимов работы дисковой подсистемы в различных сценариях и заканчивая настройкой шифрования для обеспечения безопасности. Если ЦОД или зона доступности только одна, то обычно дисковая подсистема YDB настраивается в режиме erasure coding (стирающий код — способ восстановления данных в случае их потери) с избыточностью всего 50%, а для инсталляций кросс-ЦОД — честной репликации между тремя площадками. В обоих случаях обеспечивается модель «как только сломавшийся сервер возвращается в строй, то допустимо сразу же сломаться другому» — это обеспечивается благодаря так называемым дискам hand-off, которые автоматически подхватывают поток записываемых данных на время отказа в других частях системы. На обратной стороне медали этого механизма более высокое минимальное количество дисков в отказоустойчивом кластере YDB по сравнению с другими СУБД, которые не обеспечивают такого уровня защиты от сбоев.

Рис. 2. Встроенный веб-интерфейс YDB

Вместо облачной веб-консоли в Open Source YDB есть встроенный прямо в серверный процесс веб-интерфейс (рис. 2). Помимо привычных функций вроде навигации и исполнения SQL-запросов, в нем также присутствует набор инструментов диагностики. Часть из них предназначены для начинающих пользователей, у которых пока нет своей развитой инфраструктуры мониторинга для интеграции, а остальные — для продвинутых пользователей, детально разобравшихся в том, как устроена YDB и что происходит «под капотом».

Расширение сценариев использования

Еще до первого промышленного внедрения YDB в Яндексе, огромных усилий разработчиков потребовало обеспечение фундаментальных свойств СУБД — максимально строгого уровня консистентности, отказоустойчивости даже в случае одновременного сбоя ЦОДа целиком или зоны доступности плюс еще одной серверной стойки (при наличии девяти серверов в трех ЦОДах в разных стойках), а также возможности прозрачного автоматического подключения дополнительного оборудования при необходимости расширения кластера. Несмотря на то, что целевой сценарий использования в виде OLTP и транзакционной работы с наборами данных, состоящих как из одной, так и нескольких логических таблиц, всегда оставался основным фокусом команды разработчиков YDB, стало понятно, что такой фундамент полезен и при других паттернах запросов к базе данных и в других видах инфраструктурных компонентов. Как следствие, вокруг YDB возникло множество различных проектов, что со временем превратило ее скорее в инфраструктурную платформу, чем только СУБД, но далее внимание будет уделяться только наиболее актуальным в контексте использования в Open Source — аналитическим возможностям и очередям сообщений.

Главный антагонист транзакционных СУБД — аналитические СУБД (OLAP), отличающиеся физическим расположением данных на дисковой подсистеме и в памяти серверов: транзакционные, как правило, стараются строки держать рядом, т. е. значения разных колонок одной строки находятся рядом, а аналитические, наоборот, рядом хранят значения одной и той же колонки для большого числа строк. Одну и ту же логическую таблицу человек может просматривать построчно слева направо (транзакционно) или сверху вниз колонка за колонкой (аналитически). Транзакционным СУБД проще работать с запросами, затрагивающими немного строк и сколько угодно столбцов, а аналитическим — наоборот, затрагивающими немного столбцов и сколько угодно строк. «Проще» в данном контексте выливается в минимальные задержки при выполнении запросов, пропускную способность и, в конечном счете, себестоимость выделенных под СУБД ресурсов.

Так как к одной и той же логической таблице часто применяются и транзакционные, и аналитические запросы, а подходы OLTP и OLAP принципиально отличаются на базовом физическом уровне, частым архитектурным решением является использование нескольких разных систем для хранения копий одной и той же таблицы. Обычно это аналитическая и транзакционная СУБД, но может быть и что-то еще, например, третью копию можно на всякий случай складывать просто в файлы в облачном объектном хранилище или на внешнюю систему хранения данных на дисковых массивах. Чтобы все это скрестить, потребуется очередь персистентных сообщений или ETL-решение (Extract-Transform-Load). У всего используемого в таких конструкциях программного обеспечения практически наверняка будут разные производители, которые с разной степенью успеха поддержали друг друга. В результате для изначального ввода в эксплуатацию и дальнейшей поддержки придется решать, что более финансово оправданно — нанимать свою команду или пользоваться услугами системных интеграторов.

Выход YDB в Open Source подтолкнул разработчиков заняться поддержкой и OLTP, и OLAP в одной системе. На имеющемся фундаменте СУБД можно хранить таблицы и в стиле OLAP, что позволяет в одной системе совмещать оба вида запросов c единым SQL-синтаксисом, SDK, инструментами эксплуатации и пр. Эта функциональность уже имеет первые тестовые реализации.

Следующий логичный шаг развития — автоматическая и прозрачная синхронизация обоих физических форматов хранения, о которой заботится СУБД, а не пользователь. Оптимизатору запросов надо будет затем учиться самому выбирать, каким из физических представлений выгодней пользоваться для выполнения конкретного SQL-запроса. Такие системы называют Hybrid Transactional/Analytical Processing (HTAP) — очень модная сегодня аббревиатура, однако ни одну из имеющихся сейчас на рынке промышленных СУБД, декларирующих себя как HTAP, сложно назвать полноценным решением проблемы OLTP-OLAP. В YDB также пока полностью не реализованы все необходимые для этого «строительные блоки», но направление выглядит крайне перспективным как с точки зрения долгосрочного развития целевой аудитории технологии, так и потенциальных сценариев использования.

Быстрее, выше, сильнее

Помимо функционального развития, выход на рынок самостоятельно эксплуатируемых СУБД означает и появление новых конкурентов. В той же нише Distributed SQL, распределенных отказоустойчивых СУБД c поддержкой SQL, работают два стартапа, также публикующих свой исходный код: CockroachDB и YugabyteDB. Однако среди этих трех систем лишь YDB на 100% распространяется под максимально свободной лицензией Apache 2.0. Тем не менее наличие конкурентов подтолкнуло разработчиков YDB заняться вопросами производительности выполнения запросов и сравнительным тестированием. Подробное сравнение этих СУБД на одном из распространенных в индустрии бенчмарков YCSB (Yahoo! Cloud Serving Benchmark) приведено в работе [2], а краткие результаты тестирования представлены на рис. 3. Во многих сценариях системы показали себя сопоставимо, но нашлись и сценарии, где YDB лидирует на порядки по пропускной способности и времени выполнения запросов, в частности, когда среди потока запросов преобладает чтение.

Рис. 3. Сравнение распределенных Open Source СУБД на бенчмарке YCSB

За хорошими результатами бенчмарков почти никогда не стоит одна единственная оптимизация, исполняющая роль «серебряной пули». Работа над производительностью — неотъемлемая часть работы команды разработки, наравне со стабильностью, безопасностью, корректностью и прочими базовыми свойствами любого программного продукта. В компаниях наподобие «Яндекса», постоянно работающих над решением разнообразных задач миллионов пользователей, внимание к производительности среди основных приоритетов — никто не любит пользоваться медленными сервисами.

С момента выхода YDB в Open Source был существенно переработан и оптимизирован слой выполнения запросов, что ускорило запись на 60% и чтение до 10%; внедрен новый слой оркестрации выполнения запросов, что дало еще 20%; улучшены форматы передачи записи между стадиями выполнения запросов — на 15% повысилась пропускная способность; появилась возможность кэшировать графы вычисления запросов, чтобы не тратить вычислительные ресурсы на их повторное построение — экономия до 17%; покрыто больше сценариев применения предикатов максимально близко к физическому хранению данных.

Не только исходный код

Как известно, опубликовать код и забыть — неправильный способ реализации проектов с открытым исходом, всю пользу от которых можно получить, только адаптировав под новые реалии все связанные с этим кодом бизнес-процессы. С сообществом пользователей и контрибьюторов YDB взаимодействие сложилось естественным образом благодаря проекту Yandex Cloud и многочисленной когорте бывших сотрудников «Яндекса». Однако с перестройкой процессов разработки оказалось сложнее — исторически команда разработчиков была сильно завязана на внутренние инструменты и подходы «Яндекса»: системы управления кодом и задачами, сборки, тестирования, релизов и пр. Найти достойные замены вовне оказалось не просто, но если посмотреть на происходящее в ветке GitHub, можно заметить, что сейчас происходят активное строительство и развитие инфраструктуры для разработки полностью в открытом поле.

Стирая барьеры

До выхода СУБД YDB в Open Source можно было встретить скептические настроения из-за доступности технологии только в одном регионе у одного провайдера облаков — vendor lock-in, отсутствия у пользователей возможности сменить поставщика услуг, если что-то пойдет не так, или приобрести аналогичный сервис в другом регионе, если компания решит расширяться. Подобные опасения — существенный ограничивающий фактор для расширения бизнеса из-за рисков, который, однако, мгновенно исчезает в день объявления о выходе продукта в Open Source. Кроме этого доступность исходного кода устраняет лишние вопросы регуляторов и аудиторов.

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

***

Сложно найти аспекты работы любой СУБД, которые бы не поменялись при появлении модели распространения Open Source. На самом деле они, конечно, есть. Например, YDB Query Language — SQL-диалект для работы с СУБД остался прежним, ровно как и спецификации сетевого gRPC API и клиентские SDK — ведь нужно обеспечивать совместимость самих с собой, чтобы приложения могли одинаково работать с СУБД YDB вне зависимости от того, самостоятельно ли пользователь решил заниматься эксплуатацией или поручил это команде управляемого сервиса. Но с точки зрения развития продукта и активности взаимодействия с разработчиками публичный релиз исходного кода определенно вывел проект СУБД YDB на совершенно новый уровень.

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

Литература

1. Андрей Фомичев, Олег Бондарь. Бессерверная альтернатива традиционным базам данных // Открытые системы.СУБД. — 2021. — № 1. — С.20–23. URL: osp.ru/os/2021/01/13055826 (дата обращения: 21.06.2023).

2. Евгений Иванов. YCSB performance series: YDB, CockroachDB, and YugabyteDB // Блог YDB — 2023. — URL: https://habr.com/ru/articles/740560/ (дата обращения: 21.06.2023).

Олег Бондарь (oleg@ydb.tech) – директор по продукту YDB, Иван Блинков (ivan@ydb.tech) – руководитель продуктового направления Open Source YDB, «Яндекс» (Россия).