ПЗ_Забарин (1220033), страница 3
Текст из файла (страница 3)
– приведение данных к единым или унифицированным идентификаторам, описывающим универсальным образом структуры данных, а также названия структурных элементов, в которых хранятся данные, связывание данных.
Одной из важных и наиболее ресурсоемких задач процесса контроля состояния и динамики изменения объектов государственного управления является периодический поиск и анализ большого объема информации, содержащейся в открытых источниках в различных формах представления таких как текстовые документы, изображения, видеозаписи, машинные коды, таблицы и т. д., необходимой для принятия решений [1]. Традиционные методы анализа информации не могут угнаться за огромными объемами постоянно растущих и обновляемых данных, что в итоге и открывает дорогу технологиям Big Data, в англоязычных источниках для его описания используют определение трех V (volume, velocity, variety). Это означает, что если система обладает большим объемом данных, которые содержат информацию самых различных типов и методов сбора, и их необходимо достаточно быстро обработать, то такие данные могут быть определены как Big Data. Более подробно вопрос построения хранилища данных такого типа описан в разделах 1.2, 3.1.
Значительный объем исходных данных и многообразие их типов и форм представления с одной стороны и необходимость разностороннего описания объектов управления с учетом их взаимосвязей и особенностей функционирования с другой, породили проблему автоматизированного анализа открытых данных с целью выявления закономерностей, получения новых знаний об объекте управления, восполнения недостающих данных, прогнозирования поведения объекта управления и т.д. [1].
Решение данной проблемы находится в компетенции интеллектуального анализа данных [12]. Частично эту задачу решают технологии:
– кластерного анализа [13];
– построения ассоциативных деревьев [14];
– регрессионного анализа [15];
– анализа временных рядов [16] и др.
Однако адекватно интерпретировать полученные результаты и принять решение способен только человек, являющийся экспертом в предметной области.
В связи с этим, ведущая роль отведена способам и формам представления, как исходных данных, так и результатов аналитической обработки, учитывающих особенности восприятия и мышления. Применение методов и средств визуализации информационными системами, открывает новые возможности для восприятия их содержимого и значительно повышает информативность и эффективность информационных систем.
Использование возможностей человека по визуальному анализу информации, является предметом исследования когнитивной компьютерной графики. Более подробно данная проблема рассмотрена в разделах 1.3, 2.1-2.3.
Визуализация данных стала неотъемлемой частью. Однако лишь владения инструментами для графического отображения чисел, дат недостаточно – важно понимать, в чем именно заключается эффективность визуальной презентации. Правильное использование технологии NoSQL для создания слабоструктурированных массивов данных позволяет расширить возможности использования распределенных хранилищ, значительно повысить скорость чтения данных, а, следовательно, и работы системы в целом.
1.2 Обзор технологий NoSQL
База данных (БД) описывает реальные объекты нашего мира. Информация о состоянии этих объектов при должном хранении и организации становится данными. Таким образом структура базы – это отображение информационной структуры модели предметной области. Чем ближе модель структуры БД будет к предметной области, тем более работоспособной будет информационная система, так как модель, наиболее приближенная к реальной предметной области, будет предоставлять больше возможностей.
Несмотря на то, что существуют много решений для работы с БД, популярными и востребованными становятся лишь некоторые из них. Наиболее часто применяемая на сегодняшний день – реляционная система управления базами данных (СУБД).
В классической модели хранения данных используется распределенные табличные виды отображения, где информация собирается исходя из логики разработчика.
Подобный подход приводи к созданию избыточного хранения информации, ведь несмотря на позитивные аспекты разделения информации по признакам данных подход имеет и крайне негативный момент неконтролируемое возрастание количества таблиц данных при усложнении логики приложения.
С конца 60-х годов реляционные базы получили широкое распространение. За последние 100 лет в мире значительно возросли объемы информации и наблюдается динамичный рост скорости изменения структуры информационных объектов.
Динамика роста, исследованная компанией IDC, представлена на рисунке 1.1.
Рисунок 1.1 Динамика роста объема данных
По исследовательским данным IBM ежедневно в мире генерируется 15 петабайт данных. При этом каждые 18 месяцев объемы генерируемой информация удваивается. Объемы хранения цифровых данных возрастают на 45% в год. Важным фактором является тот факт, что 80% новых данных не структурированы.
С развитием распределенных вычислительных систем и хранилищ, возникала необходимость в своевременной и четкой работе экспертных систем и систем принятия решений в режиме реального времени, с высокой скоростью доступа к большому объёму данных, а также возможностью изменения описания объекта. Основной сложностью в реализации данной функции является то, для каждого объекта может быть определен свой набор атрибутов, который может меняться в процессе функционирования системы.
Изменения, вызванные ростом объема информации и изменением ее структуры, приводят нас к необходимости изменения методологии проектирования и разработки. Сегодня структура данных изменяется так быстро, что при длительной разработке модели информационной системы, модель устареет при вводе в эксплуатацию. Таким образом необходима возможность оперативного изменения структурной модели БД.
Для того, чтобы удовлетворить потребности в условиях роста объема данных, дальнейшие разработки велись в направлении масштабируемых баз данных, с возможностью оперативно производить изменения в структуре модели. Таким образом, появился новый тип БД, известный как слабоструктурированные(неструктурированные) БД. Основным стандартом структурированных баз данных является SQL, новый тип подчеркивая свою революционность был назван «не только SQL» (NoSQL). Увеличение объема данных также увеличился объем данных для обработки, сложности данных и отношений связи между ними данных. Обработка больших объемов данных является аспектом, который выходит за рамки данной работы. Термин «NoSQL» не следует понимать буквально. Вместо того, чтобы заменить реляционную базу данных, подход NoSQL предназначен для работы в приложениях, где есть проблемы масштабируемости, и данные нуждаются в некоторой структуре. Существует четыре типа хранилищ NoSQL.
Первым типом является хранилище «ключ-значение». Хранилища «ключ-значение» используют ключ для доступа к значению. Такие хранилища используются для хранения изображений, создания специализированных файловых систем, в качестве кэшей для объектов. Примерами таких хранилищ могут служить – Berkeley DB, MemcacheDB, Redis, Riak, Amazon DynamoDB[17].
Следующим типом выступает хранилище семейств колонок или Bigtable-подобные БД. В этом хранилище данные хранятся в виде разреженной матрицы, строки и столбцы которой используются как ключи. Этот вид СУБД чаще всего используется для веб-индексирование, а также задачах, связанных с большими объёмами данными, в которых требования к согласованности данных понижены. Примерами СУБД данного типа являются: Apache HBase, Apache Cassandra, Apache, Accumulo, Hypertable, SimpleDB [17,18].
Третьим типом выступают, графовые БД, которые применяются для задач, в которых данные имеют большое количество связей, например, социальные сети, выявление мошенничества. Примеры: Neo4j, OrientDB, AllegroGraph FlockDB, Titan [17,18].
Четвертая категория Документо-ориентированные СУБД основное внимание в работе уделено этому типу. Документо-ориентированные СУБД служат для хранения иерархических структур данных. Находят своё применение в системах управления содержимым, издательском деле, документальном поиске и т. п. Самая известная реализация документ-ориентированной БД CouchDB , который был вдохновлен Lotus Notes, обьекты БД, как правило, хранятся формате JavaScript Object Notation (JSON) или в формате Extensible Markup Language (XML). Примеры СУБД данного типа – CouchDB, Couchbase, MarkLogic, MongoDB, eXist, Berkeley DB XML[17].
БД NoSQL являются относительно новым и развивающимся типом баз данных по сравнению с предыдущим типом – реляционными БД. Реляционные БД являются стабильными и полностью протестированными. В этом разделе ВКР, рассмотрены несколько научно-исследовательских работ, статьи и мнения экспертов, которые позволяют осуществить более эффективный обзор технологий.
В 1998 году Карло Строци [19] разработал собственную концепцию БД, чтобы отличить его модель от реляционной БД Строци первым использовал термин «NoSQL».
Сростом объема данных с течением времени, и для решения проблемы масштабируемости, Google и Amazon придумали свои собственные БД. Разработанная Google БД получила название BigTable, а Amazon назвал свою разработку Amazon Dynamo. Одним из главных аспектов
BigTable является то, что она не имеет таких функции, как первичный ключ, внешний ключ, «JOIN». BigTable не является реляционной базой данных, но является распределенной, многомерной отсортированной картой [19]. Отображение данных в BigTable достигается за счет индексации ключевой строки, ключевого столбца, и отметки времени. Каждое значение в карте представляет собой непрерывный массив байтов.
Основной концепцией реляционных баз данных является нормализация данных, в то же время BigTable денормализует данные. В концепции BigTable, таблица рассматривается как однотабличная БД. Все данные хранятся в одной таблице и поскольку все данные хранятся в одном BigTable, концепция нормализация данных не применима к BigTable. После публикации Google статьи о BigTable в 2006 году [20] на рынке начали развиваться новые проекты NoSQL с открытым исходным кодом.
Ключевым понятием NoSQL является поддержка высокопроизводительных, масштабируемых хранилищ данных, обеспечивающих прямой доступ языку программирования для управления базой данных из прикладного уровня [21]. В NoSQL, пользователь БД может управлять данными как с уровня приложения так и БД. Прямой доступ к базе данных от уровня приложений обеспечивает гибкость, и скорость обработки.
Но в реляционной базе данных, БД может управляться только на уровне СУБД, а не из приложения (рисунок 1.1, а). Реляционной базе данных необходима нормализация. Нормализация представляет собой процесс проектирования полей и таблиц БД таким образом, чтобы избежать избыточности и зависимости данных. Нормализуя данных в различные таблицы, система управления реляционными БД (RDMS) может сохранить первичный ключ, что позволит поддерживать непротиворечивость данных. Нормализация большого набора данных ведет к проблемам с производительностью, потому что попытка агрегировать информацию может быть осложнена множеством сложных запросов с использованием «JOIN».
Однако, NoSQL не имеет запросов «JOIN», и доступ к базе данных можно получить через различные интерфейсы, что представлено на рисунке 1.1, б. В NoSQL, пользователь может использовать MapReduce для обработки большого объема данных параллельно. NoSQL – денормализует данные, в результате чего, мы можем иметь значительное улучшение времени запросов для обхода БД, потому что исчезают затраты ресурсов во время выполнения запросов к базе данных. NoSQL избегает «JOIN» и операций агрегации. Из денормализации данных существует вероятность несогласованности данных – дублирование или избыточных данных. Во избежание дублирования, уровень приложений должен полагаться на синхронизацию данных, что позволит избежать каких-либо несоответствий в копии данных.
Рисунок 1.2 –Доступ к данным: а – реляционной БД; б – NoSQL базы
Еще одно важное различие в архитектуре NoSQL и реляционных баз данных являются схемы. С помощью реляционной БД, необходимо определить структуру перед добавлением каких-либо записей.
Изменение структуры или добавления новых полей в таблицу реляционной БД, когда БД запущена на сервере вызывает множество трудностей [22].
Структура данных в NoSQL базах в отличие от реляционных, не регламентирована. Отдельному объекту можно добавить произвольный атрибут. При этом не требуется предварительного декларативного изменения структуры всей таблицы, что характерно для SQL. Как следствие отсутствия схемы – эффективность работы с разреженными данными. Если в одном документе есть поле A, а во втором – нет, значит никакого пустого поля A для второго создано не будет. Однако в силу отсутствия схемы, колонки не объявляются декларативно и могут меняться/добавляться во время пользовательской сессии работы с базой [23].
В 2000 году Эрик Брюэр публикует статью с идеей фундаментального компромисса между согласованностью данных, доступностью и устойчивости к разделению. Позже идея стала широко известна как CAP теорема, которая широко обсуждается и по сей день. Согласованность означает данные во всех узлах кластера не противоречат друг другу. Пользователь может получить те же данные запрашивая любой узел в кластере. Доступность означает, что любой запрос к распределённой системе завершается корректным откликом. Устойчивость к разделению свойство системы гарантирующее, что расщепление распределённой системы на несколько изолированных секций не приводит к некорректности отклика от каждой из секций.
Согласованность является свойством, в котором сравниваемые технологии различны. NoSQL базы являются менее согласованными из-за денормализации данных. Для того чтобы увеличить согласованность, количество узлов должно быть увеличено. Но увеличение количества узлов также уменьшает устойчивость БД. Согласно теореме CAP [24], система может иметь только два из трех свойств, таких как согласованность, доступность и устойчивость к разделению. Как показано на рисунке 1.3, только два из трех аспектов могут быть достигнуты в любой момент времени. Для реляционных баз данных это свойства доступности и согласованности БД, поскольку данные хранятся на одной машине.
Большинство баз данных NoSQL как правило, теряют согласованность для достижения лучшей доступности и устойчивости к разделению для решения проблемы масштабируемости. Архитектура БД выбирается в соответствии с потребностями бизнес-требований.
Например, в Amazon Dynamo акцент сделана высокую
доступность и устойчивость к разделению, потому что Amazon является сервис-ориентированной компанией и обеспечивает непрерывное обслуживание своих клиентов, что жизненно важное для выживания компании [24].
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
