Операционные СУБД NoSQL: сегодня и завтра

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

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

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

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

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

Текущие характеристики и прогнозируемые направления развития систем NoSQL

Главные общие черты

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

Изменяемые схемы. Во многих современных приложениях схема данных часто меняется. К примеру, при сохранении информации из пользовательского профиля в платформе адресной рекламы число атрибутов пользователя с поступлением новых сведений о нем меняется. Другой пример — сбор данных о пользовательской активности на торговых онлайн-площадках вроде eBay или Craigslist. По мере изменения приложений, на которых базируются эти площадки, сохраняется все больше данных в расчете на каждого пользователя и каждое его действие. Согласно нормативным требованиям,  могут  также понадобиться запись дополнительной информации и хранение старой в течение определенного периода времени. Управление подобными данными с помощью традиционных реляционных СУБД, не предполагающих изменения однажды созданной схемы,  невозможно:  в достаточно сложной среде даже для простого изменения схемы,  например  для добавления одного столбца, может потребоваться неделя. В системах NoSQL этой проблемы  нет:  в них часто используется документная модель данных, когда база представляет собой коллекцию документов, или модель «ключ-значение», в которой данные представлены в виде соответствующих пар. В таких системах можно вначале загрузить данные, а уже потом определять и переопределять схемы. Гибкие модели данных позволяют, например, держать в одной и той же коллекции две записи с переменным числом описательных атрибутов. Процессы управления  данными (например,  контроль изменений и версий  схем)  протекают проще, а времени на внедрение новой функциональности требуется гораздо меньше.

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

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

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

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

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

В строгих соглашениях об уровне обслуживания (service-level objectives, SLO) нередко диктуется необходимость обеспечения высокой доступности и быстродействия в круглосуточно активных средах — эти требования выполняются путем автоматического сегментирования данных, балансировки нагрузки и аварийного переключения с использованием тиражирования. Поддержка соответствующих функций должна быть изначально встроена в платформу обработки данных, а не реализована после основной разработки. Кроме того, эти функции должны автоматически адаптироваться при увеличении или уменьшении кластера.

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

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

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

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

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

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

Дополнительные особенности

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

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

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

Системы NoSQL нередко используются приложениями, сохраняющими информацию о состоянии в таких структурах, как списки и упорядоченные множества. К примеру, в игре нужно вести учет показаний доски рекордов. Если модель данных NoSQL поддерживает упорядоченные множества в качестве объекта первого класса, то историю показаний доски рекордов можно будет без проблем сохранять в базе. Многие системы NoSQL поддерживают такие структуры данных, как счетчики, списки, стеки, карты, кэши и упорядоченные множества [2, 3]. Благодаря этому приложения могут сохранять информацию о состоянии для каждого пользователя в базе и легко обращаться к ней.

Направления дальнейшей работы

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

Контролируемая согласованность

Ранние системы NoSQL обычно не отвечали стандартным требованиям к транзакционным системам  —  ACID (atomicity, consistency, isolation, durability —  атомарность,  согласованность, изолированность,  долговечность),  применяя вместо этого модель BASE (basic availability, soft state, eventual consistency —  базовая  доступность, негарантированное сохранение состояния и   возможная согласованность).  Эта модель предъявляет менее строгие требования к согласованности, допуская временное расхождение копий одних и тех же данных, вследствие чего в определенных ситуациях увеличивается доступность распределенной системы. Но нередки случаи, когда системы NoSQL обеспечивают ограниченное соответствие ACID, а СУБД Google Spanner довольно близко подходит к полному выполнению требований к транзакционным системам. Сегодня наблюдается тенденция к обеспечению поддержки нескольких моделей согласованности, что предоставляет приложению возможность выбирать различные компромиссы. В каком-то смысле такой отход от BASE-согласованности — это заимствование у традиционных СУБД, в которых издавна существует возможность варьирования уровней согласованности.

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

Бесконфликтное тиражирование структур данных

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

Ускорение за счет возможностей оборудования

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

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

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

Универсальность

Некоторые специалисты по СУБД считают, что универсальность недостижима и для каждого класса приложений необходимо разрабатывать свои движки по обработке данных. Но внедрять слишком много платформ данных в пределах одного предприятия  непрактично:  наличие отдельной платформы для различных документных хранилищ, приложений, работающих с ключами и значениями, поточными данными, а также для поддержки разных видов аналитической обработки (графы, реляционная модель и  т. д.)  усложнит администрирование, при этом вырастет общая стоимость развертывания, снизятся темпы внедрения новых приложений и сервисов, работающих с данными. При наличии N платформ данных накладные расходы на синхронизацию всех систем и обеспечение единства обзора данных предприятия растут со скоростью N² . Одно из решений — объединение нескольких функционалов в одной системе NoSQL, например интеграция Apache Solr и Cassandra. Распространена также интеграция Hadoop с аналитическими  системами:  многие операционные базы  NoSQL  как  минимум  поддерживают возможность обмена данными с файловой системой HDFS.

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

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

Эталонные тесты и стандартизация

Появление в 1980-х годах э талонных тестов оценки реляционных СУБД заставило разработчиков этих систем сфокусироваться на производительности, что со временем принесло свои плоды. Аналогичные инициативы могут помочь и NoSQL, однако здесь имеются сложности с разработкой теста, точно воспроизводящего характеристики среды, в которой работает NoSQL-система, а также с получением поддержки тестов со стороны широкого круга поставщиков NoSQL-систем. Стоит отметить, что такие системы нередко классифицируют по следующим перекрывающимся подкатегориям: документные хранилища (MongoDB и MarkLogic), поколоночные хранилища (Cassandra и HBase) и хранилища пар «ключ-значение» (Aerospike, Couchbase, Oracle NoSQL, Redis и Riak). Для каждой подкатегории существуют свои сферы применения, однако не исключена возможность создания единого эталонного теста, который охватывал бы все сценарии, особенно с учетом прогнозируемой консолидации  функционала  СУБД NoSQL.

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

***

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

Литература

1. D. Feinberg, M. Adrian. The OLTP DBMS Market Becomes the Operational DBMS Market. Gartner, May 2013. URL: http://www.gartner.com/doc/2498715/oltp-dbms-market-operational-dbms (дата обращения: 18.09.2016).
2. Aerospike. Large Data Types Guide. 2015. URL: http://www.aerospike.com/docs/guide/ldt_guide.html (дата обращения: 18.09.2016).
3. DataStax. CQL for Cassandra: Using Collections. 2015. URL: http://www.datastax.com/documentation/cql/3.1/cql/cql_using/use_collections_c.html (дата обращения: 18.09.2016).

Джигнеш Пател (jignesh@cs.wisc.edu) — профессор, Университет штата Висконсин.