Ренессанс СУБД: проблема выбора

До недавнего времени реляционные СУБД оставались главным инструментом управления данными на предприятиях, которым нужно ежедневно обрабатывать миллионы запросов. По оценкам 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 и мобильными приложениями, интересуют следующие о сновные характеристики СУБД : производительность, масштабируемость и цена. Бизнесу нужны прогнозная аналитика реального времени, персонализация, динамичное ценообразование, превосходное клиентское обслуживание, средства распознавания мошенничества и аномалий, возможность отследить статус выполнения заказа по цепочке поставок и анализ протоколов доступа к веб-серверу. Все эти задачи требуют приоритета операций вставки и извлечения, которые совершаются в огромных объемах. Операции обновления и удаления между тем либо вообще не используются, либо их доля невелика.

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

Современным приложениям требуются следующие возможности: простое тиражирование данных для обеспечения высокой доступности; встроенная поддержка версионного контроля и компрессии; выполнение запросов почти в реальном времени; наличие нескольких методов опроса, включая REST-API и сложные произвольные запросы; интерактивная обработка произвольных запросов, для чего нужны системы поддержки массово-параллельных вычислений наподобие MapReduce.

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

Системы NoSQL в той или иной степени отвечают этим характеристикам. Они масштабируемы: данные хранятся и управляются, будучи распределенными между узлами одного или нескольких кластеров, которые можно легко горизонтально масштабировать путем добавления серверов стандартной архитектуры. В некоторых системах для достижения необходимого быстродействия используется MapReduce, а многие системы позволяют менять схемы по мере добавления новых данных. Большинство NoSQL-систем имеют открытый код.

Функциональность систем варьируется в больших пределах и быстро развивается, поэтому прямое сравнение по этому критерию затруднительно. В табл. 1 перечислены характерные примеры систем с открытым кодом, отвечающих высоким требованиям к масштабированию и быстродействию.

Таблица 1. Примеры систем NoSQL, отвечающих современным требованиям к быстродействию и масштабируемости

Бизнес-факторы, стимулировавшие развитие систем NoSQL, привели также к появлению поколоночных реляционных СУБД и систем NewSQL. Первые основаны на оптимизированных движках хранения, обеспечивающих высокую эффективность операций считывания, необходимую приложениям оперативной аналитической обработки (OnLine Analytical Processing, OLAP). Некоторые системы NewSQL изначально рассчитаны на работу в распределенном кластере, узлы которого не имеют совместно используемых ресурсов. В других есть слой связующего ПО для секционирования, автоматически разбивающий данные между несколькими узлами распределенного кластера. Существуют также системы, разработчики которых основное внимание уделяют высокооптимизированным движкам хранения, опрашиваемым с помощью SQL. В частности, в СУБД TokuDB для индексации применяется алгоритм фрактального дерева, поиск и последовательный доступ к которому занимают столько же времени, что и в B-деревьях, но вставки и удаления происходят намного быстрее.

Разработка приложений

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

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

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

Разработка схемы базы данных. По нормам реляционной модели архитекторы заранее разрабатывают схему данных, поэтому физическая модель данных может быть не оптимизированной для определенных запросов и транзакций, но одна и та же логическая модель оптимально подходит для любых запросов. Моделирование данных в NoSQL резко контрастирует с проверенным временем принципом независимости логической и физической схемы данных, принятым в реляционном мире. Создатели базы NoSQL, как правило, стараются идти навстречу разработчику на всех этапах написания приложения. Схему базы данных архитектор или разработчик приложения обычно проектирует начиная с идентификации запросов, которые ему нужны, а также структур данных, оптимально отвечающих требованиям этих запросов. Однако запросы приложения и схема базы данных тесно связаны, поэтому изменения в первых повлекут перемены и во второй.

Ограничения целостности. В отличие от реляционного подхода к управлению корпоративными данными, для которого свойственны контроль избыточности и обязательное соблюдение правила целостности, некоторые системы NoSQL не позволяют задавать ограничения на диапазоны значений данных.

Прозрачность архитектуры данных. Реляционные системы подразумевают прозрачность архитектурных особенностей (например, секционирования данных) для клиентских программ — СУБД раскрывают детали архитектуры данных с точки зрения производительности, но стараются скрывать их с точки зрения корректности. Некоторые системы NoSQL требуют, чтобы клиентские программы знали такие подробности. Системы «ключ-значение» дают более высокий приоритет быстродействию, нежели корректности уровня приложения. Кроме того, поскольку не все системы NoSQL имеют декларативные языки запросов, для их реализации нередко приходится писать отдельный код.

Операции соединения. Реляционные СУБД поддерживают операции объединения и двухфазного контроля завершения транзакции. В системах NoSQL для моделирования отношений «многие ко многим» используются ссылки, но такие системы не поддерживают операции соединения, необходимые для извлечения таких связей. Вместо этого они синтезируются через реализацию операции соединения в коде приложения. На нем же лежит ответственность за обеспечение двухфазного подтверждения транзакций. К сожалению, реализация того и другого в приложении мешает получению преимуществ по масштабируемости, обеспечиваемых системами NoSQL.

Согласованность. Реляционные системы обычно обеспечивают строгую согласованность данных, причем некоторые из них предоставляют возможность указания необходимой степени согласованности. Во многих NoSQL-приложениях реализован принцип согласованности для обеспечения поддержки очень быстрых операций вставки и считывания.

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

Выбор системы

Разнообразие СУБД дает руководителям больше свободы выбора, но и усложняет поиск системы, оптимально соответствующей требованиям и ограничениям конкретных приложений. Быстрая эволюция функционала систем NoSQL приводит к слиянию систем NoSQL и NewSQL и появлению многомодельных систем, дополнительно усложняя процедуру выбора. Система NoSQL MarkLogic может работать в качестве базы данных XML, документоориентированной базы, RDF-хранилища и движка для полнотекстового поиска. А FoundationDB может использоваться в качестве реляционной СУБД, хранилища «ключ-значение» и документоориентированной базы.

В общем случае задача выбора системы может показаться непосильной, однако знание определенных подробностей о данных, которыми надо управлять, может помочь в составлении списка кандидатов.

Вопросы, которыми надо при этом задаться, касаются согласованности, доступности и устойчивости к разделению (consistency, availability, partition tolerance; CAP) — главных факторов, определяющих, подходит ли СУБД для конкретного приложения. Согласованность означает, что все копии одних и тех же данных в один и тот же момент идентичны; требование доступности выполняется, когда на каждый запрос приходит ответ; а устойчивость к разделению означает, что система продолжает работать, несмотря на частичные сбои или потерю произвольного сообщения. Однако, согласно теореме CAP, распределенная компьютерная система неспособна одновременно выполнить все три требования. Например, MongoDB и Redis обеспечивают согласованность и устойчивость к разделению, но не гарантируют доступность, а DynamoDB и Cassandra обеспечивают доступность и устойчивость к разделению, но не гарантируют согласованности. Реляционные СУБД обеспечивают согласованность и доступность, отдавая им приоритет перед устойчивостью к разделению.

Поддержка каких-либо двух из трех этих качеств, согласно теореме CAP, не должна быть определяющей при выборе системы, и рассматривать их доступность следует с точки зрения наличия функций, которые обусловлены конкретными особенностями. Более того, выбор между согласованностью и доступностью может происходить внутри одной и той же системы многократно при различных уровнях детализации. Составив краткий перечень кандидатов, можно получить ответы на ключевые вопросы выбора системы, а идентификация следствий из теоремы CAP позволяет сократить список.

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

Согласно данным сайта DB-Engines, все СУБД, представленные сегодня на рынке, можно разделить на 13 категорий по трем основным классам: реляционные СУБД, NoSQL и NewSQL. Первые два класса делятся на шесть подклассов: реляционные (построчные и поколоночные), «ключ-значение», документоориентированные, базы семейств столбцов, графовые и XML. Системы NewSQL совсем недавно отделились от реляционных, став самостоятельным классом, и подклассов у них нет. В табл. 2 приведена сводка особенностей систем и характеристик приложений, подходящих для каждого подкласса.

Таблица 2. Классы и характеристики современных СУБД

Реляционные

Реляционные СУБД выдержали проверку временем с точки зрения возможности обслуживания приложений оперативной обработки транзакций (OnLine Transaction Processing, OLTP). В число стандартных функций таких СУБД входят SQL, управление транзакциями, авторизация и контроль доступа, резервное копирование и восстановление. Прежде всего поддерживаются приложения, которым нужны сохранение целостности, аутентификация и детализированный контроль доступа, а также декларативные языки запросов и транзакции.

Реляционные СУБД хорошо работают с фиксированной схемой и сохраняют целостность данных за счет ограничений и триггеров, выполняя транзакции в полном соответствии с принципами ACID. Хранимые процедуры помогают минимизировать перенос данных, выполняя расчеты внутри самой базы данных, но MapReduce они заменить не могут.

В реляционных системах высокая доступность достигается за счет тиражирования данных и секционирования между дисковыми системами, а производительность увеличивается путем вертикального масштабирования. Но такие системы могут оказаться дорогими, и у них ограниченный круг применений. В числе ограничений реляционных СУБД, мешающих использовать их для приложений Web 2.0, называют жесткость схемы и неприемлемо высокую задержку выполнения запросов. Тем не менее, как прогнозируется, доходы от реляционных СУБД в 2016 году достигнут 41 млрд долл. при рыночной доле 93%.

Движки хранения в этих СУБД обычно оптимизированы для построчной обработки — для изменения единственного значения в строке нужно получить ее всю целиком. Такая модель хранения подходит для OLTP-приложений, но сложность вычисления агрегатов по столбцам таблицы с ростом объема данных увеличивается. В поколоночных СУБД, таких как MonetDB, MonetDB/X100 и C-Store, модель хранения оптимизирована для эффективного вычисления столбцовых агрегатов, что соответствует требованиям OLAP-приложений.

По состоянию на 2016 год существует как минимум 116 коммерческих и открытых реляционных СУБД, среди которых наиболее популярны Oracle, MySQL, Microsoft SQL Server, PostgreSQL и IBM DB2.

NewSQL

Системы NewSQL, развившиеся под влиянием реляционных и NoSQL СУБД, представляют собой универсальные среды управления структурированными и неструктурированными данными. Высокая скорость обработки в них обеспечивается за счет использования оперативной памяти и твердотельных накопителей. Многие из этих систем поддерживают несколько моделей данных, но преобладает реляционная. В качестве основного языка запросов используется SQL. Типичные представители: Clustrix, VoltDB, MemSQL, NuoDB, MySQL Cluster, TokuDB и Spanner. Эти СУБД различаются системной архитектурой (master-master либо multilevel master), методами клиентского доступа, а также поддержкой транзакций, сегментирования, тиражирования и встроенных методов MapReduce. Подходящие приложения — критически зависимые от реляционных систем, но и требующие особенностей NoSQL (например, горизонтальной масштабируемости и высокого быстродействия при увеличении масштаба). В числе применений систем NewSQL — распознавание мошенничества в реальном времени, мобильная реклама, назначение расценок и перекрестные продажи в реальном времени, а также поддержка принятия геопространственных решений.

«Ключ-значение»

Системы «ключ-значение» хранят данные в виде соответствующих пар: значение (которое может быть любого типа) рассматривается как двоичные данные и хэш-функция или иная схема секционирования, преобразующая ключ в индекс. Такие схемы обычно используются в системах, хранящих упорядоченные значения на накопителях. Для движков характерны высокая скорость извлечения и независимость времени выполнения запроса от размера данных.

В числе определяющих характеристик баз «ключ-значение» — обработка Больших Данных в реальном времени, горизонтальное масштабирование, надежность и высокая доступность, причем функциональность и быстродействие варьируются в широких пределах. Эти системы тоже могут различаться по своей архитектуре (главный-главный, главный-подчиненный и клиент-сервер) и методам клиентского доступа, иметь различные характеристики обработки в памяти и поддерживать разные структуры данных. Системы «ключ-значение» также могут различаться по таким факторам, как принципы хранения на дисках, поддержка транзакций, сегментация, тиражирование и встроенные функции MapReduce. По состоянию на 2016 год существуют 52 системы «ключ-значение», самые популярные из которых — Redis, Memcached, Riak и DynamoDB.

Системы «ключ-значение» хорошо подходят для приложений, которым нужно миллисекундное время отклика и в которых основной способ опроса данных — это поиск по ключам. К таким приложениям относятся механизмы управления сеансами веб-приложений, конфигурационного управления, распределенных блокировок, средства для обмена сообщениями, персонализации обслуживания пользователя в играх и социальных СМИ, мобильные платформы, онлайн-игры, торги реального времени, серверы рекламных объявлений, рекомендательные системы, многоканальная розничная торговля.

Поколоночные СУБД

Концептуально поколоночные СУБД похожи на реляционные, но при их использовании отсутствуют накладные расходы на обработку, характерные для реляционных систем. В какой-то степени поколоночные СУБД можно также рассматривать как иерархическую систему «ключ-значение». Обработка столбцов происходит аналогично тому, как это делается в реляционных СУБД, каждый столбец имеет свой индекс. Семейство столбцов задается заранее, а сами столбцы внутри семейства — нет; семейство может содержать любое число столбцов с данными любого типа, которые можно сохранить в виде байтовых массивов. Столбцы в семействе логически связаны и физически хранятся вместе. Высокая производительность достигается за счет объединения столбцов с похожими характеристиками. При изменении значения оно сохраняется как новая версия, отличающаяся отметкой времени. Благодаря возможности частичного доступа к данным производительность некоторых приложений кардинально возрастает.

Среди поколоночных СУБД наиболее известны Cassandra и HBase; далее идут Bigtable, Apache Accumulo, Hypertable и Sqrrl. Все эти СУБД основаны на архитектуре «главный-главный» без разделения значений и различаются методами клиентского доступа, поддержкой транзакций, сегментирования, тиражирования и встроенных функций MapReduce.

Поколоночные базы могут выполнять агрегированные операции (например, высокоэффективный поиск максимумов и минимумов в больших срезах данных) и подходят для приложений, которым требуются гибкие и меняющиеся схемы данных, гетерогенность данных, работа с разреженными и нетранзакционными данными, устойчивость к временной несогласованности, версионный контроль, нативные функции MapReduce, частичный доступ к записям и высокая скорость операций вставки и считывания. Типичный сценарий использования поколоночных СУБД — это управление временными рядами в системах для отрасли финансовых услуг, и соответствующие возможности, в частности, специально реализованы в Cassandra.

Документная модель

Документоориентированные СУБД управляют квазиструктурированными данными, в основном в форме пар «ключ-значение», хранимых в виде документов JSON. Каждый документ представляет собой запись с потенциально варьирующимися атрибутами. В полях сохраняются свойства, касающиеся квазиструктурированности и отличий между документами. Для эффективного поиска по полям JSON применяется индексирование.

Ны рынке представлено более четырех десятков документоориентированных баз данных, и среди них самыми популярными по состоянию на 2016 год являются MongoDB, CouchDB, Couchbase, DynamoDB, MarkLogic и OrientDB. Они различаются по системной архитектуре, методам доступа и поддержке транзакций, а также по способам сегментирования, тиражирования и набору встроенных функций MapReduce.

Документориентированные базы подобны системам «ключ-значение»; некоторые системы, например Couchbase, имеют оба набора функций. В режиме «ключ-значение» значения хранятся в качестве непрозрачных объектов, а в документном режиме — в форме документов JSON.

Документоориентированные базы нередко интегрируются с библиотеками полнотекстового поиска и сервисами наподобие Solr, Lucene и ElasticSearch. В частности, ElasticSearch интегрируется с MongoDB и выдает отклики в режиме реального времени на запросы документов в формате JSON.

Документоориентированные базы оптимальны для приложений, нуждающихся в гибкой схеме и множестве различных типов записей (что характерно для вторичных финансовых инструментов и электронных медицинских карт); имеющих экземпляры записей с разными типами данных и большим количеством значений в одном и том же поле; работающих с документами с глубоко вложенными полями и выдающих большое число запросов с вычислением агрегатов по коллекциям документов.

Графовые базы

Графовые базы в меньшей степени рассчитаны на обработку огромных объемов данных и обеспечение высокой доступности и в большей — на работу с данными, имеющими множество связей. Вершины в графовой базе представляют объекты, а ребра моделируют отношения между ними. И у вершин, и у ребер могут быть атрибуты. Поддерживаются запросы на поиск кратчайшего пути между двумя вершинами, поиск кластеров и распознавание сообществ.

Среди более чем 20 графовых баз данных, существующих по состоянию на 2016 год, самые популярные — Neo4j, OrientDB, Titan, Virtuoso, ArangoDB и Giraph. Они различаются системной архитектурой, методами клиентского доступа и поддержкой транзакций, сегментирования, тиражирования и набором встроенных функций MapReduce.

Области применения этих систем: обработка геопространственных данных, рекомендательные системы, анализ социальных сетей и сетей, применяемых в биологии. Графовые базы также используются в индустрии грузоперевозок, в здравоохранении, розничной торговле, индустрии развлечений и в нефтегазовой отрасли. Они популярны как средство реализации подсистем контроля доступа и авторизации для приложений, обслуживающих миллионы пользователей.

XML-базы

Нативные XML-базы — это старейший и самый развитый подкласс систем NoSQL, способный хранить и опрашивать более широкий круг типов данных, чем любые другие NoSQL-базы. Они превосходно подходят для управления смешанными множествами структурированных, квазиструктурированных и неструктурированных документов и имеют декларативную расширяемую модель данных, которую можно проверить по XML-схеме или шаблону DTD (Document Type Definition). Сложную проверку корректности данных, не описываемых XML-схемой, можно провести с помощью Schematron, стандартного (ISO/IEC) языка на основе правил, который позволяет судить о присутствии или отсутствии закономерностей в XML-документах.

Термин «нативные» в названии класса систем призван отличить их от реляционных СУБД, в которых поддержка XML реализована с помощью дополнений. К таким базам относятся IBM DB2, Oracle, PostgreSQL и Microsoft SQL Server. В этих базах XML-данные хранятся в виде больших символьных объектов (Character Large Object, CLOB) или фрагментов данных, распределенных по нескольким таблицам. В некоторых системах поддерживается тип данных XML, определенный в стандарте ISO 9075-14. Запросы можно совершать с помощью языков XQuery, SQL или их сочетания. В нативных же XML-базах документы хранятся в естественной иерархической форме.

Нативные XML-базы имеют ряд встроенных средств поддержки XML, большинство из которых определены в стандартах WWW. В частности, поддерживаются языки опроса и обновления XML-данных XPath и XQuery, а расширение XPath/XQuery позволяет составлять полнотекстовые поисковые запросы в форме функций XQuery. С помощью декларативного языка XProc возможна конвейерная обработка XML-документов. Xforms — еще один декларативный язык, помогающий в создании клиентских приложений, основанных на архитектуре «модель-отображение-контроллер». Стандарт форматирования документов XSL-FO позволяет указывать формат печати, а с помощью декларативного языка XSLT можно выполнять преобразования XML-документов.

Благодаря высокому уровню стандартизации (среди перечисленных лишь XSLT еще не является стандартом W3C) нативные XML-системы сокращают время разработки приложений за счет использования единой модели данных, которая устраняет необходимость в согласовании данных между уровнями приложения и позволяет людям, не обладающим техническими специальностями, выполнять разработку и сопровождение. Применение стандартных технологий повышает переносимость приложений, а также дает возможность составления политик безопасности и контроля доступа.

Типичные представители нативных XML-баз — MarkLogic, eXist­db, BaseX, TeraText Database System, Snapbridge FDX Cross Media Server и Sedna. Они подходят для приложений, которым требуется управление смешанным контентом с помощью стандартизованных технологий. Идеальные кандидаты — приложения, имеющие дело с миллионами документов, длительными транзакциями, сложной и быстро меняющейся схемой базы и опросами иерархических данных. Области применения: мультиканальная публикация из единого источника, медицина, страхование, интеграция данных, обмен сообщениями и сайты, генерируемые на основе данных.

Что впереди?

Уровень современных СУБД и рост использования облачного хостинга способствуют инновациям в сфере управления базами данных. Разработчики традиционных реляционных СУБД реализуют все больше функций NoSQL, а разработчики систем NoSQL стараются повысить их стабильность и надежность, а также обеспечить в них поддержку транзакций. Стремительное развитие систем обоих типов и обмен функциональностями между ними постепенно сотрет границы и приведет к появлению универсальных систем, имеющих функции из многих подклассов. У одной и той же системы, к примеру, могут быть одновременно функции баз «ключ-значение», документоориентированных и графовых. Такие многомодельные СУБД станут стимулом для развития облачных баз данных, предоставляемых в виде сервиса (DBaaS).

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

С падением цен на оперативную память получат более широкое применение базы с обработкой в памяти (In-memory), что позволит компенсировать ограничения реляционных СУБД по масштабируемости и быстродействию. Системы наподобие SAP HANA, Aerospike, VoltDB и McObject уже используют преимущества обработки в памяти.

Направления исследований

Дополнительные исследования требуются в таких областях, как безопасность, работа приложений на системах, поддерживающих много моделей данных, и DBaaS.

Безопасность

Некоторые системы NoSQL рассчитаны на выполнение в доверенной среде и поэтому не требуют аутентификации при передаче открытого текста и шифрования данных на диске. Риски безопасности также связаны с авторизацией и детализированным контролем доступа. Хотя способы решения этих проблем, взятые из реляционного мира, в принципе, применимы и к системам NoSQL, их перенос затруднен в связи с различиями в моделях данных, языках запросов и методах клиентского доступа.

Поддержка многих моделей данных

Обычно в системах NoSQL используется одна модель данных, но сейчас ситуация меняется, что может создать проблемы для приложений, рассчитанных лишь на одну модель данных. Если такое приложение переключается в многомодельный режим, то нет очевидного способа опроса данных, хранимых в различных моделях. Может показаться, что это напоминает проблемы, с которыми сталкиваются при обработке запросов в распределенных базах. Но возникающие сложности на самом деле больше похожи на те, что появляются при создании универсальных сред программирования, поддерживающих мультипарадигмальные языки программирования вроде Oz.

База данных в виде сервиса

Корпоративные системы NoSQL, как правило, развертываются на централизованной или распределенной кластерной системе, но когда у организации нет специалистов по установке и эксплуатации систем NoSQL, их предпочтительно выполнять в облаке, что позволяет избежать лишних затрат. Особенности эксплуатации модели DBaaS пока не ясны, но в качестве промежуточного шага можно было бы реализовать «фасад», предоставляющий сервисы управления данными для многих моделей прозрачно через публичное или частное облако. Исследовательские достижения в области безопасности, множественных моделей данных и DBaaS помогут сделать фасадную модель реальностью.

***

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

Литература

1. C.W. Olofson. Worldwide RDBMS 2014 Vendor Analysis: Top 10 Vendor License Revenue by Operating Environment. Dec. 2015. URL: www.idc.com/getdoc.jsp?containerId=US40652015 (дата обращения: 18.09.2016).
2. M. Stonebraker et al. MapReduce and Parallel DBMSs: Friends or Foes? // Comm. ACM. — 2010. Vol. 53, N. 1. — P. 64–71.
3. M. Stonebraker. Stonebraker on NoSQL and Enterprises // Comm. ACM. — 2011. Vol. 54, N. 8. — P. 10–11.

Венкат Гудивада (gudivadav15@ecu.edu) — профессор, Дана Рао (raod15@ecu.edu) — доцент, Университет Восточной Каролины (США), Виджай Рагхаван (vijay@cacs.louisiana.edu) — профессор, Университет Луизианы (США).