Хранение данных: надежно и надолго

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

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

Особенности архитектуры YDB

СУБД YDB (Yandex Database) относится к классу универсальных распределенных реляционных систем [1]: реляционная модель данных, поддержка ACID-транзакций, язык SQL и пр. Архитектура этой СУБД напоминает сложившуюся многослойную структуру (рис. 1), на принципах которой построены практически все универсальные реляционные СУБД [2]. Отличия могут присутствовать только у нишевых решений (обработка в памяти и пр.).

Рис. 1. Обобщенная архитектура универсальной СУБД

Вместе с тем многие архитектурные решения YDB находятся в русле и NoSQL, и Distributed SQL: работа на кластере серверов, эластичность, балансировка нагрузки, высокая доступность и т. д. На сегодняшний день имеется несколько подобных систем — Spanner, Cockroach, Yugabyte и TiDB, принципиальные отличия которых от классических состоят в следующем: кластер из сотен или тысяч узлов; слой хранения логически отделен от слоя вычислений; записи таблиц шардируются; для каждого шарда хранятся несколько реплик, причем для разных шардов используются разные узлы кластера; применяются различные способы репликации (RAFT, Paxos и т. п.); для обеспечения требований ACID задействованы комбинации протоколов координации транзакций/консенсуса [3].

Кластер YDB может состоять из нескольких тысяч узлов двух типов (узлы хранения и узлы обработки), таблицы автоматически шардируются по первичному ключу, возможны различные варианты избыточного хранения данных и, наконец, для обеспечения ACID используются детерминированные транзакции (рис. 2). В [4] приведены результаты тестирования YDB в сравнении с распределенными и с классическими системами.

Рис. 2. Архитектура YDB

Расхождения конкретных СУБД от традиционной архитектуры (рис. 1) начинаются на уровне реализации, например, MySQL позволяет использовать различные подсистемы хранения данных (InnoDB, MyISAM, XtraDB и пр.), а в Tarantool во главу угла поставлены неблокирующий ввод-вывод и использование кооперативной многозадачности для параллельной обработки данных. СУБД PostgreSQL предоставляет возможности для вставки модулей на различных уровнях (например, организация доступа к внешним хранилищам с помощью postgres_fdw), а облачная СУБД Spanner использует аппаратные часы для глобального упорядочивания транзакций. Главное — в каждой системе принятые архитектурные решения впоследствии могут стать проблемой, мешающей ее дальнейшему развитию, и изменить что-либо будет либо трудно, либо практически невозможно. Яркий пример — возможность параллельного исполнения различных частей одного и того же SQL-запроса. Во-первых, различные этапы физического плана исполнения запроса могут работать параллельно и необходима их синхронизация (вплоть до того, что появляются новые типы физических элементов); во‑вторых, может требоваться межпотоковый (или даже межпроцессный) обмен данными; во‑третьих, планировщик запросов должен учитывать появившиеся возможности для параллельной обработки.

Ключевые требования к архитектуре YDB — распределенность и возможность горизонтального масштабирования. Для этого СУБД построена на основе акторной модели [5], а базы представляются в виде множества акторов-таблеток, что сделало крайне простым и штатным разрешение многих критических ситуаций, характерных для распределенных СУБД (см. Таблицу).

Надежность хранения

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

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

В свою очередь, способ избыточного хранения данных тесно связан с топологией кластера, задаваемой на этапе развертывания системы. Используются понятия области отказа (например, ЦОДа) и доменов отказа (например, серверных стоек). Таким образом, образуется иерархия: область отказа состоит из доменов отказа, домены отказов состоят из серверов, а каждый сервер имеет несколько носителей данных. Поддерживаются три варианта развертывания.

1. Зеркалирование. Несколько полных копий данных хранятся на узлах, расположенных в разных областях и доменах отказа.
2. Избыточность по схеме стирающего кода. В разных областях и доменах отказа хранятся части исходных данных и дополнительная информация (коды избыточности), позволяющая восстановить полную копию данных.
3. Без избыточного хранения. На уровне распределенного хранилища копий данных не создается, но при этом надежность может обеспечиваться за счет асинхронной репликации.

Система распределенного хранения в некотором смысле повторяет логику RAID, однако имеются принципиальные отличия. Во-первых, серверы и диски разносятся по разным ЦОДам. Во-вторых, для оптимизации скорости работы учитываются особенности работы носителей данных (HDD/SSD и т. п.). Наконец, работа таблетки со своими данными осуществляется не поблочно (в терминах физического носителя), а с более высокоуровневыми структурами (специализированное хранилище «ключ-значение», в котором значения — это бинарные объекты размером до 12 Мбайт), что позволяет оптимизировать работу с данными и их размещение на реальном физическом носителе. Кроме увеличения скорости выполнения операций ввода-вывода такой подход повышает устойчивость к сбоям физических носителей данных.

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

Для не критичных применений возможно использование средств асинхронной репликации на логическом уровне представления данных. Этот механизм основан на средствах захвата изменений (change data capture):

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

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

Дополнительно к средствам репликации имеются инструменты создания и восстановления резервной копии, которая может создаваться как для метаданных кластера (всегда сохраняются в файловой системе), так и для самих данных (копия сохраняется на файловой системе или в S3-совместимом хранилище). Таким образом можно хранить необходимое количество резервных копий базы данных.

Защита

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

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

• Идентификация и аутентификация пользователей. Возможны разные подходы: по логину и паролю, с использованием LDAP или стороннего IAM-провайдера. Вся аутентификационная информация (например, имена пользователей и пароли) хранится в защищенном формате, есть строгие требования на параметры паролей, наконец, осуществляется блокировка пользователей при попытке подбора их паролей.
• Администрирование и ролевое управление доступом. С СУБД взаимодействуют пользователи, выполняющие разные роли: администратор СУБД, администраторы базы данных и непосредственно пользователи. Роль администратора СУБД позволяет выполнять общие действия над кластером и создавать администраторов баз данных. В свою очередь, роль администратора базы позволяет выполнять общие действия над конкретной базой, в том числе управлять доступом пользователей к ее содержимому. Наконец, роль пользователя позволяет работать с объектами конкретной базы данных, при этом традиционное понятие ролей пользователей расширено до понятия групп доступа, которые могут входить друг в друга, образуя сложную иерархию, что позволяет более эффективно управлять правами большого числа пользователей.
• Объекты доступа. Важным отличием YDB является не двухуровневая (схема базы данных — объект базы), а иерархическая организация объектов доступа, состоящая из каталогов и подкаталогов, в которых располагаются объекты базы данных. Каждый подкаталог — это полноценный объект доступа, для которого также могут быть настроены права доступа.
• Аудитное логирование. Система отслеживает и заносит в журнал событий все действия пользователей, связанные с информационной безопасностью, и дополнительно оповещает администратора.
• Контроль целостности. Конфигурация СУБД подписывается с помощью ЭЦП средствами защищенной ОС (СУБД сертифицируется на определенный уровень с учетом работы на конкретной ОС), на которой установлена СУБД. При ее запуске происходит проверка ЭЦП, и если она завершается ошибкой, то СУБД будет доступна только администратору. При работе администратора с узлом (запуск, останов, перенастройка и т. д.) он не может самостоятельно получить доступа к содержимому базы, что минимизирует потенциальный ущерб в случае его компрометации.
• Гарантированное удаление данных. Для хранения содержимого базы данных YDB не использует файловую систему, а напрямую работает с блочным устройством. Если некоторая информация удаляется из базы данных, то в соответствующие ей области блочного устройства записываются специальные битовые последовательности. Таким образом, даже имея доступ к блочному устройству практически невозможно восстановить содержимое базы.

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

• при взаимодействии пользовательского приложения с СУБД;
• при взаимодействии администратора с системой с помощью встроенного веб-интерфейса;
• при обращении системы к внешним системам (например, выполнении федеративных запросов или асинхронной репликации);
• при взаимодействии узлов кластера между собой;
• при сохранении информации на физических носителях.

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

***

Сегодня YDB — это зрелая отечественная СУБД, применяемая для построения надежных высокодоступных масштабируемых решений. Широкий спектр функциональных возможностей и наличие сертификата ФСТЭК подтверждают готовность к использованию этой СУБД в инфраструктурах самого различного назначения. Такие возможности достигнуты не за счет переработки ранее существовавших решений, а благодаря проектированию и созданию системы «с нуля», позволившему заложить многие свойства СУБД на «генетическом уровне». Кроме того, акторная модель и возможность «перетасовки» таблеток по разным узлам обеспечивают поддержку перспективного развития информационной инфраструктуры, позволяя, например, выполнять масштабирование за счет перераспределения таблеток.

Литература

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

2. Эволюция архитектуры баз данных. URL: https://habr.com/ru/companies/oleg-bunin/articles/950454 (дата обращения: 21.06.2026).

3. Calvin: обеспечение принципов ACID для высоконагруженных распределенных систем. URL: https://habr.com/ru/articles/577300/ (дата обращения: 21.06.2026).

4. Сравнение производительности YDB, CockroachDB и YugabyteDB на бенчмарке YCSB. URL: https://habr.com/ru/companies/ydb/articles/740560/ (дата обращения: 21.06.2026).

5. Архитектурный обзор YDB. URL: https://ydb.tech/docs/ru/concepts/architecture?version=v25.2 (дата обращения: 22.06.2026).

Александр Зевайкин (azevaykin@yandex-team.ru) — руководитель группы разработки строковых таблиц, Константин Селезнев (kseleznyov@yandex-team.ru) — разработчик, «Яндекс» (Россия).