YDB интересна не только происхождением внутри Yandex, а тем, как распределённый SQL соединяется с платформенным взглядом на мультиарендность, масштабирование и эксплуатацию.
В реальных проектных решениях эта глава помогает думать об изоляции арендаторов, квотах, границах транзакций и пакетной записи как о свойствах всей платформы, а не как о локальных оптимизациях одной команды.
На интервью и в архитектурных обсуждениях она особенно полезна там, где нужно объяснить выбор YDB через отказоустойчивость, управление шумными соседями по ресурсу и предсказуемость на масштабе.
Практическая польза главы
Границы мультитенантности
Проектируйте изоляцию арендаторов и квоты так, чтобы шумный сосед не ломал общий уровень сервиса платформы.
Транзакционные контуры
Определяйте границы транзакций и пакетную запись под особенности распределённого SQL-исполнения.
Эластичность хранения и вычислений
Связывайте стратегию масштабирования с профилем нагрузки и ожидаемыми пиками трафика.
Обоснование решения
Обосновывайте выбор YDB через требования к отказоустойчивости, управлению арендаторами и операционной предсказуемости.
Источник
Wikipedia: YDB
История YDB от KiWi и KiKiMR до публичной СУБД, ключевые релизные вехи и общая архитектурная рамка.
Официальная документация
YDB Docs: Architecture
Обзор архитектуры: отсутствие общего состояния, таблетки YDB, автоматическое шардирование, распределённые транзакции и слой хранения.
YDB (Yet another DataBase) — распределённая SQL-СУБД с транзакционными гарантиями, автоматическим шардированием и архитектурой без общего состояния. В системном дизайне YDB часто выбирают для высоконагруженных backend-сервисов, где важны строгая консистентность, масштабирование по ключам и единая платформа для операционных и аналитических задач.
В этой главе под понимаем SQL-интерфейс поверх шардирования, репликации и транзакционной координации. YDB добавляет , и , чтобы приложение не управляло каждым разбиением данных вручную.
Практический смысл проявляется в деталях: , сериализуемость, и определяют, будет ли нагрузка локальной и предсказуемой или начнёт платить ценой межшардовой координации.
История и контекст
Начало разработки во внутренней инфраструктуре Yandex
В Yandex начинается проект распределённого слоя «ключ-значение» KiWi как основа для масштабируемых сервисов.
Переход к распределённой SQL-архитектуре
Развивается архитектура KiKiMR с таблетками YDB и акторной моделью, которая позже ляжет в основу YDB.
Широкое использование в продуктивных сервисах Yandex
YDB-класс архитектуры применяется для высоконагруженных сервисов внутри экосистемы Yandex.
Публичный релиз с открытым исходным кодом
YDB становится доступной как распределённая SQL-СУБД с транзакционными гарантиями и автоматическим шардированием.
Стабилизация серверной ветки 24.3
Ветка 24.3 получает релизы с исправлениями и улучшениями стабильности для продуктивных кластеров.
Новая минорная линейка 25.x
Развитие ветки 25.x с улучшениями SQL-функциональности, производительности и операционных сценариев.
Ключевые архитектурные элементы
Таблетки и автоматическое шардирование
Данные таблиц распределяются по таблеткам YDB, которые автоматически делятся и перемещаются при росте нагрузки.
Сериализуемые транзакции
YDB даёт транзакции с сериализуемой изоляцией и оптимистичной конкурентной записью для конкурирующих операций.
Строковые и колоночные таблицы
В одной платформе доступны строковые таблицы для транзакционного контура и колоночные таблицы для аналитики.
Разделение вычислений и хранения
Архитектура разделяет вычислительный слой и хранение, а также поддерживает отказоустойчивые кластеры в нескольких зонах.
Модель данных и транзакционный контур
Интерактивный блок показывает, как в YDB сочетаются строковые и колоночные таблицы, автоматическое шардирование, индексы и распределённые транзакции в общей архитектуре.
Модель данных YDB: таблицы, таблетки и транзакции
YDB совмещает реляционную модель с автоматическим шардированием и распределёнными транзакциями для растущих сервисов.
Почему YDB — это не просто ещё одна SQL-СУБД
- Каждая таблица обязана иметь первичный ключ; данные физически распределяются по таблеткам YDB.
- Есть строковые таблицы для транзакционной обработки и колоночные таблицы для аналитики.
- Поддерживаются распределённые транзакции с сериализуемой изоляцией и оптимистичной конкурентной записью.
- Топики, CDC и асинхронная репликация помогают строить конвейеры данных без внешних брокеров в части сценариев.
Строковые таблицы
Базовый тип для транзакционных нагрузок: первичный ключ обязателен, таблица сортируется по ключу.
Ключевые элементы
Типичные сценарии
- Состояние пользователей
- Заказы и платежи
- Транзакционные API
Пример
CREATE TABLE orders (
tenant_id Uint64,
order_id Uint64,
status Utf8,
amount Uint64,
PRIMARY KEY (tenant_id, order_id)
);Архитектура YDB по слоям
Ниже показан слой клиентского доступа, SQL и транзакций, таблетки и шарды, распределённое хранение и механики отказоустойчивости.
Системный взгляд
Модель данных
Операционная цена
Пути чтения и записи через компоненты
Диаграмма объединяет путь записи и путь чтения: от поиска ответственных таблеток и координатора транзакции до шардов и реплицированного хранения.
Пути чтения и записи
Интерактивный разбор прохождения транзакций и запросов через ключевые компоненты YDB-кластера.
Путь записи
- Первичный ключ определяет, попадёт ли операция в один шард или потребует распределённой транзакции.
- YDB использует сериализуемую изоляцию и оптимистичную конкурентную запись; конфликтующие транзакции могут требовать повтора.
- Межшардовая запись обычно дороже по задержке и ресурсам, чем одношардовая запись.
- DDL и DML не комбинируются в одной транзакции: изменения схемы выполняются отдельно и идемпотентно.
Когда выбирать YDB
Хорошо подходит
- Высоконагруженные транзакционные сервисы, где нужны строгая консистентность и автоматическое шардирование.
- Сценарии с ростом данных и нагрузки, где важна горизонтальная масштабируемость архитектуры без общего состояния.
- Системы, где рядом нужны транзакционный контур и аналитика на колоночных таблицах.
- Команды, готовые инвестировать в проектирование ключей и эксплуатацию распределённой SQL-платформы.
Стоит избегать
- Небольшие проекты на одном узле, где проще локальная БД без распределённой сложности.
- Нагрузки с очень частыми межшардовыми транзакциями без продуманного разбиения по ключам.
- Сценарии, где нужна минимальная операционная сложность и нет ресурсов на сопровождение кластера.
- Сценарии, где доминирует полнотекстовый поиск или чистая аналитика без транзакционного контура.
Практика: DDL и DML
Ниже примеры DDL и DML для YDB: проектирование схемы и индексов, транзакционные операции UPSERT/UPDATE и выборки по ключевым диапазонам.
Примеры DDL и DML в YDB
DDL задаёт схему и партиционирование, DML работает с транзакциями, записью и запросами чтения.
В YDB DDL-операции с таблицами, индексами и партиционированием выполняются отдельно от DML-транзакций и должны быть идемпотентными.
Создание строковой таблицы с автопартиционированием
CREATE TABLEПервичный ключ обязателен; автоматическое партиционирование помогает масштабироваться при росте нагрузки.
CREATE TABLE orders (
tenant_id Uint64,
order_id Uint64,
status Utf8,
amount Uint64,
created_at Timestamp,
PRIMARY KEY (tenant_id, order_id)
)
WITH (
AUTO_PARTITIONING_BY_SIZE = ENABLED,
AUTO_PARTITIONING_MIN_PARTITIONS_COUNT = 8
);Добавление глобального вторичного индекса
ALTER TABLE ... ADD INDEXИндекс улучшает доступ по неключевым полям, но увеличивает стоимость записи.
ALTER TABLE orders
ADD INDEX idx_status GLOBAL ASYNC ON (status);Создание колоночной таблицы для аналитики
CREATE TABLE ... STORE=COLUMNДля OLAP-сценариев используем колоночное хранение и хеш-партиционирование.
CREATE TABLE events_olap (
ts Timestamp NOT NULL,
tenant_id Uint64 NOT NULL,
event_type Utf8,
payload Json,
PRIMARY KEY (ts, tenant_id)
)
PARTITION BY HASH(tenant_id)
WITH (STORE = COLUMN);Связанные главы
- Фреймворк выбора СУБД - Как выбрать распределённый SQL-подход и оценить, когда YDB лучше подходит по консистентности, масштабированию и стоимости эксплуатации.
- PostgreSQL: история и архитектура - Сравнение классического транзакционного подхода с основным узлом и репликами с распределённым SQL-контуром YDB.
- Cassandra: архитектура и компромиссы - Сопоставление распределённого SQL и AP-ориентированной NoSQL-модели по консистентности и форме запросов.
- Распределённые транзакции: 2PC и 3PC - Контекст координации транзакций и компромиссов между задержкой и доступностью в распределённых сценариях записи.
- ClickHouse: аналитическая СУБД и архитектура - Граница между транзакционным и аналитическим слоями: когда контур YDB дополняется отдельной аналитической системой.
- CockroachDB: распределённая SQL-СУБД и архитектура - Сравнение двух распределённых SQL-платформ по межрегиональному поведению, транзакционным гарантиям и операционному профилю.