NewSQL и выбор хранилища под задачу

Финальный урок: как примирить ACID с масштабом (NewSQL) и как осознанно выбирать хранилище, не поддаваясь хайпу.

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

Где мы и куда пришли

Это завершающий урок курса, и стоит окинуть взглядом весь путь. Мы начали с того, зачем нужны базы и СУБД, и поднялись по уровням абстракции. Разобрали реляционную модель строго — отношения, ключи, целостность. Увидели, как из теории множеств вырастает язык запросов (реляционная алгебра) и его практическое воплощение (SQL). Научились проектировать: от ER-модели к таблицам, от функциональных зависимостей к нормальным формам без аномалий. Поняли, как база остаётся корректной под нагрузкой — транзакции, ACID, изоляция, восстановление. Спустились на физический уровень — страницы, индексы, оптимизатор. И вот теперь, на вершине, смотрим за пределы реляционной модели: где её границы и что предлагает современный ландшафт. Этот последний урок — синтез: он связывает всё пройденное с практическим вопросом «какую базу выбрать», который встаёт перед каждым инженером. Знание теории здесь окупается напрямую: выбор хранилища — это применение всех понятий курса разом.

Зачем понадобился NewSQL

Мы увидели вилку: реляционные базы дают строгие гарантии (ACID), но трудно масштабируются горизонтально; NoSQL легко масштабируется, но часто жертвует согласованностью и SQL. Долгое время казалось, что выбирать приходится между «корректно, но не масштабируемо» и «масштабируемо, но без гарантий». NewSQL — попытка взять лучшее из обоих миров: и ACID-транзакции с SQL, и горизонтальное масштабирование на множество узлов.

Достигается это новыми архитектурами: умное автоматическое распределение данных по узлам (шардирование), распределённые протоколы согласования (например, на основе алгоритмов консенсуса), специальные часы и протоколы для упорядочивания транзакций между серверами. Примеры NewSQL: Google Spanner, CockroachDB, YugabyteDB, TiDB, VoltDB. Для приложения это выглядит как обычная SQL-база с транзакциями — но под капотом данные живут на десятках машин.

Как NewSQL держит ACID при распределённости

Стоит чуть приоткрыть, как именно NewSQL добивается, казалось бы, несовместимого — и масштаба, и ACID. Ключевых приёмов несколько. Автоматическое шардирование: данные прозрачно разбиваются на части (шарды) по узлам, причём СУБД сама решает, где что лежит, и сама направляет запросы — приложение видит единую базу. Распределённый консенсус: чтобы несколько узлов согласованно зафиксировали транзакцию, применяют алгоритмы консенсуса (вроде Raft или Paxos), которые гарантируют единое решение даже при отказе части узлов. Глобальное упорядочивание транзакций: чтобы понимать, какая транзакция «раньше», используют синхронизированные часы или логические метки времени (знаменитый пример — TrueTime в Google Spanner, опирающийся на атомные часы). Вместе это даёт иллюзию одной согласованной ACID-базы поверх десятков машин. Цена — сложность инфраструктуры и неизбежные задержки распределённой координации. Но для приложений, которым одновременно нужны и строгие транзакции, и масштаб за пределами одного сервера, NewSQL закрывает разрыв, который раньше заставлял выбирать одно из двух.

Полиглотная персистентность

Зрелый взгляд на хранение данных таков: не существует одной базы на все случаи. В одном приложении разумно использовать несколько хранилищ, каждое под свой тип данных и нагрузки. Этот подход называют полиглотной персистентностью (polyglot persistence).

Для интернет-магазина это может выглядеть так:

• заказы, платежи, остатки — в реляционной (или NewSQL) базе ради ACID и целостности;
• каталог товаров с гибкими характеристиками — в документной базе;
• корзины и сессии пользователей — в хранилище ключ-значение ради скорости;
• рекомендации «с этим товаром покупают» — в графовой базе;
• полнотекстовый поиск по товарам — в специализированном поисковом движке.

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

Сводная карта классов хранилищ

Соберём весь ландшафт в одну картину, чтобы он улёгся целостно. Есть три больших класса, и каждый занимает свою нишу по двум осям — «сила гарантий» и «лёгкость масштаба».

• Классические реляционные СУБД (PostgreSQL, MySQL, Oracle): максимум гарантий (ACID, целостность, богатый SQL), но трудное горизонтальное масштабирование. Ниша — большинство приложений умеренного и среднего масштаба с важной целостностью.
• NoSQL (Redis, MongoDB, Cassandra, Neo4j): лёгкий масштаб и гибкость ценой ослабленных гарантий (часто BASE) и специализации под модель данных. Ниша — огромные объёмы, гибкая схема, специфические модели доступа (ключ, документ, столбцы, граф).
• NewSQL (Spanner, CockroachDB, YugabyteDB): попытка совместить ACID и масштаб ценой сложности инфраструктуры. Ниша — приложения, которым нужны и строгие транзакции, и распределённость за пределами одного сервера.

Эта карта — не таблица «что круче», а пространство выбора. Каждая точка на ней хороша под свои требования. Зрелый инженер не «выбирает лучшее», а находит на карте точку, ближайшую к требованиям конкретной задачи, — и нередко использует несколько точек сразу.

Как выбирать хранилище: практические критерии

Чтобы выбор был осознанным, задайте себе несколько вопросов.

• Какова структура данных? Чёткая схема со связями → реляционная. Самодостаточные документы → документная. Связи в центре → графовая. Просто доступ по ключу → ключ-значение.
• Нужны ли строгие транзакции (ACID)? Деньги, заказы, учёт → да, нужна реляционная или NewSQL. Лента, метрики, кеш → можно итоговую согласованность.
• Какой масштаб и нагрузка? Умеренный объём → классическая RDBMS. Десятки терабайт и тысячи узлов → NoSQL или NewSQL.
• Какие запросы преобладают? Сложные соединения и аналитика → реляционная. Точечный доступ по ключу → ключ-значение. Обходы связей → графовая.
• Что важнее при сбое сети — согласованность или доступность? Вспомните CAP и выбирайте CP- или AP-систему под требования.

Реляционная теория полезна везде

Может возникнуть ощущение, что NoSQL и NewSQL обесценили теорию из предыдущих разделов. Это глубоко неверно — и стоит проговорить, почему. Понятия, которые мы изучили, работают и за пределами реляционных баз. Нормализация и избыточность: проектируя документную схему, вы постоянно решаете, что продублировать, а что вынести, — это ровно те компромиссы из раздела про нормализацию, только принятые сознательно в пользу денормализации. Транзакции и ACID: чтобы понять, что именно ослабляет NoSQL и что возвращает NewSQL, нужно твёрдо знать, что такое атомарность и изоляция. CAP и согласованность: выбор AP/CP осмыслен только если вы понимаете, что такое согласованность и чем грозит её отсутствие. Индексы и стоимость: любая база, реляционная или нет, борется за число обращений к диску. Так что реляционная теория — это не «технология одного семейства», а понятийный фундамент для рассуждения о любых данных. Освоив её, вы получили не набор фактов про таблицы, а способ думать о хранении данных вообще.

Главный практический вывод курса

Реляционная модель остаётся разумным выбором по умолчанию для большинства приложений: у неё строгая теория, зрелые инструменты, ACID и мощный SQL. NoSQL и NewSQL — не замена, а специализированные инструменты для конкретных задач, где реляционная модель упирается в свои границы. Главная ошибка — выбирать базу по моде («все берут MongoDB»), а не по требованиям данных. Теория, которую вы прошли — реляционная модель, нормализация, транзакции, индексы, — это фундамент, на котором стоит и грамотный выбор, и грамотное использование любого хранилища.

Типичные заблуждения

• «NewSQL — это просто быстрый SQL». Нет: его суть — сохранить ACID и SQL при горизонтальном масштабировании на множество узлов.
• «Надо выбрать одну базу на всё приложение». Зрелые системы используют полиглотную персистентность — несколько хранилищ под разные данные.
• «Реляционная модель устарела». Она остаётся выбором по умолчанию; NoSQL/NewSQL дополняют её, а не отменяют.
• «Выбор базы — вопрос моды». Это инженерное решение по требованиям: структура данных, транзакции, масштаб, запросы, поведение при сбоях.

Итог

• NewSQL совмещает ACID и SQL реляционной модели с горизонтальным масштабированием NoSQL (Spanner, CockroachDB).
• Полиглотная персистентность — использование нескольких хранилищ в одном приложении под разные данные.
• Хранилище выбирают по структуре данных, потребности в транзакциях, масштабу, типу запросов и поведению при сбоях.
• Реляционная модель — разумный выбор по умолчанию; NoSQL и NewSQL дополняют её под специальные задачи.