До недавнего времени реляционные СУБД оставались главным инструментом управления данными на предприятиях, которым нужно ежедневно обрабатывать миллионы запросов. По оценкам IDC, объем рынка таких СУБД в 2011 году составлял 26 млрд долл., а в 2016-м достиг 41 млрд долл. [1]. Такую популярность им обеспечил SQL — декларативный язык запросов, с помощью которого пользователи любой квалификации могут оперировать данными. Реляционные СУБД поддерживают средства контроля целостности данных, аутентификацию, ролевой контроль доступа, резервное копирование и восстановление данных, а также отвечают требованиям ACID (atomicity, consistency, isolation, durability — атомарность, согласованность, изоляция и долговечность). Однако эти СУБД не всегда подходят для решения задач Больших Данных, типичных для современных приложений. Социальные сети, к примеру, требуют выполнения миллионов операций считывания и миллиардов операций записи в режиме, близком к реальному времени. Для этих приложений появились альтернативные СУБД — NoSQL, NewSQL и Not-Only SQL, различающиеся по своим возможностям обработки массивов данных и по пропускной способности [2, 3]. В Facebook, с использованием механизма кэширования в памяти, была создана распределенная система «ключ-значение», которая содержит триллионы записей и обрабатывает миллиарды запросов в секунду.

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

По состоянию на начало 2016 года существовало почти 300 различных СУБД, в том числе реляционных, NoSQL и NewSQL, и регулярно появляются новые. Реляционные основаны на одной модели данных и пользуются стандартным языком, поэтому их функциональность прогнозируема, а у систем NoSQL могут различаться модели данных, языки запросов, способы поддержки транзакций, интерфейсы программирования и функции безопасности. Соответственно, их функциональность варьируется и нередко перекрывается — это обусловлено тем, что на рынке больше шансов выжить имеют системы, обладающие универсальными возможностями.

По прогнозу аналитиков Market Research Media, доход от NoSQL-решений за период с 2013 по 2018 год составит 14 млрд долл. — системы NoSQL теснят крупных поставщиков реляционных СУБД, заставляя их вводить в свои решения все новые функции под угрозой риска потери клиентов. Рыночную ситуацию усложняют поставщики СУБД NoSQL, развивающие свои системы форсированными темпами и вводящие произвольные новшества. Кроме того, соперничество между традиционными поставщиками СУБД и разработчиками NoSQL подогревается стремительным развитием продуктового ландшафта, приводя к борьбе за влияние и раздуванию маркетинговой шумихи, а также к разногласиям в терминологии и классификации систем. Разобраться в этом хаосе помогут обзор доступных сегодня систем и рекомендации по выбору лучшей для решения конкретных задач.

Отличия от реляционных систем

Чтобы сделать выбор между системами NoSQL, требуется понимание предпосылок их появления, а также отличий разработки приложений для NoSQL и реляционных СУБД.

Бизнес-факторы и потребности приложений

Современный бизнес, работающий с Большими Данными, Web 2.0 и мобильными приложениями,...

Это не вся статья. Полная версия доступна только подписчикам журнала. Пожалуйста, авторизуйтесь либо оформите подписку.
Купить номер с этой статьей в PDF