NewSQL

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

Источник

Data Scientist # 1

Машинное обучение, большие данные, наука о данных, анализ данных, цифровой маркетинг, искусственный интеллект, нейронные сети, глубокое обучение, data science, data scientist, machine learning, artificial intelligence, big data, deep learning

Данные — новый актив!

Эффективно управлять можно только тем, что можно измерить.
Copyright © 2016-2021 Data Scientist. Все права защищены.