NewSQL

NewSQL — класс реляционных СУБД, который совмещает привычный SQL и строгие ACID-транзакции классических баз (с горизонтальной масштабируемостью и производительностью, характерными для NoSQL).

Попытка убрать главный компромисс хранения данных:

классические реляционные БД надёжны и согласованы, но плохо масштабируются горизонтально;
NoSQL отлично масштабируется, но часто жертвует строгой согласованностью. NewSQL пытается дать и то и другое одновременно.

Зачем нужен

Сохранить совместимость с SQL.
Масштабироваться горизонтально. Нагрузка распределяется по нескольким узлам кластера вместо того, чтобы наращивать мощность одного сервера.
Не отказываться от строгой согласованности. В отличие от многих NoSQL-решений с конечной согласованностью, NewSQL держит ACID даже при распределении данных по машинам и дата-центрам.

Как работает

Главный вызов NewSQL — удержать ACID, когда данные разнесены по нескольким машинам. Под капотом транзакция проходит несколько этапов.

SQL-слой принимает запрос. Узел-координатор парсит SQL, строит план выполнения и определяет, на каких шардах лежат затронутые строки. Шард — диапазон строк таблицы, вынесенный на отдельную группу узлов; сами таблицы заранее разбиты на такие диапазоны по ключу шардирования.
Каждый шард — реплицированная группа. Данные одного шарда хранятся на нескольких узлах (обычно 3–5), между которыми работает алгоритм консенсуса — чаще всего Raft. Один узел — лидер, остальные — ведомые; запись считается подтверждённой, когда её приняло большинство (кворум). Так обеспечивается строгая согласованность без единого «главного» сервера на всю базу.
Транзакция в пределах одного шарда заканчивается на шаге 2: лидер коммитит запись после получения кворума.
Транзакция через несколько шардов идёт по протоколу распределённого коммита — двухфазному коммиту (2PC): координатор сначала спрашивает все затронутые шарды «готовы?», и лишь когда все ответили «да», приказывает зафиксировать изменения — иначе откатывает везде. Атомарность сохранена.
Параллельные транзакции не мешают друг другу благодаря MVCC — каждая работает со своим снимком данных на момент старта, читающие не блокируют пишущих. Подробнее про BASE как альтернативный подход к согласованности.
Глобальное время для согласованности между дата-центрами. Чтобы упорядочить транзакции по всему миру, Google Spanner использует TrueTime — атомные часы и GPS-приёмники в каждом ЦОД с известной погрешностью; перед коммитом транзакция ждёт, пока эта неопределённость не станет нулевой. CockroachDB и YDB обходятся без спец-железа — гибридными логическими часами (HLC).

Плата за распределённость — дополнительные раунды обмена между узлами: чем больше шардов и реплик проходит транзакция, тем выше задержка. Поэтому NewSQL выгоден там, где нужна именно горизонтальная масштабируемость, а не предельная скорость одиночного сервера.

Классификация NewSQL-систем

Выделяют два подхода к появлению NewSQL-систем:

Созданные с нуля — опираются на оперативную память (in-memory) и быстрые накопители (SSD) для предельной скорости доступа. Примеры:

VoltDB (in-memory NewSQL-СУБД для OLTP-нагрузок реального времени),
NuoDB (эластичная SQL-база с раздельными слоями транзакций и хранения).

Модификация существующих движков — расширяют зрелые СУБД (например, MySQL/MariaDB) новыми движками хранения и оптимизациями. Примеры:

Percona Server (оптимизированный форк MySQL),

Отдельная ветка — связующее ПО (middleware), которое делает прозрачное шардирование над обычными одноузловыми СУБД: Apache ShardingSphere, MaxScale. Это не полноценный NewSQL: такие слои маршрутизируют запросы, но не дают распределённого ACID.

Примеры СУБД

YDB (Яндекс) — open-source распределённая реляционная SQL-СУБД. Горизонтальная масштабируемость, строгая согласованность и ACID-транзакции, совмещение OLTP- и OLAP-нагрузок; язык запросов — YQL (диалект SQL).
CockroachDB — распределённая SQL-база, совместимая с диалектом PostgreSQL, с упором на географическое распределение и живучесть.
TiDB (PingCAP) — MySQL-совместимая distributed SQL-база с поддержкой HTAP (транзакции + аналитика); архитектура разделяет SQL-слой (TiDB) и распределённое key-value хранилище (TiKV поверх Raft).
Google Spanner — глобальная распределённая SQL-база с механизмом TrueTime; эталон направления NewSQL.
VoltDB — in-memory NewSQL-СУБД для OLTP-нагрузок реального времени
Tarantool (экосистема VK) — in-memory СУБД с хранимыми процедурами на Lua, синхронной репликацией и автоматическими выборами лидера. Не классический NewSQL, а смежное решение для высоконагруженных сценариев: очереди, кэши, мастер-хранилища с высокой пропускной способностью.

Когда применять

Высоконагруженные OLTP-системы, где критична строгая согласованность данных. Финансовый сектор и финтех, биллинг, обработка платежей — там, где недопустимы ни потери данных, ни рассинхрон между узлами.
Географически распределённые системы. Когда данные и пользователи размазаны по дата-центрам и регионам, а согласованность всё равно нужна.
Когда вертикальное масштабирование классической реляционной БД упёрлось в потолок, но переходить на NoSQL с конечной согласованностью нельзя по требованиям бизнеса.

Когда НЕ стоит использовать

Небольшие проекты с предсказуемой нагрузкой. Классической реляционной БД (MySQL, PostgreSQL) хватит — распределённая архитектура здесь избыточна и дорога.
Неструктурированные и слабоструктурированные данные. Соцсети, логи, данные датчиков, вложенные документы — для NoSQL (документные, ключ-значение, графовые БД).
Нет компетенций по эксплуатации распределённых систем. Настройка, мониторинг и диагностика неполадок NewSQL заметно сложнее, чем одиночной реляционной БД.

Сравнение SQL, NoSQL и NewSQL

Критерий	Реляционные (SQL)	NoSQL	NewSQL
Модель данных	реляционная, таблицы	документ / ключ-значение / столбцы / граф	реляционная + SQL
Согласованность	строгая, ACID	часто конечная (eventual)	строгая, ACID
Масштабирование	преимущественно вертикальное	горизонтальное	горизонтальное
Схема данных	жёсткая	гибкая	жёсткая
Примеры	MySQL, PostgreSQL, Oracle	MongoDB, Cassandra, Redis	YDB, CockroachDB, TiDB

Плюсы и минусы

Плюсы:

горизонтальная масштабируемость без отказа от строгой согласованности и ACID;
привычный SQL и совместимость с реляционными инструментами — низкий порог входа для команды;
отказоустойчивость и высокая доступность за счёт распределённой архитектуры и репликации;
подходит для систем с большим потоком параллельных транзакций.

Минусы:

сложность настройки, обслуживания и диагностики неполадок по сравнению с классическими реляционными БД;
относительно молодое направление — меньше экосистемы, документации и сообщества, чем у зрелых PostgreSQL/MySQL;
ограниченная переносимость между решениями: разные NewSQL используют разные диалекты SQL и архитектуры, поэтому миграция между ними не всегда тривиальна;
выше задержка на запись из-за раундов согласования между узлами (консенсус, распределённый коммит).

Что важно для аналитика

Различать классы хранилищ по требованиям. Решение «NewSQL vs реляционная vs NoSQL» вытекает из требований к согласованности, масштабу и географии данных — это часть архитектурного анализа.
Учитывать стоимость владения. Распределённая система — это не только возможности, но и сложность эксплуатации, кадры и ограничения переносимости. Это влияет на выбор не меньше, чем характеристики самой БД.
Ловить сценарий «нужна согласованность + рост нагрузки». Если в требованиях звучит «много транзакций, расходимся по регионам, но деньги терять нельзя» — NewSQL кандидат на рассмотрение.

Подборка материалов

Видео

Конференции

Книги

Высоконагруженные приложения. Программирование, масштабирование, поддержка — Мартин Клеппман

Зачем нужен​

Как работает​

Классификация NewSQL-систем​

Примеры СУБД​

Когда применять​

Когда НЕ стоит использовать​

Сравнение SQL, NoSQL и NewSQL​

Плюсы и минусы​

Что важно для аналитика​

Подборка материалов​

Видео​

Конференции​

Книги​