NewSQL

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

Термин «NewSQL» был введён в 2011 году аналитиком компании 451 Group Мэттом Асаем (Matt Asay) для описания нового поколения баз данных, которые не отказываются от реляционной модели и SQL, но используют современные архитектурные решения, такие как распределённые вычисления, колоночное хранение, индексация в памяти (in-memory) и автоматическое шардирование.

История возникновения

Предпосылки появления

В середине 2000-х годов рост интернет-сервисов (социальные сети, электронная коммерция, облачные платформы) породил спрос на базы данных, способные обрабатывать огромные объёмы данных с минимальной задержкой. Традиционные реляционные СУБД (RDBMS) столкнулись с проблемами масштабирования: горизонтальное масштабирование (добавление новых серверов) было сложным из-за требований к согласованности и блокировкам, а вертикальное масштабирование (увеличение мощности одного сервера) упиралось в физические ограничения. В ответ возникли NoSQL-системы (например, MongoDB, Cassandra), которые пожертвовали ACID-гарантиями ради производительности и горизонтальной масштабируемости.

Развитие NewSQL

К 2010 году стало очевидно, что NoSQL-решения не подходят для многих бизнес-приложений, где критична транзакционная целостность (например, банковские системы, бронирование билетов). Это привело к появлению NewSQL как компромиссного подхода. Первыми коммерческими NewSQL-системами стали:

• Google Spanner (2012) — глобально распределённая реляционная база данных, использующая атомные часы для синхронизации времени и обеспечивающая внешнюю согласованность.
• VoltDB (2010) — система, работающая полностью в оперативной памяти и использующая однопоточные транзакции для устранения блокировок.
• NuoDB (2010) — облачная СУБД с эластичным масштабированием.

В 2013 году компания Cockroach Labs выпустила CockroachDB — распределённую SQL-базу данных, устойчивую к сбоям и основанную на архитектуре Google Spanner. К 2020-м годам NewSQL стал стандартом для многих облачных платформ (например, Amazon Aurora, Google Cloud Spanner, Microsoft Azure SQL Database).

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

NewSQL-системы можно разделить на три основные категории по архитектурному подходу:

1. Новые реляционные СУБД с нуля

Эти системы созданы с использованием современных технологий (in-memory, распределённые вычисления) без наследия классических RDBMS. Примеры:

• VoltDB — полностью in-memory, поддерживает ACID, использует хранимые процедуры на Java.
• MemSQL (ныне SingleStore) — гибридная in-memory и on-disk архитектура, поддерживает SQL и JSON.
• NuoDB — облачная СУБД с эластичным масштабированием через «слои» (storage и transaction).

2. Облачные реляционные СУБД

Это управляемые сервисы, которые модифицируют классические ядра баз данных для облачной среды. Примеры:

• Amazon Aurora — совместима с MySQL и PostgreSQL, использует распределённое хранилище с автоматическим восстановлением.
• Google Cloud Spanner — глобально распределённая база данных с ACID и SQL.
• Azure SQL Database — облачная версия Microsoft SQL Server с автоматическим шардированием.

3. Промежуточные слои (middleware)

Эти системы не являются самостоятельными СУБД, а добавляют масштабируемость поверх существующих RDBMS. Примеры:

• ScaleBase — прозрачное шардирование для MySQL.
• Citus (ныне часть Microsoft) — расширение PostgreSQL для распределённых запросов.

Архитектура и ключевые характеристики

Основные принципы

• Горизонтальное масштабирование: данные распределяются по множеству узлов (шардов) автоматически, без необходимости ручного управления.
• In-memory обработка: многие NewSQL-системы (VoltDB, MemSQL) хранят данные в оперативной памяти, что обеспечивает низкую задержку (микросекунды).
• ACID-гарантии: поддержка атомарности, согласованности, изолированности и долговечности на уровне распределённой системы.
• SQL-интерфейс: полная поддержка стандарта SQL (JOIN, подзапросы, транзакции), что упрощает миграцию с классических RDBMS.

Технические механизмы

• Протоколы консенсуса: для обеспечения согласованности в распределённой среде используются алгоритмы, такие как Paxos (Google Spanner) или Raft (CockroachDB).
• Многоверсионное управление параллелизмом (MVCC): позволяет обрабатывать одновременные транзакции без блокировок.
• Автоматическое шардирование: система сама определяет, как разбить данные на части (шарды) и распределить их по узлам.
• Репликация: данные копируются на несколько узлов для отказоустойчивости.

Сравнение с другими классами СУБД

Применение

NewSQL-системы используются в сценариях, где требуется высокая пропускная способность транзакций и строгая согласованность данных:

• Финансовые системы: обработка платежей, биржевые торги, управление рисками. Например, VoltDB используется для анализа потоков данных в реальном времени.
• Электронная коммерция: управление заказами, инвентаризация, ценообразование. Amazon Aurora применяется в Amazon.com для обработки миллионов транзакций в день.
• Телекоммуникации: биллинг, управление подписками, мониторинг сети. CockroachDB используется для хранения метрик и конфигураций.
• Игровая индустрия: сохранение состояний игр, рейтинги, внутриигровые транзакции. Google Spanner применяется в Pokémon GO для синхронизации данных миллионов игроков.
• Облачные сервисы: базы данных как услуга (DBaaS). Например, Google Cloud Spanner предоставляется как управляемый сервис.

Преимущества и недостатки

Преимущества

• Высокая производительность: in-memory обработка и распределённая архитектура обеспечивают задержки менее 1 мс.
• Автоматическое масштабирование: добавление узлов происходит без остановки работы.
• Совместимость с SQL: разработчики могут использовать привычные инструменты и навыки.
• Отказоустойчивость: репликация и протоколы консенсуса гарантируют сохранность данных при сбоях.

Недостатки

• Высокая сложность: настройка и администрирование распределённых систем требуют квалифицированных специалистов.
• Стоимость: in-memory СУБД требуют больших объёмов оперативной памяти, что увеличивает затраты на оборудование.
• Ограниченная поддержка аналитики: NewSQL оптимизированы для OLTP, но не подходят для сложных аналитических запросов (OLAP), где лучше работают колоночные СУБД (например, ClickHouse).
• Молодость экосистемы: по сравнению с классическими RDBMS, NewSQL-системы имеют меньше инструментов, документации и сообществ.

Критика

Основная критика NewSQL связана с тем, что системы этого класса не всегда достигают заявленной производительности в реальных условиях. Например, распределённые транзакции с ACID-гарантиями могут приводить к значительным задержкам при большом числе узлов (эффект «сетевого шума»). Кроме того, некоторые эксперты отмечают, что NewSQL — это скорее эволюция, а не революция: многие решения (например, Amazon Aurora) являются оптимизациями классических RDBMS, а не принципиально новыми системами. Также существует мнение, что для большинства приложений достаточно традиционных СУБД с правильной архитектурой (например, шардирование на уровне приложения).

Интересные факты

• Google Spanner использует для синхронизации времени специальные атомные часы и GPS-приёмники, что позволяет достичь точности синхронизации до нескольких миллисекунд.
• CockroachDB названа в честь таракана (cockroach) из-за её устойчивости к сбоям: система может выжить при отказе любого отдельного узла.
• В 2020 году компания MemSQL переименовалась в SingleStore, чтобы подчеркнуть поддержку как транзакционных, так и аналитических нагрузок (HTAP).

Источники

• Asay, M. (2011). «NewSQL: The Next Generation of Databases». 451 Group.
• Stonebraker, M. (2012). «NewSQL: An Alternative to NoSQL and Old SQL for New OLTP Apps». Communications of the ACM.
• Corbett, J. C., et al. (2012). «Spanner: Google’s Globally-Distributed Database». Proceedings of OSDI.
• «CockroachDB: The Resilient SQL Database». Cockroach Labs Documentation.
• «Amazon Aurora: MySQL and PostgreSQL Compatible Relational Database». AWS Documentation.
• «VoltDB: In-Memory Database for Real-Time Applications». VoltDB Technical White Paper.