NewSQL (англ. новый SQL) — класс современных реляционных СУБД, стремящихся совместить в себе преимущества NoSQL и транзакционные требования классических баз данных. Данный термин был предложен в 2011 году Мэтью Аслетом, аналитиком 451 Group. Потребность в данных системах возникла в первую очередь у компаний, работающих с критическими данными (например, финансового сектора), которым требовались масштабируемые решения, в то время как решения NoSQL не могли предоставить транзакций и не отвечали требованиям надёжности данных.
Наиболее популярным подходом является создание принципиально новых платформ для хранения данных. Подобные решения проектируются изначально с расчётом на распределённую архитектуру и многопоточность. Примерами данных систем являются:
- Spanner
- Clustrix
- OrientDB
- VoltDB
- MemSQL
- SQLFire и GemFire XD от Pivotal
- SAP HANA
- FoundationDB
- NuoDB
- TransLattice
- ActorDB
- Trafodion
- CockroachDB
Новые механизмы хранения SQL
Данный тип решений предоставляет новые принципы хранения данных, которые масштабируются лучше чем, например, InnoDB. Примеры подобных решений:
- Infobright
- TokuDB
Данные системы добавляют новый средний слой, призванный скрыть распределённую суть хранимых данных. Примеры:
- dbShards
- Scalearc
- ScaleBase
Недостатки NoSQL
В чем главные «фишки» «широко известной в узких кругах» технологии NoSQL (aka «не только SQL»)? Во-первых, это проектирование с учетом масштабирования и линейная масштабируемость, когда добавление нового узла повышает производительность всей системы. Во-вторых, это скорость: по сравнению с предшественниками, время отклика системы примерно в 100 раз меньше (и измеряется в миллисекундах вместо сотен миллисекунд). В-третьих, это принципиальные изменения в наборе свойств: если для РСУБД необходима ориентация на требования ACID (атомарность, согласованность, изолированность, надежность), то для NoSQL эти требования заменяются так называемым набором BASE:
- Базовая доступность (Basic Availability) гарантирует завершение каждого запроса.
- Гибкое состояние (Soft state) – состояние системы может изменяться вне зависимости от того, были ли введены новые данные, или нет.
- Согласованность в конечном счете (Eventual consistency) означает, что данные могут какое-то время находиться в несогласованном состоянии, но обязательно приходят к нему после.
Так в чем же проблема? Почему NoSQL плохо приживается в сфере бизнеса? Ответ лежит на поверхности: предприятия используют РСУБД именно потому, что транзакционные системы и требования ACID удовлетворяют их нуждам. Довольно «туманные» перспективы, которые обещает масштабируемость – вроде увеличения производительности – не кажутся достойными того, чтобы ради них жертвовать надежным сервером и проверенной реляционной системой, а также серьезными финансовыми вложениями в разработку собственных API для связи узлов распределенной системы с мейнфреймом. К тому же, в некоторых сферах – той же банковской – без транзакций не обойтись вообще. А данные тем временем «растут», и необходимость в распределенных системах вместе с ними. Как быть?
Почему NewSQL?
Относительно новая концепция NewSQL призвана решить эту проблему, объединив преимущества реляционных БД с распределенной архитектурой.
- приложения взаимодействуют в основном посредством SQL;
- транзакции полностью поддерживают требования ACID;
- при управлении не применяется механизм блокировок – таким образом, исключается вероятность конфликта между записываемыми и считываемыми в реальном времени данными;
- архитектура shared—nothing, при которой каждой узел системы отвечает за свой набор данных, являясь независимым и самодостаточным, подразумевает легкую и быструю масштабируемость;
- производительность узла СУБД на NewSQL намного выше, чем у традиционных РСУБД;
- скорость отклика системы в 50 раз превышает эту величину у традиционных РСУБД.
Такое решение может понравится всем: специалистам – потому что новая архитектура надежна и вместе с тем работает гораздо быстрее и производительнее, чем «классика» РСУБД, администраторам – потому что поддерживать работу такой распределенной системы гораздо проще; наконец, предпринимателям – потому что обеспечение работы распределенной системы в ее классическом понимании требует больших вложений – решив же отдать предпочтение CУБД на NewSQL, можно уберечь себя от лишних временных, денежных и даже кадровых затрат. А поскольку «общаться» c системой можно будет все на том же SQL, перейти на нее, по крайней мере, специалистам по работе с данными, будет не слишком трудно.
Резюме и итоги
Технические характеристики решений NewSQL
- SQL как основной механизм для взаимодействия.
- ACID поддержка транзакций.
- Механизм управления без применения блокировок, таким образом считывающие данные в реальном времени не будут находится в противоречии с записывающими, что исключает конфликт.
- Архитектура, обеспечивающая намного выше производительность узла, чем доступный из традиционных решений RDBMS.
- Удобное масштабирование, способное управлять большим количеством узлов, не перенося узкие места.
Разработчики проекта утверждают, что системы NewSQL приблизительно в 50 раз быстрее, чем традиционный OLTP RDBMS.
Классификация NewSQL
Классификация основана на различных подходах, принятых сохранить SQL интерфейс, а также решить масштабируемость и производительность, являющиеся проблемами традиционных решений OLTP.
- Новые базы данных: NewSQL система разрабатывается полностью с нуля с целью достижения масштабируемости и производительности. Одним из ключевых факторов в повышении производительности является использование оперативной памяти или новых видов дисков (флэш-память/SSD), которые являются хранилищем первичных данных. Данное решение может осуществляться программно (VoltDB, NuoDB) либо на уровне железа (Clustrix, Translattice) Примеры разработок являются Clustrix, NuoDB и Translattice (коммерческие) и VoltDB, (Open Source).
- Новый движок базы данных MySQL: MySQL — часть стека LAMP и используется в OLTP. Чтобы преодолеть проблемы масштабируемости MySQL, было создано ряд движков основанных на MySQL. Положительная сторона — использование интерфейса MySQL, но есть плохая сторона — не поддерживается миграция данных из других баз данных (включая старый MySQL). Примеры реализации — Xeround, GenieDB (коммерческие) TokuTek; и Akiban, MySQL Группа NDB и др. (opensource).
- Прозрачное объединение в кластеры: Эти решения сохраняют базы данных OLTP в своем оригинальном виде, но обеспечивают особенность расширения, с прозрачной группировкой и гарантироующую масштабируемость. Другой подход должен обеспечить прозрачный sharding, чтобы также улучшить масштабируемость. БД Schooner MySQL, Continuent Tungsten и ScalArc следуют первому подходу, тогда как ScaleBase и dbShards следуют второму подходу. Оба подхода позволяют повторное использование существующих наборов и экосистемы, и избегают потребности переписать код или выполнить любые миграции данных. Примеры реализаций — ScalArc, Schooner MySQL, dbShards (коммерческий) ScaleBase; и Continuent Tungsten (opensource).
Вывод
Новое поколение систем управления информацией, которые носит название NewSQL, соответствует этой тенденции и ограничениям. NewSQL склонен для фирм, которые планируют:
- миграцию существующих приложений для адаптации к новым тенденциям роста объема данных
- разработку новых приложений на хорошо масштабируемых системах OLTP
- полагаясь на имеющиеся знания использования OLTP