Отображение моделей данных NoSQL в объектные спецификации © Н. А. Скворцов Институт проблем информатики РАН nskv@ipi.ac.ru Аннотация необходимо работать с большим количеством данных или высоконагруженными хранилищами Системы баз данных, принадлежащие к данных. классу NoSQL, используются для При решении научных задач над обеспечения горизонтального множественными информационными ресурсами масштабирования данных и работы со также приходится сталкиваться с базами данных на сверхбольшими объёмами данных. При основе NoSQL. Для интеграции базы данных в решении задач над множественными среду решения задач необходимо построить неоднородными информационными отображение схемы базы в концептуальную схему ресурсами необходимо их использовать. В задачи. С целью разрешения модельной статье рассмотрены подходы к неоднородности между спецификациями базы отображению моделей NoSQL разных данных и задачи модель данных системы баз видов в объектную модель языка СИНТЕЗ, данных NoSQL должна быть отображена в используемого в качестве унифицирующей некоторую унифицирующую целевую модель, информационной модели при решении используемую на уровне спецификаций решаемой задач в среде неоднородных ресурсов. задачи. Однако путь такого отображения не всегда Показаны общие проблемы отображения на является очевидным, так как в моделях данных примере нескольких систем баз данных систем баз данных NoSQL наряду со NoSQL и предложен подход, включающий структурированными данными могут выявление схем баз данных, не заданных присутствовать слабоструктурированные и явным образом, и отображения операций. неструктурированные, схема базы чаще всего не Рассмотрен случай, когда схему данных имеет спецификации, а предполагается неявно, восстановить невозможно из-за неполной может быть нефиксированной, изменяемой информации о структурах, хранимых в динамически, может содержать сложные базах, или слабой структурированности переплетения экземпляров данных и структурных данных. элементов. Работа выполнена при поддержке РФФИ Статья посвящена исследованию отображения (гранты 10-07-00342-а, 11-07-00402-а) и моделей данных NoSQL различных видов в Президиума РАН (программа 16П, проект 4.2). объектную модель языка СИНТЕЗ [3], используемую в качестве канонической модели 1 Введение предметных посредников для решения задач над Проекты, работающие в информационном множественными информационными ресурсами. В пространстве, сталкиваются с необходимостью разделе 2 описаны общие принципы, положенные в горизонтального распределения по узлам большого основу построения систем баз данных NoSQL и количества данных и быстрого доступа к ним. Для анализ того, как описанные принципы влияют на решения проблемы нередко прибегают к отображение моделей данных NoSQL в целевую использованию для хранения и обработки данных модель задачи. В разделе 3 приведены краткие систем баз данных, принадлежащих к классу сведения об объектной модели данных языка NoSQL [1]. К таковым причисляют хранилища СИНТЕЗ, используемой в статье в качестве целевой «ключ-значение», кортежные системы баз данных с при отображении моделей. В разделе 4 описаны колоночным хранением, документные системы баз возможности модели данных системы баз данных данных. Они использовались, в первую очередь, в «ключ-значение» Oracle NoSQL и показаны поисковых сервисах, в крупных социальных сетях, и принципы отображения данной модели в объектную сегодня применяются в тех проектах, где модель языка СИНТЕЗ, обозначены проблемы такого отображения. Разделы 5 и 6 посвящёны Труды 14й Всероссийской научной конференции исследованию системы с колоночным хранением «Электронные библиотеки: перспективные методы и Cassandra и документной системы баз дынных технологии, электронные коллекции» - RCDL-2012, MongoDB. В разделе 7 сделаны выводы об общих Переславль-Залесский, Россия, 15-18 октября 2012 г. проблемах отображения систем баз данных NoSQL 53 разных классов, о подходах к отображению моделей имеющиеся данные, даже если эти данные ожидают в тех случаях, когда не удаётся выделить обновления. Непротиворечивость обновляемых фиксированную структуру данных. данных гарантируется только конечная. Ключи и значения могут иметь различную 2 Общие принципы построения систем структуру и организовываться в различные структуры в разных системах. С точки зрения баз данных NoSQL моделей данных системы баз данных NoSQL можно Технологии NoSQL направлены на обеспечение разделить на следующие основные классы: горизонтального масштабирования и доступа к  базы данных «ключ-значение», основанные данным сверхбольших объёмов или работу с напрямую на парах ключей и значений, в высоконагруженными по чтению или обновлению которых, однако, и ключи, и значения, данными, они часто обеспечивают более возможно, будут иметь определённую приемлемую производительность простых структуру или быть слабоструктурированными; операций, чем реляционные системы баз данных.  базы данных с колоночным хранением, в Системы баз данных NoSQL, в основном, которых с одним ключом связан набор колонок пользуются следующими принципами работы с значений, имеющих имена, и таким образом, данными. имитируется табличная организация; В NoSQL произошёл отказ от табличной  документные базы данных, в которых организации данных, хранимых по кортежам, что разрешены иерархические структуры, позволяет избежать обращений к целым кортежам, основанные на вложенных парах «ключ- если необходимо прочитать только некоторые их значение», то есть, значением любой пары компоненты. Для быстрого поиска необходимых может становиться последовательность пар данных они организованы в виде пар «ключ- ключ значение. значение», для доступа к значениям по ключам Те решения, которые используются для используется принцип хеш-таблиц. Для надёжности достижения распределённости, возможности и физического распределения по узлам данные интенсивного чтения и записи, особенностей могут быть связаны с определённым узлом или обеспечения целостности данных, являются реплицироваться на несколько узлов с помощью прозрачными для пользователей, работающих с механизмов, таких как распределённые хеш- системами баз данных NoSQL. То, что имеется в таблицы (DHT) [7]. распоряжении у пользователя, включает некоторым Так как обращения производятся только по образом организованные структуры на основе пар ключам, то упрощается и язык манипулирования «ключ-значение» и обычно простой интерфейс к данными. Обычно используется набор операций, ним. подобный CRUD (Create/Read/Update/Delete) [4]. В Поэтому на отображение моделей данных зависимости от организации ключей и значений на систем баз данных NoSQL в информационную основе операций могут составляться SQL-подобные модель, используемую для решения задач над запросы, однако и они должны укладываться в множественными информационными ресурсами, обращение по ключам. влияет только организация структуры данных и Обращение по ключам вносит существенные состав операций системы. Остальные используемые ограничения в возможностях запросов, которые, в принципы: распределённое хранение, способы результате, влияют на организацию данных. В обновления данных, – скрыты за интерфейсом большинстве систем возможные разновидности системы баз данных и на отображение не влияют. запросов, используемых при решении задач, Как в традиционных системах баз данных, так и должны быть известны заранее. Те данные, по в системах баз данных NoSQL при решении задачи которым необходимо организовать поиск, должны отображения моделей строится отображение языков оказаться ключами в некоторых парах «ключ- определения и манипулирования данными. В случае значение», а искомые данные – значениями. Для моделей NoSQL модель не определяется схемой этого формируются вспомогательные пары, данных в явном виде, и отображение на уровне дублирующие данные в разной организации ключей языка определения данных сталкивается с и значений. Фактически они реализуют над отсутствием её описания. Интерфейс приложения, данными в основных парах материализованные работающего над базой, обеспечивает более взгляды, которые должны формироваться в высокий уровень семантики данных. Однако соответствии с данными в основных парах при приложения создаются для решения определённых каждом их обновлении. Таким образом, происходит задач, одна база данных может использовать в ряде сдвиг обработки запросов на этап обновления приложений, не всегда на уровне приложений данных, что усложняет обновление, но позволяет предоставляют достаточные средства доступа к быстро выполнять чтение данных. Используется данным для отображения схем и трансляции журнальная структура обновлений, при которой данных. Поэтому, несмотря на неопределённость необходимые обновления буферизуются и схемы, представляется оправданным выявление распространяются на необходимые узлы по мере структуры данных из доступных источников: кода возможности. Операции чтения используют уже приложения, документации, знаний создателя базы 54 и приложения, анализа самих данных, – и 4 Отображение модели данных «ключ- отображение моделей на уровне операций системы значение» баз данных. Отображение моделей с участием моделей Рассмотрение отображения моделей данных NoSQL, в основном, востребовано в обратном NoSQL в объектную модель языка СИНТЕЗ начнём направлении: из произвольных моделей в NoSQL. с отображения системы баз данных Oracle NoSQL При отображении реляционной модели в NoSQL [9]. Эта система относится к классу систем баз разрабатываются способы представления в NoSQL данных «ключ-значение». данных, ранее представленных в реляционной Хранимыми элементами в данной системе модели и имитация операций реляционной алгебры являются ключи и значения. Ключи являются в моделях NoSQL [6]. Отображение объектной составными и разделяются на старший ключ (major модели в NoSQL имеет целью исследовать key) и младший ключ (minor key). представление объектов при работе языков Старший ключ представляет собой программирования с базами данных NoSQL [5]. При последовательность из одного или более этом подчёркивается отсутствие дорогостоящего компонентов, являющихся строками. По старшему объектно-реляционного отображения, с каким ключу, помимо прочего, производится выбор узла в приходится сталкиваться при работе в языках кластере, так что пары, у которых старшие ключи программирования с реляционными системами баз совпадают, гарантированно будут находиться на данных. одном и том же узле. Младший ключ также является 3 Сведения об объектной модели данных последовательностью строк, однако он может быть и пустым. Вместе со старшим ключом младший языка СИНТЕЗ ключ определяет уникальное значение ключа, с Язык СИНТЕЗ [3], используемый в данной которым в базе может быть связано одно значение. статье в качестве целевого языка при отображении Значения в парах Oracle NoSQL могут быть моделей данных, является языком спецификации произвольными. Они рассматриваются как строки информационных ресурсов и включает в качестве байтов, и в них могут быть записаны данные с синтаксической основы язык фреймов, построенную любой семантикой, структурированные или над ним объектную модель и средства выражения неструктурированные, сериализованные. логических формул. Состав языка манипулирования данными Фреймы имеют идентификатор и набор слотов, соответствует упомянутому выше набору операций каждый из которых может иметь набор значений CRUD, именованных по-своему. слота. Язык фреймов позволяет специфицировать Операция put(k, v) записывает в базу значение v метафреймы, метаслоты и метазначения, которые по ключу k. Она используется одновременно для сами определяются как фреймы. Средствами языка вставки и обновления данных. В языке есть фреймов выражаются произвольные виды условные варианты данной операции: putIfAbsent – информации, в том числе, слабоструктурированные. создание пары, если такой ключ не найден в базе, Объектная модель рассматривает фреймы как putIfPresent – обновление значения, если такой ключ типизированные значения. Фрейм может отражать присутствует в базе, а также putIfVersion – для состояние объекта определённого типа, в этом работы с версиями значений. случае, его структура должна соответствовать Операция get(k) читает значение, спецификации некоторого абстрактного типа соответствующее ключу k. Операция данных. Помимо абстрактных типов данных, множественного чтения multiGet(k, r) читает пары определяющих структуру и поведение объектов, «ключ-значение», соответствующие неполному вводятся также классы как множества однотипных ключу k, задающему только часть первых объектов. Фрейм может становиться экземпляром компонентов полных ключей, в r налагаются класса, если соответствует типу экземпляров этого условия на значения компонента ключа, класса. следующего за компонентами, заданными в k. Язык формул в язык СИНТЕЗ используется для Список существующих ключей, хранящихся в предикативных спецификаций, задающих базе, не затрагивая соответствующие им значения, ограничения целостности в типах, для определения можно прочитать с помощью операции правил в логических программах и для задания multiGetKeys (k, r). запросов над спецификациями задач или Операция delete (k) удаляет из базы пару, информационных ресурсов. соответствующую ключу k. Операция Перечисленными средствами и должны быть множественного удаления multiDelete (k, r) работает выражены спецификации, отображённые из с параметрами по аналогии с операцией multiGet. моделей данных NoSQL. Подробные сведения о Приведём пример спецификации на языке Java, языке СИНТЕЗ можно почерпнуть из [3]. работающий с интерфейсом системы Oracle NoSQL. List majorComponents = new ArrayList(); List minorComponents = new ArrayList(); 55 majorComponents.add("Smith"); Поэтому в целом, если возможно отображение и majorComponents.add("Bob"); трансляция данных на уровне приложения над базой minorComponents.add("phonenumber"); данных, то предпочтительно использовать этот minorComponents.add("home"); уровень. В этом случае особенности модели NoSQL Key myKey = Key.createKey теряются за интерфейсом приложения. Если (majorComponents, minorComponents); String data = "555 5555"; приложение не позволяет это сделать, для Value myValue = Value.createValue (data.getBytes()); отображения модели данных NoSQL на уровне kvstore.put(myKey, myValue); языка манипулирования данными в модель языка ValueVersion vv = kvstore.get(myKey); СИНТЕЗ необходимо сформировать структуры, в Value v = vv.getValue(); которые будут преобразовываться данные, и String data = new String(v.getValue()); отобразить операции манипулирования данными. Интерес исследования представляет последний В данном примере определяется старший ключ случай. “Smith/Bob”, состоящий из двух компонентов, и младший ключ “phonenumber/home”, также из двух 4.1 Формирование структуры данных компонентов. Полный же ключ составляет строку: Первым делом, для отображения структур “Smith/Bob/-/phonenumber/home”. В данном случае, данных, хранящихся в базе данных модели Oracle старший ключ определяет имя и фамилию человека, NoSQL, важно понять, какие из компонентов к которому относятся данные, а младший ключ – ключей являются для объектной модели путь в структуре, описывающей вид данных об этом экземплярами (“Smith”), а какие определяют человеке, в данном случае, в значении, связанном с атрибуты структур (“phonenumber”). Для этого данным ключом записан домашний телефон необходимо разобраться в особенностях человека. использования компонентов ключей разной На языке JSON [2], который часто используется структуры. для представления пар, таким образом Наиболее верным решением может быть, если определяемые данные можно записать следующим эксперт укажет, какие из значений компонентов образом: являются фиксированными и определяют {"Smith/Bob/-/phonenumber/home": "555 5555"} структуру, а какие – данными. Для фиксированных {"Smith/Bob/-/phonenumber/mobile": "333 3333"} значений компонентов также необходимо определить, какие из них являются дочерними для Фактически ключами определяется некоторая других, то есть связанными с определёнными иерархическая структура: значением родительского компонента. Эксперт может решить эти задачи на основании анализа: Smith  примеров ключей, └ Bob  документации к базе данных, └ phonenumber  кода приложений, работающих с базой данных; ├ home: "555 5555" └ mobile: "333 3333"  «логов» операций обращения к базе. Возможна и частичная автоматизация. То, что так распределены старший и младший Интуитивно, если компонент имеет фиксированный ключи, гарантирует, что все данные об одном и том набор значений, который к тому же связан с же человеке будут всегда храниться на одном узле. единственным определённым значением другого Касательно отображения модели данных компонента, он может оказаться определяющим системы Oracle NoSQL в целевую модель, структуру данных. Такую статистику можно определённую языком СИНТЕЗ, можно заключить, набрать в самой базе, запрашивая в ней ключи. что различие между старшими и младшими Однако статистический подход может быть ключами никак не отражается на отображении. дорогостоящим и при этом не гарантировать Полный ключ рассматривается как список строк. точность результатов. В любом случае, эксперт Однако приведённый пример показывает, что должен подтвердить результаты статистического сложность отображения будет заключаться в анализа. В данной статье детали возможного семантике этих компонентов. В любом месте статистического подхода не рассматриваются. составного ключа могут быть данные (“Smith”), а После того, как выяснена природа могут быть фиксированные имена в структурах фиксированных значений компонентов ключей, данных (“phonenumber”). можно переходить к отображению структуры базы Это, в свою очередь, означает, что полностью данных. Можно выделить следующие правила автоматическое отображение в объектную модель, отображения: учитывающее такую структуру данных, 1. Связанные по структуре ключей пары организовать будет сложно. Если отображение отображаются в классы (Class1, Class2, …) и зависит от семантики строкового значения в типы их экземпляров. Если какой-либо компонентах ключей, то правильное отображение с компонент ключа фиксирован и имеет уверенностью может определить только эксперт. 56 единственное значение в подобных ключах, то Как мы выяснили, первые два компонента ключа он становится именем класса. являются нефиксированными, а последние два – 2. В соответствие компонентам ключей, имеющим фиксированными. В результате отображения нефиксированные значения, ставятся атрибуты получим следующую структуру данных: типа экземпляров класса (majorKey1, majorKey2, …, minorKey1, minorKey2, …). { class1; in: class; Значения компонентов станут при этом instance_section: { строковыми значениями атрибутов. Однако при majorKey1: String; известной семантике компонентов ключей majorKey2: String; phonenumber: Phonenumber; возможно задавать другие типы атрибутов и key: { unique; { majorKey1, majorKey2 } }; преобразование строковых значений }} компонентов ключей к ним. Атрибуты могут иметь пустое значение, если компонент ключа { Phonenumber; in: type; не определён в некоторых парах. home: String; 3. Если в качестве компонента ключа mobile: String; используется фиксированное значение, его } следует сделать атрибутом с именем, соответствующим значению компонента. Проследим, как применяются правила при этом Сопоставление атрибутов со значениями будет отображении. В соответствии с ключами с похожей задано позже. структурой создан класс class1 и тип его 4. Если для компонента с фиксированным экземпляров в разделе instance_section (применяется значением существуют дочерние правило 1 из вышеперечисленных). фиксированные компоненты, то есть, Нефиксированным компонентам ключа ставятся в фиксированные значения связаны с соответствие атрибуты majorKey1 и majorKey2 типа единственным определённым значением String (правило 2). В соответствии с первым данного родительского компонента, то фиксированным значением компонента создаётся создаётся одноимённый со значением атрибут phonenumber (правило 3). Типом значений родительского компонента абстрактный тип этого атрибута становится абстрактный тип данных данных с атрибутами, соответствующими Phonenumber, содержащий атрибуты, фиксированным значениям дочернего соответствующие фиксированным значениям компонента. Атрибут, порождённый последнего компонента ключа: home и mobile родительским компонентом, приобретает в (правило 4). Значениям пар соответствуют значения качестве типа значений созданный абстрактный атрибутов home и mobile, их типами значений тип данных. становится строка (правило 5). В типе экземпляров 5. Значение пары отображается в значение класса class1 указывается уникальность значений атрибута, соответствующего последнему пары атрибутов majorKey1 и majorKey2 (правило 6). фиксированному значению, у которого нет Здесь необходимо также отметить, что обычным дочерних компонентов. Либо, если такового не подходом в NoSQL, как уже было сказано ранее, нет, то значение пары отображается в атрибут является дублирование данных в дополнительных value. Типом значения атрибута по умолчанию парах «ключ-значение» с другой структурой ключей является фрейм языка СИНТЕЗ. Необходимо и значений, которые фактически являются знать способ преобразования значений во материализованными взглядами над теми же фреймы. Если выявить такой способ данными и служат для создания других ключей и невозможно, значения будут иметь тип Bitstring возможности задания запросов по ним. Например, языка СИНТЕЗ. Значения могут приводиться к если в базе с приведённой выше структурой любым другим типам в зависимости от их необходим поиск по номерам телефона, то в ней, известной семантики и структуры. помимо описанных пар необходимо будет создать 6. Набор всех атрибутов типа, образованных дополнительные пары, в которых номера телефонов компонентами полных ключей, указывается как являются ключами: уникальный. Если с атрибутом, соответствующим фиксированному значению {"555 5555": ["Smith", "Bob"]} компонента ключа, связано значение, соответствующее значению в паре, то включать Такие пары отображаются в уже построенные его в набор излишне. структуры, и для них не нужно создавать Приведём пример отображения в язык СИНТЕЗ дополнительные структуры, а важно разработать следующих пар «ключ-значение»: отображение операций в язык манипулирования данными целевой модели данных. Ведь присутствие {“Smith/Bob/-/phonenumber/home”: “555 5555”} таких пар расширяет разновидности возможных {“Smith/Bob/-/phonenumber/mobile”: “333 3333”} запросов, выражаемых в целевой модели, а именно, то, на какие атрибуты можно налагать условия, и 57 какие данные при таких условиях можно переименовывается в переменную v и возвращается возвращать. в классе q, являющемся ответом на запрос. Так как В худшем случае, семантика данных, хранимых пара атрибутов majorKey1 и majorKey2 уникальна, в в базе, может быть вообще не известна. В этом ответе будет возвращено одно значение, если случае отображение может строиться только исходя только значение ключа присутствует в базе. из структур, используемых для организации ключей Обратное отображение подобного запроса и значений. При этом структуры, используемые в полностью восстановит операции задания ключа и Oracle NoSQL, отображаются в структуры, обращения к базе в исходном виде. состоящие из последовательностей строковых Операция multiGet(k) передаёт в качестве значений младшего и старшего ключей и параметра фрагмент ключа и возвращает множество произвольной битовой строки в качестве значения: пар, ключи которых соответствуют данному фрагменту. { db; in: class; instance_section: { majorComponents.add("Smith"); minorKey: {sequence; type_of_element: String}; majorComponents.add("Bob"); majorKey: {sequence; type_of_element: String}; Key myKey = Key.createKey(majorComponents); value: Bitstring; SortedMap x = key: { unique; { minorKey, majorKey } }; kvstore.multiGet(myKey); }} Данной программе соответствует спецификация 4.2 Отображение операций запроса: После того, как отображена структура данных, необходимо построить отображение языка q(x) :- class1(x/class1.inst) & манипулирования данными. Такое отображение x.majorKey1="Smith" & x.majorKey2="Bob" необходимо построить в две стороны. Отображение операций Oracle NoSQL в запросы на языке формул В отличие от Oracle NoSQL запрос на языке языка СИНТЕЗ позволит понять, какие виды формул возвратит в классе результата всего один запросов возможно отобразить в операции Oracle объект. Дело в том, что в ключе myKey, NoSQL. Обратное отображение позволит определённом в программе, отсутствуют только восстановить операции Oracle NoSQL по запросам фиксированные компоненты, а значит, из на языке формул. нефиксированных значений компонентов ключа и Рассмотрим операции системы Oracle NoSQL. значений пар будут сформированы все значения Во-первых, спецификации с операцией get(k). атрибутов в объекте-экземпляре класса class1. Параметр k должен быть полным уникальным В случае, если определённый ключ будет ключом, по которому требуется узнать содержать, помимо нефиксированных, единственное значение пары. фиксированные компоненты, например, phonenumber, возвращаться будет не полный объект, majorComponents.add("Smith"); а только объект, связанный с соответствующим majorComponents.add("Bob"); атрибутом, то есть, в данном случае – объект типа minorComponents.add("phonenumber"); Phonenumber. minorComponents.add("home"); Обратное отображение запроса в программу Key myKey = Key.createKey вызова операций системы в данном случае также (majorComponents, minorComponents1); восстановит операции формирования неполного ValueVersion vv = kvstore.get(myKey); ключа из ограничений значений атрибутов и из типа Value v = vv.getValue(); возвращаемого в запросе значения и вызов Данной программе соответствует спецификация операции multiget. запроса: Операция multiGet поддерживает также задание q([v]) :- class1([majorKey1, majorKey2, диапазона ключей, пары с которыми необходимо v : phonenumber.home]) & вернуть. В следующей программе задаётся первый majorKey1="Smith" & majorKey2="Bob" компонент ключа, а для второго компонента указывается диапазон значений. Из класса class1, соответствующего ключам данной структуры, выбирается фрагмент значений majorComponents.add("Smith"); типа его экземпляров, состоящий из атрибутов Key myKey = Key.createKey(majorComponents); majorKey1 и majorKey2, построенных в KeyRange kr = new KeyRange( "Bob", true, "Patricia", true); соответствии с компонентами, содержащими SortedMap x = нефиксированные значения, и пути kvstore.multiget(myKey, kr); phonenumber.home к значению пары. На атрибуты majorKey1 и majorKey2 накладываются ограничения, соответствующие заданным значениям компонентов ключа. Значение пары 58 Появление условия на диапазон значений Оно выражается в терминах определённого ранее дополнит отображённый запрос условиями для класса class1 на языке СИНТЕЗ, возвращая атрибута majorKey2. фамилию и имя человека по его домашнему телефону. q(x) :- class1(x/class1.inst) & При обратном отображении запроса на языке x.majorKey1="Smith" & СИНТЕЗ использование значения основной пары в x.majorKey2>="Bob" & x.majorKey2<="Patricia" операции сравнения (v=”555 5555”) говорит о том, что в отображении будет использоваться Ответ на данный запрос будет содержать все вспомогательная пара, где эти значения являются объекты-экземпляры class1, соответствующие ключами. условиям, наложенным на атрибуты. Последняя операция, которую мы рассмотрим, - 5 Отображение модели данных с операция возврата ключей, присутствующих в базе колоночным хранением multiGetKeys. Система баз данных Cassandra [8] относится к классу систем с колоночным хранением. Колонками majorComponents.add("Smith"); в ней называются множества пар «ключ-значение». Key myKey = Key.createKey(majorComponents); Семейства колонок, имитирующие табличную SortedSet k = kvstore.multiGetKeys(myKey); организацию данных, состоят из множества колонок, у каждой из которых есть название, Отображённый запрос может вернуть только значение и временная метка, и на которые данные, соответствующие компонентам ключей, ссылается ключ. Ключ является строкой, и с одним являющимся нефиксированными. Возможностей значением ключа в семействе может быть связано возвращать метаинформацию о схеме в языке СИНТЕЗ нет. единственное значение каждой колонки. Также значения колонки могут включать множество q([majorKey1, majorKey2]) :- подколонок с именами и значениями (без ключа). В class1([majorKey1, majorKey2]) & majorKey1="Smith" этом случае она называется суперколонкой. Манипулирование данными производится с Обратное отображение запроса восстановит помощью операций get, multiGet, getSlice, программу полностью, однако возвращать он будет multiGetSlice для вариантов чтения данных, insert и множество полных ключей вместе с разными remove для добавления/обновления и удаления значениями фиксированных компонентов. данных. Операции обновления и удаления пар Особенность использования модели в отличие от отображаются подобным образом с помощью традиционных реляционных баз данных состоит в специальных конструкций в языке правил языка том, что имена и значения в колонках могут СИНТЕЗ, вставляющих и удаляющих экземпляры использоваться, как угодно. Например, семейство классов. может состоять из неограниченного количества Для примера отображения вспомогательных пар, колонок, в которых имена не являются именами дублирующих основные данные, рассмотрим колонок, но и в именах, и в значениях хранятся приведённый ранее пример. данные. Это означает, что и в данной системе мы сталкиваемся с той же проблемой определения, { "555 5555": ["Smith", "Bob"] } какие из элементов являются фиксированными именами для построения структур, а в каких Следующий код демонстрирует работу с такими хранятся данные. Запросы к семействам парами: выполняются только по ключу, соответственно для выполнения запросов по другим элементам в majorComponents.add("555 5555"); системе Cassandra, как и в Oracle NoSQL, Key myKey = Key.createKey(majorComponents); используются вспомогательные семейства с ValueVersion vv = kvstore.get(myKey); материализованными взглядами, имеющими ключом необходимый элемент. Для правильного отображения операций в Для формирования объектной структуры, построенные ранее структуры необходимо знать, соответствующей исходной базе, используем какие элементы основных пар дублируются следующие правила: элементами вспомогательных. Отображение в язык 1. Семейство колонок отображается в класс и СИНТЕЗ будет выглядеть так: связанный с ним тип экземпляров класса, ключ q([majorKey1, majorKey2]) :- семейства становится атрибутом id типа class1([majorKey1, majorKey2, экземпляров, с ним связано свойство v : phonenumber.home]) & уникальности значения. v="555 5555" 2. Если имена колонок фиксированы (в именах не данные, а названия колонок, одни и те же для всех ключей), то имена колонок отображаются в 59 одноимённые атрибуты типа экземпляров операция get, запрашивающая колонки firstName и класса. Значения колонок, связанные с одним lastName по ключу "1", будет отображена в запрос: значением ключа, отображаются в значения атрибутов в объекте с id, соответствующим q([firstName, lastName]) :- значению ключа семейства. users(x/[id, firstName, lastName]) & x.id="1" 3. Если имена колонок нефиксированы (являются данными), то для пар имя-значение колонки Как и в случае систем баз данных «ключ- создаётся абстрактный тип данных с двумя значение», в колоночных базах для задания атрибутами, а семейство колонок отображается запросов с условиями, накладываемыми на в класс с атрибутом id и атрибутом, значением элементы, не являющиеся ключом семейства которого является последовательность значений колонок, в базе должны быть заранее созданы созданного типа. вспомогательные семейства, для которых эти 4. Ключи, имена колонок и значения элементы являются ключами. Отображение вспомогательных семейств (материализованных вспомогательных семейств производится в взглядов на основные семейства) отображаются структуры, построенные для основных семейств. в атрибуты уже существующего класса, если Для этого необходимо знать, какие элементы все колонки присутствуют в основных дублируют друг друга в разных колонках. семействах. 5. Подколонки отображаются в отдельный 6 Отображение документной модели абстрактный тип данных. В зависимости от данных того, фиксированы или не фиксированы имена Последняя рассматриваемая в статье система подколонок, структура типа задаётся по тому же принципу, что и для колонок семейств. MongoDB [10] относится к классу документных систем баз данных. Документом в ней является последовательность пар «ключ-значение» с Представим прежний пример, в виде семейства колонок для системы Cassandra: возможностью создавать последовательности вложенных пар в значениях. Интерфейс системы users: использует для задания документов и их { "1": { "firstName": "John", фрагментов язык JSON. Помимо запросов по "lastName": "Smith", ключам здесь возможно строить запросы и по "phoneNumbers": значениям, для этого можно создавать вторичные { "home": "555 5555", индексы. "mobile": "333 3333"} }, … users: } { "firstName": "John", "lastName": "Smith", Семейство users по значению ключа связывает "phoneNumbers": колонки firstName, lastName и phoneNumbers, { "home": "555 5555", причём последняя является суперколонкой, "mobile": "333 3333" хранящей две колонки: home и mobile. } Такая структура данных будет отображена в } спецификацию на языке СИНТЕЗ в виде класса Структуры в документах могут быть users и типа его экземпляров с атрибутами id для неограниченными по вложенности, например, ключа, firstName и lastName для фиксированных описывая XML-документ. В этом случае документы колонок и атрибутом phoneNumber с отдельным системы баз данных MongoDB должны типом, создаваемым в соответствии со структурой суперколонки. отображаться во фреймы языка СИНТЕЗ. С другой стороны, они могут быть неограничены по { users; in: class; количеству пар «ключ-значение» в instance_section: { последовательности. И если семантика хранимых id: String; данных такова, что в именах и значениях находится firstName: String; последовательность данных без вложения, то lastName: String; целесообразно отображать их в тип данных phoneNumbers: PhoneNumbers; последовательности языка СИНТЕЗ. Однако если key: { unique; id }; возможно выяснить фиксированную структуру }} документов, как в приведённом примере, то их { PhoneNumbers; in: type; home: String; имеет смысл отображать в значения абстрактных mobile: String; типов данных с формированием классов. } { users; in: class; Задавать запросы к такой базе возможно только instance_section: { по ключу, которому соответствует атрибут id. Так, firstName: String; lastName: String; 60 phoneNumbers: PhoneNumbers; NoSQL в объектную модель, заключается в их }} слабой структурированности: { PhoneNumbers; in: type;  в большинстве из них не определяется схема home: String; данных в явном виде; mobile: String; }  значения в парах «ключ-значение» часто могут быть произвольными и неструктурированными, Пример операций, запрашивающие номер ключи могут рассматриваться и как элементы домашнего телефона home по фамилии lastName структуры, и как данные; будет выглядеть следующим образом:  при отсутствии схемы структура пар может изменяться динамически. Фактически, с db.things.ensureIndex({'lastName':1}); помощью операции обновления можно в любой db.users.find({'lastName': 'Smith'}, момент ввести новую структуру пар «ключ- {'phoneNumbers.home':1}); значение»;  базы данных обычно не ограничены по И отображение данного запроса, соответственно, количеству пар в структурах, по длине ключей, будет таким: по вложенности пар. Такие системы могут использоваться для q([v]) :- users([lastName, v : phonenumber.home) решения задач, изначально рассчитанных на & lastName="Smith" использование нефиксированных и неограниченных слабоструктурированных данных (например, Как видно, при отображении документных баз иерархических или потоковых). С другой стороны, мы сталкиваемся с теми же проблемами, что и при многие приложения используют системы баз работе с системами баз данных NoSQL остальных данных NoSQL для хранения достаточно жёстко классов. В зависимости от семантики данных, типизированных структур. И тот, и другой случаи хранимых в парах, отображение в объектную приходится учитывать при отображении в модель может быть различным. объектную модель языка СИНТЕЗ. При выявлении семантики данных обращается 7 Выводы об общих проблемах внимание на использование в ключах фиксированных (имена элементов структур) или отображения моделей NoSQL в нефиксированных (данные) значений. В случае объектные спецификации выявляемой статической схемы данных Обобщая результаты анализа отображения фиксированные значения ключей отображаются в систем баз данных NoSQL различных классов, атрибуты типов, нефиксированные – в значения можно сделать вывод, что вне зависимости от атрибутов. класса системы – «ключ-значение», колоночной или При отображении создаются следующие документной – приходится сталкиваться с структуры: похожими проблемами отображения.  типы последовательности для Так как в системах баз данных NoSQL схема последовательностей пар; бывает не определена и может присутствовать  фреймовые структуры для вложенных пар; неявно, подразумеваемая создателем базы данных и  абстрактные типы данных в случае, если реализованная в коде приложения, то семантически данные подчиняются выявляемой чёткой значимое отображение в объектную модель структуре. автоматически строить невозможно. Каждая Возможные разновидности запросов, отдельная база данных потребует выявления схемы используемых при решении задач над данными в с участием эксперта. Есть смысл строить моделях NoSQL должны быть известны заранее. отображение на уровне приложения, работающего Данные, по которым необходимо организовать над базой данных, минуя отображение моделей поиск, должны оказаться ключами в некоторых системы баз данных. Однако приложения могут парах «ключ-значение», а искомые данные – быть закрытыми для внешних запросов, не значениями, для чего формируются предоставляющими произвольного доступа к вспомогательный пары над основными данными с данным, быть разбитыми на части, работающими с соответствующей структурой данных. Такие пары разными подмножествами данных из одних и тех же при отображении не образуют новые структуры, а баз, с одной базой может работать множество отображаются в типы и классы, образованные приложения. Поэтому оправдано проведённое в основными парами. В соответствии с статье исследование для построения отображения вспомогательными парами в целевой модели моделей на уровне операций системы NoSQL, образуются вторичные ключи. Запросы со включающего выявление семантики хранимых сравнением по атрибутам, являющимся ключами в данных и отображения структур с её учётом. вспомогательных парах, при обратном отображении Основная причина проблем, возникающих при отображаются в операции над этими парами. семантическом отображении моделей данных 61 Заключение [7] I. Stoica, R. Morris, D. Liben-Nowell, D. R. Karger, M. F. Kaashoek, F. Dabek, and H. На примере отображения моделей трёх систем Balakrishnan. Chord: a scalable peer-to-peer баз данных NoSQL различных классов в язык lookup protocol for internet applications. СИНТЕЗ показаны принципы отображения моделей IEEE/ACM Transactions on Networking (TON), NoSQL в объектную модель. Затронуты проблемы 11(1):17.32, 2003. отображения, которые по большинству являются [8] The Apache Saccandra Project. – общими для различных систем NoSQL. Данная URL: http://cassandra.apache.org/ работа может быть также использована для [9] Getting Started with NoSQL Database 11g Release отображения моделей данных NoSQL в другие 2. – Oracle. – 2011. – целевые модели данных. URL: http://docs.oracle.com/cd/NOSQL/html/Getti ngStartedGuide/Oracle-NoSQLDB-GSG.pdf Литература [10] MongoDB. – URL: http://www.mongodb.org/ [1] R. Cattell. Scalable SQL and NoSQL Data Stores. ACM SIGMOD Records. - Vol. 39. Iss. 4. - Mapping of NoSQL data models NY:ACM New York, 2010. - P. 12-27 to object specifications [2] D. Crockford. The application/json Media Type for JavaScript Object Notation (JSON). – RFC 4627. – Nikolaj Skvortsov 2006. – URL: http://tools.ietf.org/html/rfc4627 Database systems belonging to NoSQL class are [3] Kalinichenko L.A., Stupnikov S.A., Martynov D.O. used to supply horizontal data scaling and to work with SYNTHESIS: a Language for Canonical extralarge data volumes. It is necessary to involve them Information Modeling and Mediator Definition for into the problem solving over multiple heterogeneous Problem Solving in Heterogeneous Information information resources. The paper considers approaches Resource Environments. – Moscow: IPI RAN, to mapping of NoSQL models of different types to 2007. – 171 p. object model of the SYNTHESIS language used as the [4] J. Martin. Managing the Data-base Environment. – unifying information model in problem solving at New Jersey: Prentice-Hall. - 381 p. – ISBN 0-13- heterogeneous resources environment. The paper shows 550582-8. common mapping problems using several NoSQL [5] H.J.M. Meijer. Object model to key-value data databes systems and proposes an approach for discovery model mapping – US Patent App. 12/938,168, of database schemes not specified explicitly, as well as 2010. – Google Patents. mapping of operations. It considers a case when it is [6] D. Merriman. SQL to Mongo Mapping Chart. – impossible to recover data scheme because of lack of 2011. – URL: information about data structures stored in databases http://www.mongodb.org/display/DOCS/SQL+to+ including the semi-structured data case. Mongo+Mapping+Chart 62