Эта глава темы 8 фокусируется на NewSQL-подходе и компромиссах SQL+ACID в distributed-среде.
В реальном проектировании систем этот материал помогает выбирать хранилище и границы данных через измеримые ограничения: профиль нагрузки, консистентность, задержки, стоимость эксплуатации и риски эволюции.
Для System Design interview глава полезна тем, что даёт четкий словарь компромиссов и аргументацию архитектурных решений: почему выбран именно этот подход, где его границы и как он ведет себя при сбоях.
Практическая польза главы
Global ACID fit
Определяйте, где NewSQL позволяет сохранить SQL+ACID при горизонтальном масштабировании без ручного шардирования.
Region-aware дизайн
Учитывайте data locality и межрегионные RTT, чтобы не платить лишней задержкой за каждый транзакционный шаг.
Стоимость консистентности
Сравнивайте выгоду сильной консистентности с ценой по latency, throughput и инфраструктуре.
Interview comparison
Сравнивайте NewSQL с Postgres+шардинг и NoSQL через бизнес-требования, а не через маркетинговые тезисы.
Primary source
NewSQL (Wikipedia)
Быстрый исторический контекст NewSQL: попытка совместить SQL/ACID и горизонтальное масштабирование.
TiDB docs
TiDB Architecture
Официальный архитектурный обзор TiDB: TiKV, PD, SQL layer и HTAP-компоненты.
NewSQL обычно выбирают в тот момент, когда команда хочет сохранить SQL и ACID, но нагрузка уже выходит за комфорт single-node OLTP. В этой главе мы сравним три практические реализации: TiDB, CockroachDB и YDB.
Цель сравнения - не выбрать универсального победителя, а научиться быстро сопоставлять workload, транзакционные требования и операционный контур с конкретным движком.
Что обычно означает NewSQL
SQL + ACID без отказа от распределенности
Вместо ручного шардинга на уровне приложения система берет на себя транзакционную координацию и балансировку данных.
Сильная консистентность как default
Базовый сценарий - корректность и предсказуемость записи даже под отказами, а не только максимум throughput.
Operational complexity выше классического OLTP
Цена distributed SQL - более строгая дисциплина key design, observability и capacity planning.
Общий архитектурный паттерн
SQL как основной интерфейс
NewSQL сохраняет реляционную модель и SQL-экосистему, чтобы команды не переписывали все приложение под NoSQL API.
Consensus-репликация
Данные реплицируются между узлами через протоколы класса Raft/Paxos для устойчивости к сбоям и строгих гарантий на запись.
Автоматическое шардирование
Система делит и перемещает диапазоны/шарды без ручного split/merge, чтобы scale-out был управляемым операционно.
Транзакции в distributed-контуре
ACID и serializable-подобные гарантии реализуются поверх распределенного KV-слоя и координации транзакций.
TiDB vs CockroachDB vs YDB
Базовая архитектура
- TiDB: TiDB server + TiKV (Raft KV) + PD; HTAP через TiFlash.
- CockroachDB: Единый бинарник: SQL + KV + Raft ranges в одном кластере.
- YDB: Tablets/actors, shared-nothing, compute/storage разнесены по слоям.
Multi-region модель
- TiDB: Есть placement rules, но чаще используется региональный/зональный контур с явной настройкой.
- CockroachDB: Сильный фокус на geo-partitioning и locality policy из коробки.
- YDB: Multi-AZ и геораспределенные сценарии зависят от конфигурации кластера и топологии доменов.
Совместимость и экосистема
- TiDB: MySQL-compatible wire/DDL; удобен для миграций из MySQL.
- CockroachDB: PostgreSQL wire-совместимость и PostgreSQL-подобный SQL.
- YDB: Собственный SQL-диалект и API; сильная интеграция в экосистему YDB/Yandex Cloud.
Сильные стороны
- TiDB: Хороший баланс OLTP + near-real-time аналитики (HTAP) и миграционный путь из MySQL.
- CockroachDB: Сильная история для global OLTP и auto-failover в multi-region.
- YDB: Высоконагруженный транзакционный контур, auto-sharding, row+column таблицы в одной платформе.
Операционные риски
- TiDB: Нужен контроль hot-region и ключевого дизайна; сложность HTAP-контуров.
- CockroachDB: Стоимость latency при межрегионных транзакциях и требования к schema/key design.
- YDB: Требуется зрелая модель эксплуатации distributed-системы и дисциплина partitioning.
| Критерий | TiDB | CockroachDB | YDB |
|---|---|---|---|
| Базовая архитектура | TiDB server + TiKV (Raft KV) + PD; HTAP через TiFlash. | Единый бинарник: SQL + KV + Raft ranges в одном кластере. | Tablets/actors, shared-nothing, compute/storage разнесены по слоям. |
| Multi-region модель | Есть placement rules, но чаще используется региональный/зональный контур с явной настройкой. | Сильный фокус на geo-partitioning и locality policy из коробки. | Multi-AZ и геораспределенные сценарии зависят от конфигурации кластера и топологии доменов. |
| Совместимость и экосистема | MySQL-compatible wire/DDL; удобен для миграций из MySQL. | PostgreSQL wire-совместимость и PostgreSQL-подобный SQL. | Собственный SQL-диалект и API; сильная интеграция в экосистему YDB/Yandex Cloud. |
| Сильные стороны | Хороший баланс OLTP + near-real-time аналитики (HTAP) и миграционный путь из MySQL. | Сильная история для global OLTP и auto-failover в multi-region. | Высоконагруженный транзакционный контур, auto-sharding, row+column таблицы в одной платформе. |
| Операционные риски | Нужен контроль hot-region и ключевого дизайна; сложность HTAP-контуров. | Стоимость latency при межрегионных транзакциях и требования к schema/key design. | Требуется зрелая модель эксплуатации distributed-системы и дисциплина partitioning. |
Быстрый выбор по сценариям
Global SaaS с активной multi-region записью
Чаще CockroachDB
Если критичны locality policies, survive-поведение при отказе региона и предсказуемый geo-failover с SQL-интерфейсом.
Рост из MySQL в distributed SQL без полного переписывания решения
Чаще TiDB
Когда важна MySQL-совместимость, постепенная миграция и возможность объединить OLTP с HTAP-сценариями.
High-load транзакционные сервисы в экосистеме Yandex Cloud
Чаще YDB
Когда нужен managed/нативный контур YDB, auto-sharding и сильная интеграция с облачной инфраструктурой.
Обычный региональный OLTP без жестких scale-out требований
Часто не NewSQL
Если профиль нагрузки закрывается классическим PostgreSQL/MySQL, distributed-слой может быть избыточной сложностью.
Рекомендации
Начинай с ключевого design-документа: partition key, transaction boundaries, expected hot keys.
Тестируй не только throughput, но и p95/p99 latency при отказах нод/зон и network partitions.
Явно разделяй local и cross-region транзакции, чтобы контролировать задержки и стоимость.
Закладывай observability по shard/range/tablet: skew, rebalance, retry и lock contention метрики.
Частые ошибки
Считать NewSQL серебряной пулей и переносить существующую схему без redesign ключей.
Игнорировать транзакционные границы и допускать частые cross-shard/cross-region записи.
Сравнивать движки только по synthetic benchmark без отказов, ребалансировок и реальных запросов.
Выбирать distributed SQL там, где single-node OLTP уже закрывает нагрузку и SLA.
References
Связанные главы
- Database Selection Framework - Практический фреймворк выбора СУБД и критериев, по которым NewSQL может оказаться оптимальным.
- YDB: distributed SQL база данных и архитектура - Детальный разбор YDB: tablets, auto-sharding, транзакционные гарантии и операционные компромиссы.
- CockroachDB: distributed SQL база данных и архитектура - Подробности по ranges/leaseholder, Raft replication и multi-region locality политикам.
- PostgreSQL: история и архитектура - Сравнение distributed SQL-модели с классическим OLTP-подходом и точкой, где NewSQL не нужен.
- Distributed Transactions (2PC/3PC) - Фон по координации транзакций, latency trade-offs и why distributed commit не бывает бесплатным.
- Мультирегиональные и глобальные системы - Практика построения geo-distributed контуров: locality, failover и компромиссы задержки.