CC BY
35ОБ ИСПОЛЬЗОВАНИИ NOSQL-ХРАНИЛИЩ ДАННЫХ
Н.Н.Шарипова,
старший научный сотрудник Уральский Федеральный университет имени первого президента России Б.Н.Ельцина, Институт естественных наук, г. Екатеринбург
ABOUT THE USE OFNOSQL DATABASES
N.N. Sharipova, senior staff scientist, Ural Federal University named after the first president of Russia B.N.Eltsin, Institute of natural Sciences, Ekaterinburg
АННОТАЦИЯ
Статья посвящена особенностям структуры и практического использования NoSQL-хранилищ данных Рассмотрены модели данных - агрегатная и графовая и типы баз данных NoSQL: «ключ-значение», документная, семейство столбцов и графовая. Для каждого типа приведены примеры СУБД и возможные сферы их использования. Указаны достоинства и недостатки этих хранилищ в сравнении с реляционными. Даны рекомендации по выбору типа хранилища при проектировании программных систем.
ABSTRACT
The article aims to consider the use of a currently popular NoSQL approach in the development of network applications. Data model (aggregate and graph) and four types of NoSQL databases ("key-value", document, "column family" and graph) are considered. Several examples of DBMS are given and their scope discussed. Some recommendations for software developers on choosing the type of repository represented.
Ключевые слова: NoSQL-хранилище; агрегатная модель данных; графовая модель данных; реляционная модель данных; СУБД.
Keywords: NoSQL database; aggregate data model; graph data model; relational data model; DBMS.
Введение. С конца 80-х годов прошлого века фактическим стандартом баз данных (БД) стали реляционные базы данных (РБД) и системы управления реляционными базами данных (РСУБД) [1]. Напомним известные разработчикам и пользователям преимущества этих систем: обеспечение минимальной избыточности данных за счет механизма нормализации и поддержка целостности содержимого базы данных; обеспечение согласованности данных и связей в каждый момент времени посредством механизма ASID-транзакций; использование универсального стандартизованного языка запросов SQL.
С 90-х годов прошлого века с развитием глобальных сетей и распределенных систем, появилась необходимость эффективно обрабатывать большие объемы данных, распределенных по многим узлам сети. Наиболее удобной организацией такой работы оказалось так называемое горизонтальное масштабирование, т.е. использование большого количества небольших компьютеров, объединенных в кластеры, где хранятся фрагментированные данные. Оказалось, что для решения таких задач РСУБД не предоставляют удобных и эффективных средств в силу следующих причин:
• Реляционная модель данных в соответствии с принципом нормализации предполагает разбиение совокупности данных по разным таблицам. Это чаще всего не соответствует структуре тех информационных объектов, с которыми имеет дело пользователь. Это, в свою очередь, особенно при обработке большого объема данных, не только замедляет доступ к данным, но и затрудняет разработку приложений. Прикладной программист вынужден существенное время тратить на отображение реляционных структур данных в структуры, соответствующие бизнес-логике приложения.
• РБД не всегда эффективно работают в распреде-
ленной среде, когда крупномасштабные данные фрагмен-тированы по многим узлам сети или кластерам.
Эта ситуация привела уже в 80-90-х годах прошлого века к разработке альтернативных моделей данных. Так появились объектно-ориентированная модель данных (ООМД), основанная на принципах объектно-ориентированного программирования [2]. Были созданы объектно-ориентированные СУБД (наиболее известные ОО-СУБД - ObjectStore, Jasmine), но в силу ряда объективных причин эти СУБД не получили широкого распространения. Другой подход оказался более плодотворным: расширение возможностей реляционных СУБД объектно-ориентированными свойствами, а именно возможностью отображать данные в виде объектов предметной области и манипулировать ими. Появились объектно-реляционные СУБД [3] (например, PostgreSQL, Oracle Database 8i, Cache и др.), которые и в настоящее время широко используются. Развиваются и другие подходы и основанные на них СУБД, отличные от реляционных. Основное назначение всех этих систем - эффективная обработка больших объемов распределенных данных с поддержкой горизонтального масштабирования и репликации. В 2009 году все это множество разнородных систем получило название баз данных или хранилищ NoSQL (Not Only SQL). Несмотря на растущую популярность NoSQL- подхода, в русскоязычной научной литературе публикаций, касающихся структуры и особенно практического использования NoSQL, немного.
Основные свойства NoSQL-систем[4,5]:
1. Отсутствие схемы данных, хранение неструктурированных данных в виде агрегатов - информационных объектов, фактически отражающих структуру предметной области. В неструктурированных БД можно легко изменять хранение данных, добавлять и удалять сущно-
сти, в одной записи хранить и обрабатывать неоднородные данные, т.е. данные с разным набором полей. Каждое приложение, работая с неструктурированными данными, фактически создает свою неявную схему данных.
2. Использование метода Map/Reduce (Отображение/Свертка) для обработки больших объемов распределенных данных. На фазе Map производится предварительная выборка нужных данных на разных узлах (причем, возможна параллельная выборка), а на фазе Reduce - чаще всего объединение выбранных на фазе Map данных и их обработка. Эта обработка может последовательнопро-водиться в несколько этапов и на разных узлах. Заметим, что использование этогомотодане является свойством исключительно NoSQL-систем. Многие РСУБД также используют этот метод дляобработкираспределенных данных.
3. Использованиегорезонтттьногомасштабировп-ния для ускорения операций чтения и записи. Естественной единицей храненйяоЬГоВННятляется аграгет.Мдш чтении масштабирование достигается за счет увеличения количества узлов, выполляюмрнчттн ие.Пяи з амилиосу-ществляется фрагментация по определенному заранее полю и в соответствии с его значениемотуществллется запись на соответствующие узлы. Например, можно фраг-
Ключ-значение
Рис 1. Классификация NoSQL-хранилищ
В агрегатных моделях данных единицей хранения и манипулирования являетсяагрегат- структура,представ-ляющая собой набор (коллекцию) разнотипных объектов, интерпретируемых в предметной областикакединое целое. Например, в качестве агрегата можно представить информацию о клиенте и всех его заказах в Интернет-магазине. Агрегат структурно можно сравнить с записью (record) в языках программирования. Следует заметить, что в агрегатной модели связи поддерживаются только внутри самого агрегата. Связи же между агрегатами в модели не заложены и могут быть реализованы только в приложениях. В связи с этим агрегатную модель рекомендуется использовать в тех предметных областях, которые имеют большой объем данных и достаточно простые связи. Привлекательность этой модели состоит в том, что она
ментировать по географическому местоположению пользователя. Масштабирование применяется и во многих современных РСУБД.
4. Создание на разных узлах репликаций (копий) одних и тех же данных. Это увеличивает доступность данных и отказоустойчивость системы в целом. Часто вместе с репликацией используется и фрагментация: фрагменты данных в виде агрегатов размещаются на разных узлах, а именно, там, где они чаще всего используются. Существуют разные способы и виды репликаций, наиболее употре-бительныевБД 1Ло8(^Ь - репликация типа «ведущий-ведомый» и одноранговая [4]. Во многих NoSQL-системах садествпют сыосоЛынаетролки репликаций и их автоматическое распространение по узлам. Реплицирование и фрагментацияприменяетсяи в РСУБД, но это является более сложной задачей, чем в БД NoSQL, большинство из которыхизначальнооыиентированы на работу с агрегатами.
Моделиаанныхтаипы хщанили щ NoSQL. В настоящее время к БД NoSQL относят БД, основанные на моделях хснных ывух тиолтюорегаыные (тли агрегированные) и графовые. На рис.1 изображена классификация существу-ющитхрани л ищ№ы8ЫНХ.
Графовые
Семейство столбцов
не предполагает наличия заранее разработанной жесткой схемыданных:структура агрегатаявляется довольно гибкой, допускает добавление как новых полей в агрегат, так и новыхагрегатовв модель.Агрегаты особенно удобны для работы на кластерах, т.к. данные одного агрегата хранятся на одном узле, что упрощает чтение и модификацию данных.
Агрегатные хранилища.
1. Хранилища типа «ключ-значение» (КУ-хранили-ща). Эти БД состоят из множества агрегатов, в которых данные хранятся в виде пары ключ-значение. Обычно ключ - это идентификатор, используемый для доступа к данным, а значения могут быть любой природы, в том числе, массивы, множества, списки и др. Значения хранятся без детализации внутренней структуры, т.е. структура
Хранилища NOSQL
Агрегатные
Документные
агрегата скрыта, оперировать с агрегатом можно только целиком, задав ключ. Содержимое агрегата интерпретируется приложением, работающим с ним. Возможны только три операции: чтение, запись и удаление значения по ключу. В силу простоты и быстроты доступа к данным БД типа «ключ-значение» обеспечивают хорошее быстродействие и горизонтальное масштабирование на кластерах.
Отметим и некоторые проблемы, возникающие при работе с KV-хранилищами: обновление данного, используемого в разных агрегатах; выполнение транзакций, состоящих из нескольких операций; выполнение запросов не по ключу, а по данным; невозможность одновременной работы с несколькими ключами.
Такие БД удобно использовать, когда вся необходимая информация должна храниться в одном объекте, например, для хранения информации о сеансах пользователей и об их профилях, о корзинах заказов в Интернет-магазине. Наиболее известные СУБД такого типа - Redis, Riak, Amazon Dynamo DB.
2. Документные БД являются разновидностью БД типа «ключ-значение» с более богатыми возможностями. Запись также состоит из ключа и значения, а в качестве значений хранят различные документы, которые имеют заранее известную, обычно древовидную структуру. Таким образом, значение определенным образом структурировано и эта структура здесь не является скрытой, т.е. можно обрабатывать и отдельные поля документа, делать поиск не только по ключу, но и по другому полю, делать запросы по аналогии с РБД. В некоторых документных БД есть свои языки запросов.
Первые две проблемы, указанные для БД «ключ-значение» , актуальны и для документных БД. Кроме того, документные хранилища неэффективно использовать в тех случаях, когда приходится часто изменять структуру документа и сохранять эти изменения. Т.к. агрегат сохраняется только целиком, то это заметно уменьшает эффективность записи, хранения и поиска. В качестве примеров документных СУБД можно указать MongoDB, CouchDB, OrientDB. Документные БД находят применение в тех областях, где нужно хранить большое количество независимых документов в разных форматах, но не требуется поддержка ссылочной целостности. Например: регистрация различных событий; управление информационным наполнением веб-сайтов; электронная комерция и др. Естественно, что документные СУБД особенно хорошо подходят как платформа для современных систем автоматизации документооборота.
3. Хранилища типа «семейство столбцов» или хранилища колоночного типа. В этой модели данные хранятся в виде совокупности (коллекции, семейства) столбцов, снабженных ключом. Каждый столбец - это фактически таблица из одного именованного поля, его значением является массив данных. Столбцы объединяются в семейства, доступ к семейству как к единому целому осуществляется по ключу. Ключ идентифицирует строку, состоящую из совокупности столбцов. Это напоминает организацию данных в РБД, но основное отличие заключается в том, что разные строки могут содержать разные наборы столбцов, причем, столбцы можно добавлять в любой момент в
любую строку. Такая гибкая структура позволяет хранить большие объемы агрегированных данных, а путем индексирования обеспечивается быстрый доступ к данным. Особенно эффективно в таких хранилищах выполняется операция записи. Но, как и другие агрегатные БД, они не подходят для сложной оп-line обработки данных. Наиболее известная СУБД колоночного типа - Apache Cassandra. Примеры использования: блог-платформы, веб-аналитика, регистрация событий во времени и др.
Графовые хранилища. Графовая модель данных предназначена для хранения и манипулирования объектами, имеющими относительно простую структуру, но связанными между собой большим количеством разных связей. В качестве модели хранения выбрана известная в математике универсальная структура - ориентированный граф, состоящая из узлов (информационных объектов) и направленных ребер, отражающих связи (отношения) между объектами. Это наиболее естественный способ представления сложных предметных областей. Таким образом, эта модель, в отличии от агрегатно-ориентированной, предполагает наличие четкой схемы данных и связей. Но, несмотря на это, модель является универсальной и гибкой, она допускает прозрачное внесение изменений: добавление как новых узлов, так и связей и их удаление. Поиск данных и запросы здесь осуществляются путем обхода узлов, что является более эффективным, чем формулировка и выполнение сложных запросов в РБД. Следует отметить, что методы и алгоритмы поиска, добавления и удаления узлов графа уже давно разработаны математиками и использовались при создании сетевых БД (CODASYL-си-стем) в 70-80е годы прошлого века [5]. Эти хранилища хорошо подходят практически для любых предметных областей со сложными отношениями между объектами, например, для социальных сетей.
Т.к. в графовых моделях основной акцент сделан на связях, то такие БД более эффективно работают на одном серевере, чем на кластерах в распределенной сети. На наш взгляд, отнесение графовых моделей к NoSQL весьма условно: единственное общее, что есть у них с идеологией NoSQL - это отсутствие языка запросов SQL. Кроме того, эти модели нельзя отнести и к постреляционным, они были использованы для реализации сетевых БД даже ранее, чем завоевала свою популярность реляционная модель. Наиболее
известная СУБД, основанная на графовой модели, -Neo4j.
Выбор типа хранилища. Далее рассмотрим актуальный для практики вопрос о выборе типа БД или хранилища для конкретной разработки. Какими бы привлекательными ни казались неструктурированные модели NoSQL, следует помнить, что они не являются заменой реляционных моделей, а служат альтернативным средством для решения определенного круга задач, о которых мы упоминали выше. Выбор структуры и типа хранилища должен быть хорошо обоснован, ему должно предшествовать доскональное изучение возможностей и ограничений тех инструментальных средств (СУБД и др.), которые предполагается использовать. Следует также иметь в виду, что для эффективной реализации хранилища NoSQL в соот-
ветствии с известной теоремой САР[4] придется выбирать не более двух из трех важных свойств данных: согласованность, доступность и устойчивость к фрагментации. Поэтому можно рекомендовать делать выбор в пользу NoSQL-хранилищ только в тех случаях, когда они имеют явные преимущества перед РБД.
Наиболее разумным подходом к разработке БД проекта является компромиссный подход, который исходит, с одной стороны, из требований решаемых задач, а, с другой стороны, из оценки производительности труда программистов. Часто на практике эти два требования могут противоречить друг другу. Выбор NoSQL-хранилища может повысить производительность работы программиста, т.к. структура используемых данных точнее соответствует логике приложения. Допустимо также, чтобы для реализации разных функций одной и той же системы, были бы выбраны разные типы хранилищ. Таким образом, для каждого приложения можно, в случае необходимости, создавать свою БД. Но при этом обязательно нужно заранее (уже при выборе типа БД) позаботиться об обеспечении согласованности при обмене данными между приложениями. А это, бузусловно, непростая задача.
Заключение. В настоящее время, когда NoSQL-подход является относительно новым и еще недостаточно методологически и теоретически обоснованным, большинство приложений все же должны по-прежнему использовать реляционную технологию, тем более, что современные
РСУБД (Oracle Database, Ms SQL Server, DB2 и др.) предоставляют много возможностей для работы с абстрактными данными в распределенной сети. Таким образом, БД NoSQL целесообразно использовать только для решения определенного круга задач после проведения тщательного анализа требований предметной области и производительности труда программистов.
Данная работа проводилась в рамках государственного задания Министерства образования и науки РФ, проект №2725, 2014-2016г.г.
Список литературы
1. Дейт К. Дж. Введение в системы баз данных. -8-е изд.: Пер. с англ. - М.: «Вильямс», 2005. -1328с.
2. The Object Database Standard: ODMG-93. Ed. by R. G.G. Cattell, Morgan Kaufmann Publ., 1994, p. 169
3. Михаэл Стоунбрейкер. Обектно-реляционные системы баз данных //- «Открытые системы», N 04, 1994, с.43-49
4. Мартин Фаулер, Прамодкумар Дж. Садаладж. NoSQL: новая методолгия разработки неряляционных баз данных: Пер. с англ.- М.: «И. Д. Вильямс», 2013. - 192с.
5. Т. В. Олле. Предложения КОДАСИЛ по управлению базами данных.- М.: «Финансы и статистика», 1981, с. 286
6. Сайт NoSQL (открытый доступ). - http://nosql-database.org/
ШАГОВЫИ ДВИГАТЕЛЬ
Л. Н. Шарыгин С. А. Тихомирова2, Т. А. Чумутина3
Владимирский государственный университет имени А.Г. и Н.Г. Столетовых (ВлГУ) 1 Профессор,2 Студент,3 Студент
PITCH ENGINE
АННОТАЦИЯ
Предложены основные технические решения по созданию электронноуправляемого шагового двигателя храпового типа. Преобразователь электрической энергии в механическую построен на основе магнитострикционного стержня. Основу фиксатора составляет поляризованный электромагнит. Управление шаговым двигателем осуществляется коротким прямоугольным импульсом постоянной формы для всех частот вращения.
ABSTRACT
The article deals with the principal solutions in making electromotive pitch engine with cog triangle wheel. The converter of electric power into mechanic one is made on the basis of magnetic strict spindle. The frame of binding is a polar electric magnet. The operation of pitch engine is performed by a short rectangular impulse of constant shape for all frequent rotations.
Ключевые слова: Шаговый двигатель, магнитострикционный преобразователь, храповое колесо, электромагнитный фиксатор.
Keywords: Pitch engine, magnetostrict spindle, cog triangle wheel, electromagnetic binding.
В электроприводах систем автоматического управления находят применения шаговые двигатели, в которых обычно попользуются электромагнитное взаимодействие полюсов статора и ротора. Типичным примером служит электродвигатель с явно выраженными полюсами статора и ротора [4, с 68-71]. Однако двигатели такого типа имеют низкий коэффициент полезного действия, их габариты быстро растут с увеличением мощности, они чувствительны к моменту инерции нагрузки. Проблема повышения
качества шаговых двигателей может быть решена на основе храпового механизма. Известные храповые механизмы [2,3] имеют сложные механические цели фиксации, что снижает их быстродействие, а за счёт износа - долговечность.
Предлагаем основные технические решения по созданию шагового двигателя храпового типа с фиксатором на основе поляризованного электромагнита и с магнито-стрикционным приводом колеса - рис. 1-5. Монтажной
