NewSQL NewSQL — класс реляционных СУБД, который совмещает привычный… — Системный Аналитик

Системный Аналитик@sys_sa · 19.1K subscribers Open in TelegramOpen

NewSQL

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

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

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

NoSQL отлично масштабируется, но часто жертвует строгой согласованностью

NewSQL пытается дать и то и другое одновременно

Зачем нужен

сохранить совместимость с SQL

масштабироваться горизонтально. Нагрузка распределяется по нескольким узлам кластера, а не наращивается мощность одного сервера

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

Как работает

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

Под капотом транзакция проходит несколько этапов:

SQL-слой принимает запрос. Узел-координатор парсит SQL, строит план выполнения и определяет, на каких шардах лежат затронутые строки
* Шард — диапазон строк таблицы, вынесенный на отдельную группу узлов; сами таблицы заранее разбиты на такие диапазоны по ключу шардирования

Каждый шард — реплицированная группа. Данные одного шарда хранятся на нескольких узлах (обычно 3–5), между которыми работает алгоритм консенсуса (чаще всего Raft)

один узел — лидер, остальные — ведомые

запись считается подтверждённой, когда её приняло большинство (кворум).

обеспечивается строгая согласованность без единого «главного» сервера на всю базу.

Транзакция в пределах одного шарда заканчивается на шаге 2: лидер коммитит запись после получения кворума

Транзакция через несколько шардов идёт по протоколу распределённого коммита — двухфазному коммиту (2PC):

координатор сначала спрашивает все затронутые шарды «готовы?»,

когда все ответили «да», приказывает зафиксировать изменения — иначе откатывает везде. Атомарность сохранена.

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

Глобальное время для согласованности между дата-центрами
Например, чтобы упорядочить транзакции по всему миру, Google Spanner использует TrueTime — атомные часы и GPS-приёмники в каждом ЦОД с известной погрешностью.
Перед коммитом транзакция ждёт, пока эта неопределённость не станет нулевой

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

NewSQL выгоден там, где нужна именно горизонтальная масштабируемость, а не предельная скорость одиночного сервера

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

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

Созданные с нуля
Опираются на оперативную память (in-memory) и быстрые накопители (SSD) для предельной скорости доступа
Например, VoltDB (in-memory NewSQL-СУБД для OLTP-нагрузок реального времени),

Модификация существующих движков
Расширяют зрелые СУБД (например, 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 (документные, ключ-значение, графовые БД)

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