Почему появился NewSQL
На рубеже 2000-х и 2010-х годов индустрия оказалась в ловушке: классические реляционные СУБД не справлялись с растущей нагрузкой, а NoSQL-решения жертвовали транзакционностью ради масштабируемости. Термин NewSQL предложил аналитик Мэтью Аслет (451 Group) в 2011 году, обозначив им класс систем, которые одновременно:
- Поддерживают реляционную модель данных и язык SQL
- Гарантируют ACID-транзакции
- Обеспечивают горизонтальное масштабирование, как NoSQL
- Используют современное ядро, а не унаследованную архитектуру традиционных RDBMS
Проще говоря, NewSQL — это ответ на вопрос: «Почему мы должны выбирать между масштабированием и надёжностью транзакций?»
Легендарный Майкл Стоунбрейкер, один из отцов реляционных баз данных, в 2011 году заявил, что традиционные СУБД медленны не из-за SQL как такового, а из-за того, что они проектировались для других эпох и вот тут-то и выходят на сцену NewSQL.
SQL, NoSQL, NewSQL: где граница
Чтобы правильно выбирать инструмент, аналитику и архитектору важно понять, что каждый из трёх классов решает разные задачи:
| Критерий | Традиционный SQL | NoSQL | NewSQL |
|---|---|---|---|
| Модель данных | Реляционная, строгая схема | Гибкая (документы, KV, граф) | Реляционная + гибкое распределение |
| Транзакции | ACID, но один узел | BASE (eventual consistency) | ACID на кластере |
| Масштабирование | Вертикальное | Горизонтальное | Горизонтальное |
| Язык запросов | SQL | Зависит от БД | SQL (совместим с MySQL/PostgreSQL) |
| Типичная нагрузка | OLTP, до среднего масштаба | Big Data, real-time, гибкие схемы | High-throughput OLTP, критичные системы |
NoSQL отказывается от ACID ради скорости и гибкости. Это работает, когда «несогласованность» допустима — например, лента новостей в соцсети. Но в финансах, e-commerce и телекоме, где каждая транзакция должна быть атомарной, это неприемлемо. NewSQL закрывает именно этот пробел.
ClustrixDB
Архитектура
ClustrixDB — кластеризованная реляционная СУБД, созданная как масштабируемая замена MySQL. Она построена на архитектуре shared-nothing: каждый узел самодостаточен и может выполнять любые операции чтения и записи. Это принципиально отличается от классического MySQL с репликацией master-slave, где мастер становится узким горлышком.
Три ключевых компонента архитектуры:
- GTM (Global Transaction Manager) — координирует транзакции, компилирует SQL в фрагменты запросов и строит оптимальный распределённый план выполнения;
- Rebalancer — патентованный механизм, использующий согласованное хеширование для автоматического распределения данных по узлам кластера без ручного шардирования;
- Sierra Database Kernel — ядро выполнения, которое компилирует запрос в исполняемые фрагменты и распределяет их по кластеру.
Особенности, важные для архитекторов:
- Механизм чекпоинтов каждые 500 мс — позволяет откатиться к консистентному состоянию всего кластера;
- Двухфазные блокировки на уровне строк и таблиц во всех узлах;
- Уровень изоляции по умолчанию — Repeatable Read (с возможностью выбора Read Committed и Serializable);
- Внешние ключи поддерживаются, но с ограничением: они должны вести к уникальным родителям;
- Используются MVCC и протокол PAXOS для согласованности.
Идеальный сценарий применения: Samsung Cloud
Задача: Samsung Cloud обслуживает сотни миллионов пользователей, обрабатывает десятки миллиардов запросов в сутки и хранит сотни петабайт данных. До перехода на ClustrixDB инфраструктура строилась на ручном шардировании MySQL — это требовало дополнительного кода для роутинга запросов, сложных миграций при ребалансировке и не давало полноценной аналитики без объединения данных из разных шардов.
Решение: ClustrixDB автоматически распределяет данные и запросы по кластеру, устраняя прпоблему ручного шардирования. Samsung развернул систему в трёх географических регионах, обрабатывая 230 миллионов транзакций в секунду при 16 миллиардах строк в базе. Команда смогла сосредоточиться на логике сервиса, а не на инфраструктуре.
Вывод для архитектора: ClustrixDB оптимален, когда у вас высоконагруженный OLTP на MySQL, который упёрся в потолок вертикального масштабирования, и вы хотите уйти от сложности ручного шардирования.
NuoDB
Архитектура
NuoDB — распределённая реляционная СУБД с уникальной трёхуровневой peer-to-peer архитектурой, не имеющей аналогов среди традиционных СУБД. Система полностью отказывается от парадигмы «общего диска» (shared disk) и «без общего доступа» (shared nothing) в пользу динамического кэширования.
Два ключевых слоя:
- Transaction Engine (TE) — in-memory уровень, который обрабатывает транзакционную логику (атомарность, согласованность, изоляция). Фактически является распределённым кэшем по требованию. Можно запустить несколько TE для горизонтального масштабирования чтения и записи;
- Storage Manager (SM) — уровень долговременного хранения. SM ведёт журнал всех операций только добавляя записи и историю различий (diff log).
При промахе кэша TE обращается к любому из peer-узлов: другому TE (если у него есть нужные данные в кэше) или SM. Это позволяет добавлять новые TE-узлы «на лету» без остановки системы — живая миграция и масштабирование по требованию без downtime.
Особенности, важные для аналитика и архитектора:
- MVCC для разрешения конфликтов: все данные версионированы и хранятся в кэшах TE;
- Два режима видимости: SNAPSHOT VERSION (начало транзакции фиксирует срез данных) и MOST RECENT (видны последние зафиксированные данные из всех узлов);
- Уровень изоляции по умолчанию — Snapshot Isolation;
- Индексация через B-tree;
- Поддержка DDL для изменения структуры на лету;
- Peer-to-peer протокол маршрутизации устраняет единую точку отказа.
Идеальный сценарий применения: Телеком и SaaS
Задача: Представьте телеком-оператора, у которого биллинговая система работает 24/7 без возможности полнорй остановки. В часы пик нагрузка возрастает в 10 раз, в ночное время — падает. Традиционные СУБД требуют либо избыточного железа «на пик», либо сложного ручного управления мощностями.
Почему NuoDB: Архитектура TE позволяет добавлять и удалять транзакционные узлы без перезапуска. BT (British Telecom) применяет NuoDB для управления сетью и обслуживания клиентов, Scotiabank — для глобальной банковской платформы с требованиями высокой доступности. Компания Amdocs, ведущий поставщик биллинговых решений для телекомов, также использует NuoDB для обработки клиентского опыта.
Вывод для архитектора: NuoDB идеален для облачно-нативных сценариев с непредсказуемым масштабированием: когда вам нужно эластично добавлять вычислительные мощности под транзакции, не трогая слой хранения. Это классический fit для микросервисных архитектур в облаке.
CockroachDB
Архитектура
CockroachDB (CRDB) — распределённая база данных SQL с открытым исходным кодом, построенная на строго согласованном хранилище ключей и значений. Название не случайно — система проектировалась так, чтобы «выживать» при любых проблемах, как таракан.
Два архитектурных слоя:
- Слой SQL — экспортирует полный реляционный API, преобразует SQL-запросы в вызовы KV-хранилища. Поддерживает распределённое выполнение запросов: узел шлюза строит DAG (направленный ациклический граф) процессоров SQL и распределяет их по кластеру;
- Слой хранения — построен на PebbleDB (собственная Go-реализация RocksDB/LevelDB, использующая LSM-дерево). Диапазоны ключей шардируются и реплицируются по кластеру через алгоритм консенсуса Raft.
Особенности, критичные для архитектора:
- MVCC + репликация через кворум — обеспечивает отказоустойчивость без единой точки отказа;
- Уровни изоляции: Snapshot Isolation, Read Committed, Serializable;
- Векторизованное выполнение запросов — для аналитических подзапросов;
- Geo-partitioning через
REGIONAL BY ROW— данные физически размещаются ближе к пользователю, обеспечивая соответствие требованиям регуляторов (GDPR, 152-ФЗ); - Совместимость с PostgreSQL wire protocol — миграция существующих приложений минимальна;
- Модель данных — ключ-значение под капотом, реляционная модель на поверхности.
Идеальный сценарий применения: Глобальные финансовые и платёжные системы
Задача 1 — Финтех (DoorDash, Netflix): Платёжная система должна работать на глобальном рынке, переживать сбои дата-центров без потери транзакций и соответствовать требованиям разных юрисдикций по локализации данных. Netflix использует CockroachDB для обеспечения отказоустойчивости сервисной архитектуры, DoorDash перешёл с Aurora Postgres на CockroachDB для обработки глобальных транзакций в своей системе заказов.
Задача 2 — Спортивный беттинг: Hard Rock Digital построил высокодоступную платформу спортивных ставок на CockroachDB — приложение обрабатывает пиковые нагрузки во время крупных спортивных событий без деградации.
Задача 3 — Twitter (многорегиональный кейс): Инженеры Twitter используют CockroachDB для трёх сценариев одновременно: read-heavy нагрузки, write-heavy нагрузки и мульти-регионального хранения данных пользователей с низкой задержкой.
Вывод для архитектора: CockroachDB оптимален для систем с требованиями географического распределения и строгой консистентности: платёжные системы, управление учётными записями, IAM (Identity Access Management), системы управления заказами. Это выбор, когда вы не можете позволить себе ни простоя, ни потери транзакций, ни нарушения регуляторных требований по локализации данных.
Сравнение трёх NewSQL СУБД
| ClustrixDB | NuoDB | CockroachDB | |
|---|---|---|---|
| Первичная ниша | High-throughput OLTP, замена MySQL | Облачная эластичность, телеком, SaaS | Мульти-регион, финтех, IAM |
| Архитектурный паттерн | Shared-nothing кластер | Peer-to-peer + раздельные слои TE/SM | Distributed KV + Raft consensus |
| Хранилище | Проприетарное | Append-only diff log | PebbleDB (LSM-tree) |
| Согласованность | MVCC + PAXOS | MVCC (Snapshot / Most Recent) | MVCC + Raft |
| Geo-distribution | Через зоны (zones) | Через живую миграцию TE | Нативно (REGIONAL BY ROW) |
| Совместимость | MySQL | SQL (JDBC/ODBC) | PostgreSQL wire protocol |
| Открытый исходный код | Нет (MariaDB Enterprise) | Нет | Да |
| Уровни изоляции | RR, RC, Serializable | Snapshot, Read Committed | Snapshot, RC, Serializable |
Как выбирать: взгляд архитектора
Выбор NewSQL-решения — это всегда компромисс между нагрузочным профилем, требованиями к согласованности и операционной сложностью. Несколько ключевых вопросов, которые помогут принять решение:
1. Какая у вас текущая СУБД и насколько критична совместимость? Если вы на MySQL и хотите масштабировать без переписывания приложений — ClustrixDB. Если на PostgreSQL — CockroachDB. Если строите с нуля в облаке — NuoDB или CockroachDB.
2. Нужна ли географическая распределённость с локализацией данных?
Здесь нет конкурентов CockroachDB с его REGIONAL BY ROW и встроенной поддержкой мульти-региональных кластеров. Это особенно важно в контексте 152-ФЗ и международных регуляторных требований.
3. Насколько непредсказуема ваша нагрузка? Если нагрузка сильно варьируется и вы платите за облако, архитектура NuoDB с отдельными масштабируемыми TE-узлами даёт наибольшую экономическую эффективность.
4. Важна ли открытость и возможность самостоятельного развёртывания? Из трёх рассмотренных только CockroachDB является полностью открытым — это снижает зависимость от вендора и упрощает аудит безопасности.
Когда NewSQL не нужен:
- Малые и средние нагрузки — PostgreSQL или MySQL справятся дешевле
- Аналитические (OLAP) нагрузки — лучше ClickHouse, Greenplum, BigQuery
- Неструктурированные данные с гибкой схемой — MongoDB, Cassandra
Место NewSQL в современной ИТ-архитектуре
NewSQL не убивает ни SQL, ни NoSQL — он занимает конкретную нишу: высоконагруженные транзакционные системы, которым нужна горизонтальная масштабируемость без отказа от ACID. В Одноклассниках (VK) именно невозможность хранить критические транзакционные данные в NoSQL при объёме в 50 ТБ привела к выбору NewSQL-подхода.
Архитектор, понимающий разницу между этими тремя классами, сможет избежать двух типичных ошибок: переусложнения (когда NewSQL берут для задачи, с которой справился бы обычный PostgreSQL) и недооценки (когда растущая система упирается в стену и требует дорогостоящего рефакторинга). Выбор инструмента под задачу — это и есть архитектурная зрелость.
Нужен разбор вашего архитектурного решения? Я провожу менторские сессии для системных аналитиков и архитекторов: Нужно подобрать базу данных под ваше решение? Обращайтесь!. Подробнее: /mentoring/