Этот класс СУБД появляется там, где команда уже не хочет выбирать между удобством SQL, строгими транзакционными гарантиями и болью ручного шардирования. Эта глава именно про этот промежуточный, но дорогой этап роста.
На практике она помогает понять, когда распределённый SQL действительно снимает часть архитектурной боли, а когда локальность данных, межрегиональная задержка и транзакционная цена всё равно остаются главными факторами.
В интервью и инженерных обсуждениях эта глава особенно полезна, когда нужно сравнить этот подход не с рекламных слайдов, а с PostgreSQL плюс шардирование и NoSQL-подходами под конкретные требования продукта.
Практическая польза главы
Глобальные транзакционные гарантии
Определяйте, где распределённая SQL-СУБД позволяет сохранить строгую транзакционность при горизонтальном масштабировании без ручного шардирования.
Регионально-ориентированный дизайн
Учитывайте локальность данных и межрегиональную задержку, чтобы не платить лишней ценой за каждый транзакционный шаг.
Стоимость консистентности
Сравнивайте выгоду строгой консистентности с ценой в задержке, пропускной способности и инфраструктуре.
Сравнение подходов
Сравнивайте распределённый SQL с PostgreSQL плюс шардирование и NoSQL через бизнес-требования, а не через маркетинговые тезисы.
Рамка выбора и редакторский фокус
Фокус главы
классе распределённых SQL-СУБД и цене строгой транзакционности
Профиль нагрузки
Фокус — транзакционный SQL на горизонтальном и часто региональном масштабе, где один классический узел уже не даёт нужной формы роста.
Когда выбирать
Распределённый SQL оправдан, когда строгие гарантии важнее простоты и команда готова платить задержкой, координацией и эксплуатацией.
Граница и риск
Главные риски — горячие ключи, межрегиональные транзакции, стоимость консенсуса, ребаланс и ложное ощущение бесплатного шардирования.
Связать дальше
Всегда проверяйте решение через базовый вариант PostgreSQL/MySQL, распределённые транзакции и мультирегиональную архитектуру.
Источник
NewSQL (Wikipedia)
Короткий исторический контекст NewSQL: попытка совместить SQL, ACID и горизонтальное масштабирование.
Документация TiDB
TiDB Architecture
Официальный архитектурный обзор TiDB: TiKV, PD, SQL-слой и компоненты HTAP.
В этой главе под понимаем системы, которые сохраняют SQL и , но добавляют и для горизонтального роста.
Главная цена такого выбора — не синтаксис SQL, а , , и их влияние на и .
NewSQL обычно выбирают в тот момент, когда команда хочет сохранить SQL и ACID, но нагрузка уже выходит за комфорт одного OLTP-узла. В этой главе мы сравним три практические реализации: TiDB, CockroachDB и YDB.
Цель сравнения — не выбрать универсального победителя, а научиться быстро сопоставлять профиль нагрузки, транзакционные требования и операционный контур с конкретным движком.
Что обычно означает NewSQL
SQL и ACID без ручного шардирования
Система берёт на себя транзакционную координацию, размещение данных и балансировку нагрузки.
Строгая консистентность по умолчанию
Базовый сценарий — корректность и предсказуемость записи даже под отказами, а не только максимум пропускной способности.
Цена выше классического OLTP
Распределённый SQL требует дисциплины в проектировании ключей, наблюдаемости и планировании ёмкости.
Общий архитектурный паттерн
Архитектурная карта NewSQL
SQL-слой отдельно от KV-хранилища
Одна рамка сравнения для трёх подходов: где живёт SQL-слой, как распределяются данные и где появляется цена консистентности.
MySQL-совместимый путь к распределённому SQL
TiDB разделяет вычисление, метаданные и хранение: SQL-узлы принимают запросы, PD управляет размещением, TiKV хранит данные, а TiFlash добавляет аналитический контур.
Что проверить
Когда подходит
Где риск
Что измерять
TiDB vs CockroachDB vs YDB
Базовая архитектура
- TiDB: SQL-узлы TiDB + TiKV на Raft + PD; HTAP-контур через TiFlash.
- CockroachDB: Единый бинарник: SQL, KV-слой и диапазоны Raft в одном кластере.
- YDB: Таблетки и акторы, архитектура без общего состояния, вычисление и хранение разнесены по слоям.
Межрегиональная модель
- TiDB: Есть политики размещения, но региональная и зональная топология требуют явной настройки.
- CockroachDB: Сильный фокус на географическом разбиении и политиках локальности данных.
- YDB: Сценарии на несколько зон или регионов зависят от конфигурации кластера и топологии доменов.
Совместимость и экосистема
- TiDB: Совместимость с MySQL wire protocol и DDL; удобен для миграций из MySQL.
- CockroachDB: Совместимость с PostgreSQL wire protocol и PostgreSQL-подобный SQL.
- YDB: Собственный SQL-диалект и API; сильная интеграция в экосистему YDB/Yandex Cloud.
Сильные стороны
- TiDB: Хороший баланс OLTP и близкой к операционным данным аналитики HTAP, плюс миграционный путь из MySQL.
- CockroachDB: Сильная история для глобальной транзакционной обработки OLTP и автоматического переключения при отказе региона.
- YDB: Высоконагруженный транзакционный контур, автоматическое шардирование, строковые и колоночные таблицы в одной платформе.
Операционные риски
- TiDB: Нужен контроль горячих регионов и проектирования ключей; HTAP-контуры добавляют операционную сложность.
- CockroachDB: Межрегиональные транзакции увеличивают задержку, а схема и ключи сильно влияют на стоимость записи.
- YDB: Требуется зрелая эксплуатация распределённой системы и дисциплина партиционирования.
| Критерий | TiDB | CockroachDB | YDB |
|---|---|---|---|
| Базовая архитектура | SQL-узлы TiDB + TiKV на Raft + PD; HTAP-контур через TiFlash. | Единый бинарник: SQL, KV-слой и диапазоны Raft в одном кластере. | Таблетки и акторы, архитектура без общего состояния, вычисление и хранение разнесены по слоям. |
| Межрегиональная модель | Есть политики размещения, но региональная и зональная топология требуют явной настройки. | Сильный фокус на географическом разбиении и политиках локальности данных. | Сценарии на несколько зон или регионов зависят от конфигурации кластера и топологии доменов. |
| Совместимость и экосистема | Совместимость с MySQL wire protocol и DDL; удобен для миграций из MySQL. | Совместимость с PostgreSQL wire protocol и PostgreSQL-подобный SQL. | Собственный SQL-диалект и API; сильная интеграция в экосистему YDB/Yandex Cloud. |
| Сильные стороны | Хороший баланс OLTP и близкой к операционным данным аналитики HTAP, плюс миграционный путь из MySQL. | Сильная история для глобальной транзакционной обработки OLTP и автоматического переключения при отказе региона. | Высоконагруженный транзакционный контур, автоматическое шардирование, строковые и колоночные таблицы в одной платформе. |
| Операционные риски | Нужен контроль горячих регионов и проектирования ключей; HTAP-контуры добавляют операционную сложность. | Межрегиональные транзакции увеличивают задержку, а схема и ключи сильно влияют на стоимость записи. | Требуется зрелая эксплуатация распределённой системы и дисциплина партиционирования. |
Быстрый выбор по сценариям
Глобальный SaaS с активной записью в нескольких регионах
Чаще CockroachDB
Если критичны политики локальности данных, выживание при отказе региона и предсказуемое переключение на резерв с SQL-интерфейсом.
Рост из MySQL к распределённому SQL без полного переписывания решения
Чаще TiDB
Когда важна MySQL-совместимость, постепенная миграция и возможность объединить OLTP с HTAP-сценариями.
Высоконагруженные транзакционные сервисы в экосистеме Yandex Cloud
Чаще YDB
Когда нужен управляемый или нативный контур YDB, автоматическое шардирование и сильная интеграция с облачной инфраструктурой.
Региональная транзакционная обработка OLTP без жёстких требований к горизонтальному росту
Часто не нужен NewSQL
Если профиль нагрузки закрывается классическим PostgreSQL/MySQL, распределённый слой может быть избыточной сложностью.
Рекомендации
Начинайте с документа по проектированию ключей: ключ партиционирования, границы транзакций и ожидаемые горячие ключи.
Тестируйте не только пропускную способность, но и задержку p95/p99 при отказах узлов, зон и сетевых разделениях.
Явно разделяйте локальные и межрегиональные транзакции, чтобы контролировать задержки и стоимость.
Закладывайте наблюдаемость по шардам, диапазонам и таблеткам: перекос нагрузки, перебалансировка, повторные попытки и конкуренция блокировок.
Частые ошибки
Считать класс NewSQL СУБД серебряной пулей и переносить существующую схему без пересмотра ключей.
Игнорировать границы транзакций и допускать частые межшардовые или межрегиональные записи.
Сравнивать движки только по искусственному тесту производительности без отказов, перебалансировок и реальных запросов.
Выбирать распределённый SQL там, где один узел PostgreSQL/MySQL уже закрывает нагрузку и SLA.
Источники
Связанные главы
- Фреймворк выбора СУБД - Критерии выбора СУБД, по которым видно, когда класс NewSQL действительно оправдывает свою сложность.
- YDB: распределённая SQL-СУБД и архитектура - Детальный разбор YDB: таблетки, автоматическое шардирование, транзакционные гарантии и операционные компромиссы.
- CockroachDB: распределённая SQL-СУБД и архитектура - Подробности по диапазонам, владельцам аренды, Raft-репликации и политикам локальности данных.
- PostgreSQL: история и архитектура - Сравнение распределённой SQL-модели с классическим OLTP-подходом и точкой, где NewSQL не нужен.
- Распределённые транзакции: 2PC и 3PC - Фон по координации транзакций, компромиссам между задержкой и пропускной способностью и тому, почему распределённая фиксация не бывает бесплатной.
- Мультирегиональные и глобальные системы - Практика построения геораспределённых контуров: локальность данных, переключение на резерв и компромиссы задержки.