По мере роста применения средств работы с Большими Данными к СУБД предъявляются все более высокие требования с точки зрения производительности и масштабируемости. На протяжении последних четырех десятков лет реляционные СУБД играли ключевую роль во многих областях деятельности, однако современным приложениям нужна функциональность, не свойственная этим системам, в том числе возможность изменения схем, а также поддержка многообразия типов и моделей данных. Помимо  этого,  новым СУБД нужно уметь элегантно, экономично и автоматически масштабироваться. Элегантность — возможность добавления узлов по мере роста объемов данных для сохранения гарантированной скорости выполнения запросов. Автоматизм — способность сбалансированно распределять данные по мере добавления узлов. А благодаря экономичности затраты на развертывание должны снижаться по мере совершенствования аппаратного обеспечения. Иначе говоря, экономия, достигнутая за счет снижения затрат на вычисления и хранение, распространяется на общую стоимость внедрения и эксплуатации СУБД.

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

Системы NoSQL бывают операционными и аналитическими (см. врезку). О первых говорят редко, и их особенности известны хуже [1], хотя системы NoSQL стремительно развиваются и функциональные границы между ними стираются. Начали появляться системы, поддерживающие многие модели данных, и эта тенденция сохранится, причем ожесточенная конкуренция на рынке СУБД позволяет предположить, что разработчики продуктов NoSQL будут расширять круг их применений, заполняя пустые ниши.

   

Классы систем NoSQL

Реляционные базы данных обычно используются либо для оперативной обработки транзакций (Online Transaction Processing, OLTP), либо в системах поддержки принятия решений (Decision Support System, DSS). Рабочие задачи OLTP обычно состоят из кратких запросов, требующих считывания или обновления небольшого количества кортежей или записей. Пример такой задачи — система ввода заказов, размещающая в базе записи о новых заказах и извлекающая существующие. Задачи DSS состоят из сложных запросов, требующих просмотра, соединения или агрегации данных из одной или более таблиц. Например, анализ тенденций продаж обычно выполняется с помощью движка DSS.

Системы  NoSQL  по  аналогии  тоже можно разделить на два основных класса: операционные, соответствующие СУБД для OLTP, и аналитические, соответствующие СУБД для DSS. Подобно реляционным системам OLTP, операционные системы NoSQL являются транзакционными. К ним относятся Aerospike, Cassandra, Couchbase, DynamoDB, HBase, MarkLogic, MongoDB, Oracle NoSQL, Redis и Riak. В отличие от них, аналитические системы NoSQL основаны на MapReduce, Hadoop и Spark. Так же как и реляционные СУБД, аналитические и операционные системы NoSQL имеют свои области применения и в значительной степени присутствуют на независимых рынках.

 

Определяющие особенности

Из рисунка можно понять, какие характеристики привлекают заказчиков в системах NoSQL.

 

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