Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 7)

– при обработке данных с помощью функций-представлений используется упрощённая модель технологии MapReduce, что позволяет производить параллельные вычисления, в том числе и на многоядерном процессоре;

– поддерживается вертикальное масштабирование;

– внешний интерфейс (API) к данной СУБД построен на основе архитектуры REST(рисунок 2.6).

Рисунок 2.6 – REST API

База данных, отдельные записи, отображения и запросы – ресурсы, которые имеют уникальный адрес (URL) и поддерживают операции: GET – получение ресурса; POST – создание ресурса; PUT – обновление ресурса DELETE – удаление ресурса [42].

3 ПРАКТИЧЕСКАЯ РЕАЛИЗАЦИЯ

3.1 Схема кластера

В рамках решения поставленной задачи к операционной системе серверов предъявляются следующие требования:

– возможность использования всей аппаратной мощности серверов;

– надёжность и стабильность работы;

– безопасность системы.

Было принято решение использовать операционную систему семейства Linux, так как операционные системы Linux имеют ряд преимуществ перед Windows.

Linux отличается более высоким уровнем безопасности системы по сравнению с системами, разрабатываемыми в закрытых проектах. Так же для Linux практически отсутствуют вирусы.

Важно отметить более стабильную работу системы при длительном непрерывном использовании. Дистрибутивы на основе Linux имеют широкое применение в различных областях: от встраиваемых систем до суперкомпьютеров, надёжно удерживают лидирующие позиции на рынке серверов, как правило, в составе комплекса серверного программного обеспечения LAMP [43].

В качестве дистрибутива выбранной операционной системы сервера выступает 64-битная версия Xubunta 14.04, которая в полной мере удовлетворяет предъявляемым требованиям и является свободно распространяемой.

Ключевыми особенностями, повлиявшими на выбор данного дистрибутива являются:

– низкие системные требования самой системы;

– высокая безопасность;

– повышенная надёжность;

– использование современных технологий, включая виртуализацию;

– широкий выбор программного обеспечения;

– обеспечение наиболее полной совместимости с другими операционными системами;

– возможность управления компьютером через веб-интерфейс.

Для решения поставленных задач был сконфигурирован кластер представленный на рисунке 3.1, Команды по конфигурации представлены в приложении А.

На операционную систему установлен Docker, в котором создано три контейнера в качестве фронт-сервера используется nginx он хранит и предоставляет во внешнюю сеть данные, организованные в виде веб-страниц; отвечает за организацию запросов к базам данных, CF-сервер Railo, выполняющий команды серверного языка ColdFusion, в качестве сервера базы данных выступает CouchDB.

Рисунок 3.1 – Модель кластера

Отдельно можно выделить модуль couchapp который расширяет возможности работы с CouchDB позволяя использовать код JavaScript на сервере.

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

3.2 Исходные данные

На портале открытых данных Российской Федерации[44], на май 2016 года обеспечен доступ к 7915 базам данных, представленных в 16 группах, среди которых образование, транспорт и здоровье.

Основными принципами открытых данных согласно [45] являются:

– первичность;

– полнота;

– актуальность;

– пригодность к машинной обработке;

– отсутствие дискриминации по доступу;

– отсутствие неизвестных форматов;

– лицензионная чистота.

Предложим следующую классификацию открытых данных, содержащихся в перечисленных источниках.

Данные поступают в различных представлениях, так по форме представления данных можно выделить:

– текстовые данные;

– табличные данные;

– графические данные;

– аудио и видео файлы;

– числовые данные текстом.

С точки зрения описания характеристик объекта выделяются:

– количественные данные;

– качественные данные.

По виду данных можно выделить:

– статистические данные по различной тематике;

– данные об объектах реального мира;

– фактографические данные.

Полученные данные имеют неструктурированный формат, так как данные могут быть как в числовом, количественном, категориальном, так и текстовом формате, степень преобладания того или иного типа данных представлена на рисунке 3.2.

Рисунок 3.2 – Превалирующие типы информации для разных сфер деятельности

Таким образом в современных условиях нужно обрабатывать большие объемы неструктурированных данных различных типов, а для этой работы прежние методы не подходят. Нужны новые методики хранения и обработки данных.

3.3 Описание базы данных

CouchDB является документо-ориентированной СУБД, представляет собой неструктурированное хранилище все данные которого хранятся в виде записей. В качестве web-интерфейса для управления БД CouchDB выступает Futon, после настройки сервера он доступен для обращения по адресу http://localhost:5984/_utils/. Записи базы данных в Futon представлены на рисунке 3.3.

Рисунок 3.3 – Записи базы данных в Futon

Любой документ в базе данных может содержать произвольное количество полей и вложений, которые представляют собой ссылки на файлы хранимые в БД. В результате CouchDB позволяет работать с файлами независимо от самого документа. Доступ к БД производится при помощи протокола HTTP с использованием RESTful JSON API, что позволяет обращаться к данным в том числе из выполняемых в браузере web-приложений. В качестве единицы хранения данных выступает документ в виде JSON-объекта, имеющий уникальный идентификатор, версию и содержащий произвольный набор именованных полей в формате ключ/значение. Пример документа, описывающего объект «город Хабаровск», представлен на рисунке 3.4.

Рисунок 3.4 – Объект базы данных

В рамках разработанной концепции для каждого объекта обязательными являются поля:

– _id – уникальный идентификатор объекта;

– _rev – версия объекта;

• links – поле хранящее ссылку или набор ссылок на файлы;

• content – набор записей, каждая запись в свою очередь имеет поля : id – идентификатор записи, attr_index_displayname – описывает положение поля на карточке объекта, type­­­ – описывает тип поля на карточке объекта, value – значение поля, title – заголовок поля, attr_source_tpl – значение _id объекта связанного с данным полем;

• tpl – идентификатор связи;

• tpltitle – название группы связанных объектов;

• type – тип объекта;

• crm – запись содержащая поля: comment – комментарий к объекту, modified – дата и время последнего изменения, created – дата и время создания.

CouchDB хранит данные в формате упорядоченного списка и позволяет производить частичную репликацию данных между несколькими БД в режиме «мастер-мастер» с одновременным обнаружением и разрешением конфликтных ситуаций. Каждый сервер хранит свой локальный набор данных, синхронизированный с другими серверами, которые могут переводиться в offline-режим и периодически реплицировать изменения. Пример дерева репликации представлен на рисунке 3.5. Настройки репликации, выполненные для рассматриваемого сервера представлены в приложении Б.

Рисунок 3.5 – Дерево репликации

В рамках решения задачи создания информационной системы дистанционного образование на языке ColdFusion было написано серверное приложение для создания и редактирования документов базы данных CouchDB. Данное приложение имеет возможности идентичные Futon, однако, более удобно, и имеет конструктор шаблонов объекта и графический интерфейс. Графический интерфейс программы, а также спроектированная база данных представлены на рисунке 3.6.

Рисунок 3.6 – Интерфейс приложения для проектирования БД

Так как БД не структурирована ее структуру описать невозможно, объем разработанной базы данных составляет 160000 документов.

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

3.4 Создание представлений (view)

Для организации псевдо-структурированного набора данных из произвольных документов, агрегирования и формирования выборок, применяется концепция формирования представлений (view), для определения которых используется язык JavaScript, также можно определять функции для проверки корректности данных при добавлении новых документов в рамках определенного представления. Фактически на сервере, в специальных документах хранятся view-функции (map() и reduce()), преобразующие набор документов требуемый вид. Разработанные функции представлений представлены в приложении В. Пример функции представлен на рисунке 3.7.

Рисунок 3.7 – Код и результат представления «Группы объектов»

Представления постепенно вычисляются, с сохранением промежуточных результатов в документ, если между двумя вызовами view добавилось или изменилось несколько документов, то функция будет вызвана только для них.

На первом шаге функция разыскивает все объекты которые удовлетворяют условию поиска, следующим действием происходит выборка искомых полей и формирование представления. В условиях разнородности структуры объектов эта задача усложняется построением логики запроса, а также механизмом формирования списка полей. Однако, для вывода информации для дальнейшей визуализации в табличном представлении подобные функции достаточно просты, и в этом отношении CouchDB не уступает SQL в возможностях. Следует отметить что несмотря на то, что результаты исследований [25] показывают, что обращение к объекту в NoSQL происходит быстрее, обработка запросов на чтение и запись таблиц в рамках одного сервера происходит медленнее чем в SQL, однако значительно возрастает в распределенных кластерных системах.

Важнейшим преимуществом в условиях роста объёма данных, является тот факт, что при превышении объема 200-300 ГБ, SQL сервер не способен обрабатывать данные, в свою очередь, в технологии NoSQL нет подобных ограничений. Таким образом система не только обладает масштабируемостью, но также показывает себя значительно эффективнее при расширении системы.

3.5 Визуализация состояния объектов

Для визуализации состояния объектов, рассматриваемой в данной ВКР неструктурированной базы данных, в соответствии с разделами 2.1, 2.3 было разработано несколько модулей визуализации, позволяющих осуществить разносторонний анализ исследуемых данных.

Модули визуализации взаимодействуют с базой данных в соответствии со схемой представленной на рисунке 3.8.

Рисунок 3.8 – Взаимодействие приложений визуализации с базой данных

С помощью службы REST пользователи могут удаленно взаимодействовать с базой данных. Эта возможность позволяет программисту работать с базой данных из уровня приложений.

Технология AJAX библиотеки JQuery позволяет послать базе данных REST запрос GET, ответом которого может являться документ или результат представления(view) в формате JSON, который в дальнейшем обрабатывается в соответствии с логикой приложения.

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

Характеристики

Список файлов ВКР