Источник
Wikipedia: YDB
История YDB (KiWi/KiKiMR -> YDB), ключевые релизные вехи и общая архитектурная рамка.
Официальная документация
YDB Docs: Architecture
Обзор архитектуры: shared-nothing, tablets, auto-sharding, distributed transactions и storage слой.
YDB (Yet another DataBase) - распределённая SQL СУБД с ACID-транзакциями, автошардированием и shared-nothing архитектурой. В системном дизайне YDB часто выбирают для high-load backend-сервисов, где важны строгая консистентность, масштабирование по ключам и единая платформа для операционных и аналитических задач.
История и контекст
Начало разработки во внутренней инфраструктуре Yandex
В Yandex начинается проект распределённого key-value слоя KiWi как основа для масштабируемых сервисов.
Переход к distributed SQL архитектуре
Развивается архитектура KiKiMR с tablets и actor-моделью, которая позже ляжет в основу YDB.
Широкое продакшен-использование в Yandex
YDB-класс архитектуры применяется для высоконагруженных сервисов внутри экосистемы Yandex.
Публичный open-source релиз
YDB выходит в open source как distributed SQL база данных с ACID-транзакциями и автошардированием.
Стабилизация серверной ветки 24.3
Ветка 24.3 получает релизы с исправлениями и улучшениями стабильности для production-кластеров.
Новая минорная линейка 25.x
Развитие ветки 25.x с улучшениями SQL-функциональности, производительности и операционных сценариев.
Ключевые архитектурные элементы
Tablets и auto-sharding
Данные таблиц распределяются по shard-ам (tablets), которые автоматически делятся/перемещаются при росте нагрузки.
Serializable транзакции
YDB даёт ACID-транзакции с serializable изоляцией и optimistic concurrency control для конкурентных операций.
Row + Column таблицы
В одной платформе доступны row-oriented и column-oriented таблицы для OLTP и аналитических workload профилей.
Disaggregated compute/storage
Архитектура поддерживает разделение слоёв compute и storage, а также multi-AZ отказоустойчивые кластеры.
Модель данных и транзакционный контур
Интерактивный блок показывает, как в YDB сочетаются row/column таблицы, автошардирование, индексы и distributed transactions в общей архитектуре.
Модель данных YDB: таблицы, шарды и транзакции
YDB совмещает реляционную модель с автоматическим шардированием и распределёнными транзакциями для high-load сценариев.
Почему YDB — это не просто очередная SQL СУБД
- Каждая таблица обязана иметь primary key; данные физически распределяются по shard-ам (tablets).
- Есть row-ориентированные и column-ориентированные таблицы для OLTP/OLAP профилей.
- Поддерживаются distributed transactions с serializable изоляцией и OCC-механикой.
- Встроенные topics/CDC/async replication позволяют строить data pipeline без внешних брокеров в некоторых сценариях.
Row-oriented tables
Базовый тип для транзакционных нагрузок: primary key обязателен, таблица сортируется по ключу.
Ключевые элементы
Типичные сценарии
- User/account state
- Orders/payments
- Transactional APIs
Пример
CREATE TABLE orders (
tenant_id Uint64,
order_id Uint64,
status Utf8,
amount Uint64,
PRIMARY KEY (tenant_id, order_id)
);High-Level Architecture
Ниже high-level контур YDB: клиентский доступ, SQL/transaction слой, tablets/shards, распределённое storage и механики отказоустойчивости.
System view
Data model
Operational trade-offs
Read / Write Path через компоненты
Диаграмма объединяет write/read path и показывает маршрут транзакций/запросов через discovery, tx-coordinator, shards и storage репликацию.
Read/Write Path Explorer
Интерактивный разбор прохождения транзакций и запросов через ключевые компоненты YDB-кластера.
Write path
- Ключ первичного индекса определяет, попадет ли операция в один shard или потребует distributed transaction.
- YDB использует serializable изоляцию и optimistic concurrency control; конфликтующие транзакции могут завершаться retry-ошибкой.
- Cross-shard write обычно дороже по latency/ресурсам, чем одношардовая запись.
- DDL и DML не комбинируются в одной транзакции — schema changes выполняются отдельно и идемпотентно.
Когда выбирать YDB
Хорошо подходит
- High-load транзакционные сервисы с требованием strong consistency и auto-sharding.
- Сценарии с ростом данных/нагрузки, где важна горизонтальная масштабируемость shared-nothing кластера.
- Системы, где нужны и OLTP таблицы, и близкая аналитика на column-oriented таблицах.
- Команды, готовые инвестировать в ключевой дизайн и операционную эксплуатацию distributed SQL платформы.
Стоит избегать
- Небольшие single-node проекты, где проще локальная БД без распределённой сложности.
- Нагрузки с очень частыми cross-shard транзакциями без продуманного partitioning по ключам.
- Сценарии, где нужна минимальная operational сложность и нет ресурсов на сопровождение кластера.
- Use cases, где доминирует полнотекстовый поиск или pure OLAP без транзакционного контура.
Практика: DDL и DML
Ниже примеры DDL и DML для YDB: проектирование схемы и индексов, транзакционные upsert/update и селекты по ключевым диапазонам.
Примеры DDL и DML в YDB
DDL задаёт схему и партиционирование, DML работает с транзакциями и массовыми upsert/select запросами.
В YDB DDL-операции (таблицы, индексы, партиционирование) выполняются отдельно от DML-транзакций и должны быть идемпотентными.
Создание row-таблицы с автопартиционированием
CREATE TABLEPrimary key обязателен; настройка auto-partitioning помогает масштабироваться при росте нагрузки.
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
);Добавление глобального secondary index
ALTER TABLE ... ADD INDEXИндекс улучшает доступ по не-ключевым полям, но добавляет write overhead.
ALTER TABLE orders
ADD INDEX idx_status GLOBAL ASYNC ON (status);Создание column-таблицы для аналитики
CREATE TABLE ... STORE=COLUMNДля OLAP-сценариев используем column store и hash partitioning.
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);