YDB: tablets, distributed transactions, and failure-domain-aware storage

YDB partitions row-oriented tables by primary-key ranges into DataShard tablets. Tablets are persistent actors whose state is stored in distributed storage and can restart on another dynamic node. A multi-tablet transaction is a real distributed transaction; it is not made non-atomic merely because several shards participate.

Compute/tablet placement and distributed-storage redundancy are separate layers. block-4-2 is a single-data-center erasure-coded mode with rack requirements; mirror-3-dc is the multi-data-center mode. Stretching one block-4-2 group over three data centers contradicts the documented failure model.

Модель и предпосылки

• Client queries enter the query service, resolve tablet leaders, and coordinate every affected DataShard.
• A tablet changes persistent state through its storage channels; distributed storage survives node/disk failures under the selected topology.
• Automatic range splitting and movement respond to size/load, but key design and workload measurement still determine hotspot behavior.

Проверяемые утверждения

• C1. YDB supports distributed transactions across table shards and topics; multi-shard work uses more resources and time than single-shard work.
• C2. A DataShard is a tablet responsible for a continuous primary-key range; tablet state persists in distributed storage and can restart on another node.
• C3. block-4-2 is documented for one data center with rack failure domains, while mirror-3-dc spans three data centers.
• C4. Distributed storage erasure-codes or replicates blob fragments across VDisks and is accessed through a DS proxy.
• C5. Table partitions can split and move; a hot leading key still needs schema/load analysis rather than a guaranteed instant fix.

Исполняемые сценарии

Single-DataShard transaction. Point-key work resolves one tablet leader and commits through its durable tablet state.

Distributed DataShard transaction. Both shards participate in one coordinated serializable outcome; partial local success is not exposed as commit.

Tablet restart and placement. A tablet leader can restart elsewhere because identity and persistent state are not tied to one dynamic node.

Storage mode and failure domains. One deployment selects a topology whose data-center and rack assumptions match its failure objective.

Hot range split and verify. A hot primary-key range triggers control-plane work; success is measured after split and movement.

Ошибки проектирования

• Не описывайте multi-DataShard transaction как набор независимых local commits: YDB координирует distributed transaction.
• Не путайте tablet, dynamic node и storage replica; tablet — переносимая persistent actor identity.
• Не размещайте block-4-2 как один режим через три DC; для этого failure realm используется mirror-3-dc.
• Не обещайте, что случайный ULID/UUID или split сам по себе устранит skew; проверяйте leading key и traffic concentration.

Границы гарантии

• YDB row/column table transaction capabilities отличаются и меняются; смешанный write scope проверяется по текущей документации.
• Storage durability не равна backup/restore или cross-cluster disaster recovery; эти контуры тестируются отдельно.
• Официальные latency examples — не SLO конкретного deployment; workload и topology измеряются.

Связанные материалы

Официальные и первичные источники

1. YDB Concepts: Transactions
2. YDB Contributor Guide: DataShard distributed transactions
3. YDB Concepts: Cluster topology
4. YDB Concepts: Glossary and tablet implementation
5. YDB Contributor Guide: Distributed storage