NewSQL — класс реляционных СУБД, который совмещает привычный SQL и строгие ACID -транзакции классических баз (с горизонтальной масштабируемостью и производительностью, характерными для NoSQL)
Попытка убрать главный компромисс хранения данных:
➖ классические реляционные БД надёжны и согласованы, но плохо масштабируются горизонтально
➖ NoSQL отлично масштабируется, но часто жертвует строгой согласованностью
✅ NewSQL пытается дать и то и другое одновременно
Зачем нужен
🔸 сохранить совместимость с SQL
🔸 масштабироваться горизонтально. Нагрузка распределяется по нескольким узлам кластера, а не наращивается мощность одного сервера
🔸 не отказываться от строгой согласованности. В отличие от многих NoSQL-решений с конечной согласованностью, NewSQL держит ACID даже при распределении данных по машинам и дата-центрам
Как работает
⚡️ Главный вызов NewSQL — удержать ACID, когда данные разнесены по нескольким машинам.
Под капотом транзакция проходит несколько этапов:
1️⃣ SQL-слой принимает запрос. Узел-координатор парсит SQL, строит план выполнения и определяет, на каких шардах лежат затронутые строки
* Шард — диапазон строк таблицы, вынесенный на отдельную группу узлов; сами таблицы заранее разбиты на такие диапазоны по ключу шардирования
2️⃣ Каждый шард — реплицированная группа. Данные одного шарда хранятся на нескольких узлах (обычно 3–5), между которыми работает алгоритм консенсуса (чаще всего Raft)
🔹один узел — лидер, остальные — ведомые
🔹запись считается подтверждённой, когда её приняло большинство (кворум).
🔹обеспечивается строгая согласованность без единого «главного» сервера на всю базу.
3️⃣ Транзакция в пределах одного шарда заканчивается на шаге 2: лидер коммитит запись после получения кворума
4️⃣ Транзакция через несколько шардов идёт по протоколу распределённого коммита — двухфазному коммиту (2PC):
🔹координатор сначала спрашивает все затронутые шарды «готовы?»,
🔹когда все ответили «да», приказывает зафиксировать изменения — иначе откатывает везде. Атомарность сохранена.
5️⃣ Параллельные транзакции не мешают друг другу благодаря
MVCC — каждая работает со своим снимком данных на момент старта, читающие не блокируют пишущих. 6️⃣ Глобальное время для согласованности между дата-центрами
Например, чтобы упорядочить транзакции по всему миру, Google Spanner использует
TrueTime — атомные часы и GPS-приёмники в каждом ЦОД с известной погрешностью.Перед коммитом транзакция ждёт, пока эта неопределённость не станет нулевой
▶️ Плата за распределённость — дополнительные раунды обмена между узлами: чем больше шардов и реплик проходит транзакция, тем выше задержка
👉 NewSQL выгоден там, где нужна именно горизонтальная масштабируемость, а не предельная скорость одиночного сервера
Классификация NewSQL-систем
Выделяют два подхода к появлению NewSQL-систем:
1️⃣ Созданные с нуля
Опираются на оперативную память (
in-memory) и быстрые накопители (SSD) для предельной скорости доступаНапример,
VoltDB (in-memory NewSQL-СУБД для OLTP-нагрузок реального времени), 2️⃣ Модификация существующих движков
Расширяют зрелые СУБД (например, MySQL/MariaDB) новыми движками хранения и оптимизациями
Например,
Percona Server (оптимизированный форк MySQL), ▶️ Отдельная ветка — связующее ПО (middleware), которое делает прозрачное шардирование над обычными одноузловыми СУБД:
Apache ShardingSphere, MaxScale.Это не полноценный NewSQL: такие слои маршрутизируют запросы, но не дают распределённого ACID
Примеры СУБД
🔹YDB (Яндекс) — open-source распределённая реляционная SQL-СУБД
Горизонтальная масштабируемость, строгая согласованность и ACID-транзакции, совмещение OLTP- и OLAP-нагрузок; язык запросов —
YQL (диалект SQL)🔹CockroachDB — распределённая SQL-база, совместимая с диалектом PostgreSQL, с упором на географическое распределение и живучесть
🔹Tarantool (экосистема VK) — in-memory СУБД с хранимыми процедурами на Lua, синхронной репликацией и автоматическими выборами лидера. Не классический NewSQL, а смежное решение для высоконагруженных сценариев: очереди, кэши, мастер-хранилища с высокой пропускной способностью
Когда применять
😫 высоконагруженные OLTP-системы, где критична строгая согласованность данных (финтех, биллинг, обработка платежей)
😫 географически распределённые системы. Когда данные и пользователи размазаны по дата-центрам и регионам, а согласованность всё равно нужна
😫 когда вертикальное масштабирование классической реляционной БД упёрлось в потолок, но переходить на NoSQL с конечной согласованностью нельзя по требованиям бизнеса.
Когда НЕ стоит использовать
➖ небольшие проекты с предсказуемой нагрузкой. Классической реляционной БД (MySQL, PostgreSQL) хватит
➖ неструктурированные и слабоструктурированные данные. Соцсети, логи, данные датчиков, вложенные документы — для NoSQL (документные, ключ-значение, графовые БД)
Плюсы и минусы
➕ горизонтальная масштабируемость без отказа от строгой согласованности и ACID
➕ привычный SQL и совместимость с реляционными инструментами
➕ отказоустойчивость и высокая доступность за счёт распределённой архитектуры и репликации
➕ подходит для систем с большим потоком параллельных транзакций
➖ сложность настройки, обслуживания и диагностики неполадок по сравнению с классическими реляционными БД
➖ ограниченная переносимость между решениями: разные NewSQL используют разные диалекты SQL и архитектуры, миграция между ними не всегда простая
➖ выше задержка на запись из-за раундов согласования между узлами (консенсус, распределённый коммит)
📎 Материалы
1. Кратко про NewSQL
2. Как выбрать NewSQL-СУБД для вашей компании
3. NewSQL: SQL никуда не уходит
4. NewSQL — новый виток в эволюции BigData
5. Сравнение производительности YDB, CockroachDB и YugabyteDB на бенчмарке YCSB
6. Разбираемся в типах баз данных
📚 Книги
1. Высоконагруженные приложения. Программирование, масштабирование, поддержка — Мартин Клеппман
#бд #sql
➿➿➿➿➿➿➿➿➿➿
🧑🎓 Более поробное сравнение в базе знаний по системному анализу