Анализ платформ хранения больших данных

РЕФЕРАТ

Дипломная работа: 94с., 16 рис., 2 табл., 51источник.

Цель исследование: обеспечить доступность, масштабируемость, скорость анализа Больших данных, за счет оптимального выбора системы хранение данных, какая позволит предоставить качественные услуги конечным пользователям.

В данной работе проанализировано да предоставлено классификацию типов нет реляционных баз данных, проанализировано платформы хранение больших данных

Разработано информационную модель данных медицинских карт да выбрано оптимальную платформу хранения больших данных для практического задания на примере работы с медицинскими данным.

Описано структуру базы данных для медицинских карт в порядка развертывание от основных документов к побочных.

Ключевые слово: БОЛЬШИЕ ДАННЫЕ, НЕРЕЛЯЦИОННЫЕ БАЗЫ ДАННЫХ, КЛАССИФИКАЦИЯ, АНАЛИЗ.

СОДЕРЖАНИЕ

ПЕРЕЧЕНЬ СОКРАЩЕНИЙ

БД _ данных

ПО Программное обеспечение

ИТ Информационные технологии

NoSQL Not Only SQL

БИ Бизнес-аналитика

ИоТ Интернет вещей

СУБД Система управление базами данных

URI Унифицированный идентификатор ресурса

ВВЕДЕНИЕ

Актуальность темы

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

Только представьте, уровень пользователей интернета сейчас составляет 59,5%. Однако COVID-19 оказал значительное влияние на сбор данных о количестве пользователей интернета, поэтому фактические цифры могут быть выше. А социальными сетями в 2021 году пользуются 53,6% мирового популяция.

Интересный факт: если собрать всю информацию, которую человечество накопило из начала к 2000 года включительно, то окажется, что это меньше, нож мы производим за одну минуту. Это явление полностью изменяет представление о мире и наше место в нем.

Объем собранных данных растет огромными темпами.

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

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

Big Data – это одновременно и большие возможности, и большие проблемы.

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

Объект исследование

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

Предмет исследование

Современные платформы хранение больших данных.

Цель исследование

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

Задачи исследование

РАЗДЕЛ 1

АКТУАЛЬНОСТЬ ЗАДАЧИ, ОБЗОР СУЩЕСТВУЮЩИХ ПОДХОДОВ

1.1 Определение больших данных

Срок Big Data появился в 2008 году. Впервые его употребил редактор журнала Nature – Клиффорд Линч. Он рассказывал о взрывном росте объемов мировой информации и отмечал, что освоить их помогут новые инструменты и более развитые технологии.

С названия можно предположить, что срок «Великие данные» относится просто к управление да анализа больших объемов данных. Согласно со отчетом McKinsey Institute «Большие данные: новый рубеж для инноваций, конкуренции и производительности» (Big data: Next frontier for innovation, competition and productivity), термин «Большие данные» относится к наборам данных, размер которых превышает возможности типовых баз данных (БД) по занесению, хранению, управлению и анализу информации. И мировые репозитории данных, безусловно, продолжают расти.

«Большие данные» предполагают нечто большее, чем просто анализ огромных объемов информации

На сегодняшний день понятие «Большие данные» (Big Data) является одним из наиболее часто используемых в корпоративном среде, но нет имеет точного определение и границ этого понятие Множество авторов, организаций да компаний стараются по-разному его интерпретировать. Что же такое Big Data?

Big Data – это серия подходов, инструментов и методов, используемых для обработки структурированных и неструктурированных данных огромных объемов и значительного разнообразие для получение результатов, которые воспринимаются людьми,

доказывающие свою эффективность в условиях непрерывного роста. Большие данные служат альтернативой традиционным системам управления базами данных и решений в рамках Business Intelligence. [1 . ]

Наиболее популярным считается определение от Forrester Research (2013): «Великие данные представляют массивный объем структурированных и нет структурированных данных, которые настолько большие, что их сложно обрабатывать, используя традиционные базы данных и программные средства». [2] Эффективность такого определения, что появилось в то время, когда появились первые средства для работы с большими данными и наметились определенные тенденции в области разработки и применение больших данных, в основном связана с разработкой нереляционных баз данных (NoSQL), средств хранение больших данных и масштабируемых средств массивной обработки, таких как MapReduce, Hadoop, Spark.

Как видим, в этом определении присутствует такие неопределенные сроки, как

«огромных», «значительного», «эффективно» и «массивных». Даже сама название очень субъективно.

Аналитики компании IBS «весь мировой объем данных» оценили следующими. величинами:

2003 г. - 5 эксабайт данных (1 ЭБ = 1 млрд гигабайтов)

2008 - 0,18 зеттабайт (1 ЗБ = 1024 эксабайта)

2015 г. - более 6,5 зеттабайт

2020 г. - 40-44 зеттабайт (прогноз)

2025 г. - этот объем возрастет еще в 10 раз. [ 3]

В сентябре 2020 года агентство ResearchAndMarkets опубликовало отчет о глобальный рынок аналитики больших данных. Согласно с опубликованной информацией, мировой рынок аналитики крупных данных оценивается в $41,85 млрд по итогам 2019 года. По прогнозам аналитиков, он вырастет до $ 115,13 млрд, где средний динамике в 11,9% в течении прогнозируемого периода с 2020 по 2028 год.

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

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

В 2001 году получилось основополагающее исследование Gartner, какое определило три основные характеристики больших данных: объем (в смысле физического объема), скорость (как скорость прироста, да и скорости необходимой обработки и получения результатов) и разнообразие данных (в смысле возможности одновременной обработки разных типов структурированных и слабоструктурированных данных) (англ. – volume, velocity, variety).

В дальнейшем к базовым 3V добавились свойства обширных данных, которые они приобретают в процессе обработки и являются основополагающими для определения требований к системам обработки больших данных: Value, Variability, Veracity (Значимость, Изменчивость, Конфиденциальность). Теперь их намного больше.

Вот 10V больших данных:

Объем:

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

Скорость:

Скорость означает скорость, с которой данные генерируются, производятся, создаются или обновляются. Конечно, впечатляет, что хранилище данных Facebook хранит более 300 петабайт данных, но следует учитывать скорость создание новых данных. Facebook требует 600 терабайт входных данных на день. Только Google обрабатывает в среднем более 40 000 поисковых запросов. ежесекундно", что примерно означает более 3,5 миллиарда поисковых запросов на день.

Разновидность:

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

Вариабельность:

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

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

Правдивость:

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

источники данных, его контекста и того, насколько значим он для анализа на его основе.

Например, рассмотрим набор статистических данных о то, что Люди покупают в ресторанах и цены на эти товары за последние пять лет. Вы можете спросить? Кто создал источник? Какой методологией они руководствовались при сборе данных? Были ли включены только определенные кухни или определенные типы ресторанов? Или обобщили информацию создатели данных? Или редактировал или модифицировал информацию кто-то другой?

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

Срок действия:

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

Уязвимость:

Обширные данные вызывают новые проблемы безопасности. В конце концов, нарушение данных с большими данными – это большое нарушение. К сожалению, было много нарушений больших данных. Еще один пример, как сообщал CRN в мае 2016 года, "хакер под названием Peace разместил данные в темный сети для продажи, которые якобы включали информацию о 167 миллионов учетных записей LinkedIn да 360 миллионов электронных писем да паролей для пользователей MySpace».

Волатильность:

Сколько лет должно быть вашим данным, прежде чем они будут считаться неактуальными, историческими или больше не полезными? Как долго нужно хранить данные?

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

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

Визуализация:

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

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

Значение:

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

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

Этот список можно продолжать, однако любая проблема – обратная сторона возможностей.

Задачи, относящиеся к Big Data. Существуют три типа задач, связанных с Big Data:

Объем данных в сотни терабайт или петабайт не позволяет легко хранить и управлять ими с помощью традиционных реляционных баз данных. Big Data обычно сохраняются и организуются в распределенных файловых системах.

В общих чертах, информация хранится на нескольких (иногда тысячах) жестких дисках, на стандартных компьютеры. Да колокола «карта» (map) отслеживает, где (на каком компьютере и/или диске) сохраняется конкретная часть информации. Для обеспечения отказоустойчивости и надежности, каждый часть информации обычно сохраняют несколько раз, например - трижды.

Так, например, предположим, что вы собрали индивидуальные транзакции в большой розничной сети магазинов. Подробно информация о каждую транзакции будут храниться на различных серверах и жестких дисках, а «карта» (map) индексирует, где именно хранятся сведения о подходящую сделку.

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

Большинство всех данных Big Data неструктурированы. То есть как можно организовать текст, видео, изображение, и т.д.?

Это имеет свои преимущества и недостатки.

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

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

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

Как анализировать неструктурированную информацию? Как на основе Big Data составлять простые отчеты, строить и внедрять углубленные прогностические модели?

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

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

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

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

Это платформа информационных технологий (ИТ) класса предприятия, какая обеспечивает свойства да функциональность прикладной системы в одному решении для разработки, развертывание, обработки да управление большими данным. Программное обеспечение (ПО) аналитики больших данных помогает раскрыть скрытые шаблоны, неизвестные корреляции, рыночные тенденции, предпочтения клиентов и другую полезную информацию по широкому разнообразию наборов данных. Главный вопрос организации работы с большими данными на корпоративном уровни: выбрать реляционную (SQL) или нереляционную (NoSQL) базу данных? Главной причиной отказа от SQL баз данных (БД) есть нет правильная работа с самой базой. Большинство компаний не могут себе позволить держать специалистов для постоянного отладка баз данных, а для того, чтобы начать использовать NoSQL БД нет нужно дополнительных разработок. При разработке NoSQL БД особая внимание уделяется обеспечению высокой масштабируемости да гибкости решений. NoSQL БД – это, прежде за все, быстрый доступ к данным, хранящимся в оперативной памяти , гибкость использование да возможность быстрого распределение данных между узлами.

Однако возможны такие сценарии, когда данные впоследствии выходят из-под контроля или уже просто не умещаются в оперативной памяти.

Технологии хранение больших данных называются технологиями хранение, которые определенным образом решают объем, скорость или разнообразие и не попадают в категорию реляционных систем баз данных. Это нет значит, что реляционные системы баз данных нет решают или проблемы, но альтернативные технологии хранение, такие как столбчатые магазины да умные комбинации разных систем хранение, например использование HadoopDistributed File System (HDFS), часто более эффективными и менее дорогими (Marzand Warren 2014).

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

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

предпринимательства, которое может управлять практически неограниченными объемами данных. Свидетельством тому является широкое использование решений на основе Hadoop, предлагаемых поставщиками, такими как Cloudera (2014a), Hortonworks (2014) и MapR (2014), а также разными поставщиками баз данных NoSQL2, в частности, использующими технологии памяти и столбчатые хранилища. По сравнению с традиционными реляционными системами управления базами данных, которые полагаются на быстрое хранение и дорогие стратегии кэширования, эти новые технологии хранения больших данных предлагают лучшую масштабируемость при меньше сложности операций да затратах. до сих пор значительный неиспользованный потенциал для технологий хранение больших данных как для использование, да и для дальнейшего развития технологий:

В настоящее время существует два хорошо устоявшихся способа хранения больших данных:

Складское хранение - Подобно к состав для хранение физических товаров, хранилище данных – это крупный строительный объект, основной функцией которого хранение и обработка данных на уровне предприятия. Это важный инструмент для анализа обширных данных. Эти большие хранилища данных поддерживают разные отчеты, бизнес-аналитику (BI), аналитику, добычу данных, исследования, кибермониторинг и другие связанные с этим виды деятельности. Эти составы обычно оптимизированы для сохранения и обработки больших объемов данных в любой время, одновременно подавая их и выводя через Интернет-серверы, где пользователи могут получить доступ к своим данных без задержки.

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

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

Возможно, вы слышали о термине "Hadoop", который бросают то и дело, но до сих пор не знаете, что это хорошо. Хотя это целая тема сама по себе, мы коротко ее объясним. Hadoop - это программная база, назначена для распределенного хранения и обработки больших данных для обработки больших объемов данных и вычислений. Hadoop делает революцию в аналитике больших данных для корпоративного хранение.

Другой способ хранение больших объемов данных - это облачно хранение, с которым люди знакомы больше. Если вы когда-нибудь использовали iCloud или Google Drive, это означает, что вы использовали облачное хранилище для хранение собственных документов и файлов. С помощью облачного хранилища данные и информация хранятся в электронном режиме в Интернете, где к ним можно получить доступ с любого места, склоняя необходимость прямого подключенного доступа к жесткому диску или компьютеру. Благодаря такому подходу вы можете хранить практически безграничное количество данных в Интернете да получать доступ к ним где угодно.

Облако обеспечивает не только доступную инфраструктуру, но и возможность быстро масштабировать эту инфраструктуру для управление значительным увеличением трафика или использование.

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

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

До основных свойств платформ больших данных можно отнести:

До главных преимуществ платформы больших данных да ПО аналитики больших данных можно отнести:

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

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

Эффективное управление бизнесом требует быстрых адекватных ответов на критические вопросы, влияющие на успешность бизнес-операции. Платформа обширных данных позволяет делать это более надежно. Некоторые критические вопросы, ответы на которые требуют недель или месяцев, за наличии правильного инструмента могут решаться только за несколько часов или минут;

Обеспечивает безопасную инфраструктуру, гарантирующую безопасность данных. Задачи да ПО больших данных

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

Задачи да ПО больших данных

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

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

Хранение да управление большими данным

Традиционные методы структурированного хранения и извлечения данных, такие как реляционные БД, витрины или SQL хранилища данных, имеют определенные ограничения, делающие их не пригодными для работы с большими данными, а именно они:

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

задачи управление данным на прикладном уровни. Каждая база, в данном случае, является коллекцией независимых документов, где каждый документ поддерживает собственные данные и схемы и могут иметь метаданные – обзорную информацию о данных документа. Прикладная программа может иметь доступ к многих БД, расположенных в разных местах. Новые требования к хранение, управление да обработки данных обусловили возникновение Hadoop – фреймворка с открытым кодом под крылом Apache Software Foundation, что разрешает создавать распределены системы на базе относительно недорогого оборудование массового спроса. Со временем Hadoop был расширенный набор библиотек и утилит, да сформировал вокруг себя экосистему проектов по распределенной обработке данных. Рассмотрим его более подробно.

Выводы

В данном разделе было приведено определение Больших данных, рассмотрено основные характеристики Больших данных.

Подано понятие платформы Больших данных да ее основных свойств.

РАЗДЕЛ 2

ИССЛЕДОВАНИЕ ТА АНАЛИЗ ВОЗМОЖНЫХ РЕШЕНИЙ NOSQL

Идея разработки реляционных баз данных заключалась в обеспечении подхода к хранение данных, использующий язык структурированных запросов или SQL [ 4 ]. Ввод этих баз данных датируется 1970-ми годами, когда данные схемы были не столь сложными, как сегодня. Более того, хранение было дорогим, и не все данные рассматривались для архивных. С ростом платформ социальных медиа объемы данных, что сохраняются о события, объекты да людей выросли в геометрической прогрессии Использование данных в настоящее время и возраст не ограничивается только архивирование данных, но это также распространяется на частый поиск и обработку данных, чтобы служить таким целям, как генерация в режиме реального времени каналы [ 5 ] да рекламные объявления[6], кроме многих других.

В результате сложности информации, что обрабатывается, и необходимости лечения нескольких, порядка сотен, запросов базы данных только для того, чтобы ответить на один запрос API или воспроизвести веб-страницу, требования современной системы базы данных постоянно растут. Одними с ключевых факторов в этом домене есть потребность в интерактивности, сложность которой растет и постоянно развиваются сети пользователей [ 7 ]. Для того, чтобы удовлетворить или растущие требования, применяются стратегии развертывание да усовершенствованная вычислительная инфраструктура. С учетом этого, серверные развертывания есть дорогими и очень сложными, что привело к смещению к использованию облачного оборудование. Кроме того, использование гибких методов также сократило время. разработки да развертывание, что разрешает быстрее реагировать на потребности пользователей.

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

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

Ручное шардирование

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

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

Распределенный кэш

Кэширование [9] - это общеупотребительный процесс, какой в основном применяется для улучшения чтения производительности системы. Примечательно, что использование кэш-памяти не влияет на производительность записи и способно существенно увеличить сложность общей системы. Поэтому, если требования системы требуют интенсивного чтение, тогда след учитывать использование распределенного кэша. С другого стороны, включено программы, что требуют интенсивной записи или чтения / записи и не требуют распределенной кэша [10].

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

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

Некоторые преимущества решений NoSQL перед традиционными базами данных такие:

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

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

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

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

Возможно реализовать гибкие модели данных в NoSQL[11]. Это позволяет разработчикам реализовать параметры запросов да типы данных, которые подходят приложения, вместо соответствующих схеме. В процессе взаимодействие между базой данных и приложением упрощается, что делает этот подход предпочтительным вариантом ловкого развития.

NoSQL - общий срок, что используется для описания множества технологий, которые предусматривают следующие общие характеристики [12].

Динамические схемы

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

Так требование непригодна для гибких сред разработки, поскольку поля данных, возможно, придется сменить через некоторое время. Возможно, будет добавлено новое требование как часть итерации, и впоследствии, возможно, придется иметь схему изменен. Если база данных большая, это трудоемкое Задача. Как результат, базу данных, Возможно, придется закрыть для любого использование в течение длительного времени для внесения необходимых изменений. Больше того, если процесс разработки требует несколько итераций, базу данных, Возможно, придется закрывать достаточно часто на значительный промежуток времени. Очевидно, реляционные базы данных непригодны для хранение больших, неструктурированных да неизвестных данных.

NoSQL удовлетворяет этому требованию, поскольку не имеет заранее определенных схем. Более того, вставка данных не требует разработчика определить схему заранее. Как результат, изменения в структуре данных могут быть внесены в режиме реального времени без необходимости закрывать базу данных для любого другого использование [12]. Есть несколько преимуществ использование этого подхода.

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

Автозаточка

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

Для того, чтобы выполнить шардинг базы данных, что охватывает несколько серверов, нужно сделать сложные механизмы несколько серверов действуют единой системой, их нужно установить. С другого стороны, базы данных NoSQL поддерживают автоматическое затухание. Другими словами, база данных автоматически распределяет данные между несколькими системами без необходимости использование администратора, чтобы быть в курсе состав пулу серверов. Балансировка нагрузки [13] для данных и запросов также автоматически выполняется системой. Это разрешает системе предложить высокую доступность. Как и когда сервер снижается, его можно удобно заменить, а операции остаются неизменными.

Автоматическая репликация

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

Интегрированный кэш

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

NoSQL - это технология, какая разработана для противодействия проблемам, представленным реляционными базами данных, что есть реализованы разными способами по разным моделям. Общие характеристики моделей NoSQL включают эффективность хранение, снижение эксплуатационных затрат, высокая доступность, высокая параллельность, минимальное управление, высокая масштабируемость и низкая задержка[14]. Решение NoSQL классифицировали по несколькими критериями. Yen [15] предоставил подробную классификацию решений NoSQL, разделив их на девять категорий, которые включают широкий столбчатый магазин, хранилище документов, база данных объектов, хранилище кортежей, сервер структур данных, хранилище ключевых значений, кэш-ключ-значение, упорядоченное хранилище ключевых значений и со временем схожее хранилище ключевых значений. Еще одно таксономическое исследование было проведено Нортом [15], какой дал исчерпываю классификацию да включал облачные решение, также для анализа Решение были классифицированы за шестью категориями, а именно "Данные о сущность-атрибут-стоимость" Магазины, магазины столбцов Amazon Platform, хранилища данных Key-Value и хранилища документов распределенной хэш- таблицы.

Catel [16 . ] и Leavitt [17] предложили классификацию на основе модели данных. Catel [16] разделяет решения NoSQL на три категории, а именно магазины ключевые значения, магазины документов и расширяющиеся магазины записей. С другой стороны, Leavitt [17] предлагает использовать три категории, а именно на основе документов, хранилища ключевых значений, хранилища, ориентированы на столбцы.

Скофилд [18] дал наиболее принятую схему категоризации, классифицируя базы данных на реляционные, графические, хранилища значений документа, столбца да ключа. Эта исследовательская работа использует вышеупомянутую основу для классификации да охватывает хранилища, ориентированы на документы, модель данных графиков, хранилище ключевых значений да широкое хранилище столбцов в следующих разделах.

База данных NoSQL, какая использует документы для хранение да поиск данных, называется документоориентированной базой данных [19]. Другие названия этой модели данных NoSQL - это база данных документов да хранилище документов. Это прежде всего используется для управление полуструктурированными данным через его гибкость да поддержку переменной схемы Упомянутые раньше, базы данных используют документы для своей работы. Эти документы могут быть в формате PDF или Word формате. Однако блоки JSON да XML есть наиболее распространенными форматами документов. Реляционная база данных содержит столбцы, которые описываются их именами и типами данных. Напротив, в случае с документом базы данных, описание типа данных и значение соответствующего описания приводятся в документе.

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

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

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

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

Эффективность записывание баз данных, ориентированных на документы, лучшая за обычные системы [20]. Чтобы сделать систему доступной для написание, база данных может также нарушить консистенцию данных. Итак, даже если система выходит из строя и репликация занимает больше времени, чем ожидалось, операция записи будет быстрой.

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

Каждый документ может хранить в себе, как правило, XML, JSON или BSON – бинарно-сохраняемый JSON. Но сейчас это уже практически всегда JSON или BSON. Это тоже как бы пара ключ-значения, можно это себе представить как таблицу, в которой каждая строка имеет определенные характеристики, и мы по этим ключам можем с нее что-нибудь доставать.

Преимущество документоориентированных БД: они имеют очень высокой доступностью и гибкостью данных. В любой документ, в любой JSON можно записать абсолютно любой набор данных. И они очень часто применяются – например, когда нужно сделать какой-нибудь каталог и когда каждый продукт в каталоги может иметь разные характеристики.

Или, например, профили пользователей. Кто-то указал свой любимый фильм, кто-то – любимую пищу. Чтобы не засовывать все в одно поле, которое будет сохранять непонятно что, мы можем все записать в JSON документоориентированных базы.

Эта модель данных NoSQL создана специально для поддержания хранения да обработки объемных данных, которые могут быть полуструктурированными, структурированными или неструктурированными за типом. Таким образом, данные могут быть доступны и получены из разных источников. Как результат, модель данных Graph широко используется в социальных сетях да аналитике больших данных. Заслуживает на внимание то, что реляционные базы данных были разработаны для хранение структурированной информации, доступной да генерируемой для предприятий. Следовательно, схема хранимых данных доступна заранее. Напротив, данные, генерируемые IoT (Интернет вещей) и социальные медиа неструктурирован. Больше того, он генерируется в режиме реального времени.

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

Вышеупомянутые программы, такие как анализ социальных медиа и аналитические решения на основе IoT, требующие базовой технологии для интеграции данных, поступающих из неоднородных источников и установления связей между разными наборами данных. Данные программы такого рода самое лучшее обрабатывать за помощью базы данных семантических графов или RDF triplestore [21], что фокусируется на взаимосвязи между разными элементами базы данных и генерирует аналитику на данной базе. Графовые базы данных в основном используются для анализа в режиме реального времени из-за их способности обрабатывать большие объемы данных и без необходимости заранее определять схему.

Преимущества использование графовых баз данных можно обобщить следующим образом:

Наиболее гибким типом базы данных NoSQL есть ключ-значение [23], какой реализует политику без схем нет имеет схемы и делает значение данных непрозрачными. Значение данных может сохранять строки, числа, изображение, двоичные файлы, счетчики, XML, JSON, HTML да видео, кроме многих других[23]. Доступ к сохраненным значениям можно получить с помощью ключа. Гибкость базы данных проявляется в том, что программа контролирует значение данных, полностью. Основные преимущества модели ключ-значение такие:

Мы можем использовать ключ-значение, например, для хранение сессий пользователя. Пользователь кликнул, мы записали это в value. Это таковой schemaless, модель данных без определенной схемы, структуры значений. Благодаря поэтому, что это очень просто структура, она имеет высокую скорость и легко масштабируется. В нас уже есть ключи, и мы можем очень легко их шардировать, сделать их хэши. Это одна из наиболее высокомасштабируемых баз данных.

Примеры - Redis, Memcached, Amazon DynamoDB, Riak, LevelDB. Вы можете посмотреть особенности реализации именно key-value хранилищ.

Магазины широких столбцов [24] имеют столбцы и семейства столбцов как базовые сущности. Факты или данные группируются вместе для формирование столбцов, которые упорядочены в виде семейств столбцов, являющихся конструкциями, подобными к таблиц в реляционные базы данных. Например, данные о личность, такие как имя, имя и адрес, являются фактами об отдельных и могут быть сгруппированы вместе, чтобы создать строку в реляционной базе данных. Напротив, такие же факты организованы в виде столбцов в магазине с широкими колонками, и каждая из колон включает несколько групп.

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

Другие названия таких баз данных включают ориентированную на столбце СУБД, столбчатые базы данных да семейства столбцов.

Ключевые преимущества [24] использование баз данных с широким столбцом:

Представим, что в нас есть огромная таблицы. И если бы мы хранили данные строками, это было бы то, что внизу: огромное количество строк. Для отъема даже за тремя параметрами этой таблицы нам нужно пройти по всей таблицы. А когда мы сохраняем значение за столбцами, то при отборе за тремя значениями нужно пройтись только за тремя вот таким, грубо

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

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

Самые популярные столбцовые базы данных - это, наверное, Кассандра, HBase и ClickHouse. Испытайте их. Очень интересно инвертировать в голове отношение строк и столбцов. И это действительно эффективный и быстрый доступ к большой количества данных.

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

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

Документоориентированные базы данных обходят документы. Итак, документ есть основной атомной единицей хранение в такой базе данных. Любая модель домена, какая разрешает разделять да распределять свои данные между документами, может использовать документ база данных. Некоторые общие примеры включают CMS, программное обеспечение для блогов да wiki- программное обеспечение. Однако, рассматривая эту модель данных, вы можете встретить случаи использования, когда реляционная модель может быть настолько же хорошим вариантом использовать как нереляционную базу данных.

Хранение ключевых значений - это общеупотребительные модели данных, предпочтительно для областей приложений, окружающих данные, например пользователя профиль, электронные письма, комментарии к блогу / статьи, информация о сеансе, данные корзины покупок, обзоры товаров, детали товара и В дополнение ко многим других таблицы пересылка протоколов Интернета (IP). Очень важно понять, что ключ-значение store можно использовать для хранения полных веб-страниц [25]. В этом случае URL-адрес можно использовать как ключ, а содержимое веб-страницы, как значение. Однако другие модели данных могут быть более подходящими для этой цели, если приложение этого требует.

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

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

Обсуждая пригодность решений NoSQL к реальных проблем, важно вспомнить CAP Теорема [27]. Эта теорема вводит понятие толерантности к разделов (P), доступности (A) да согласованности (C) для распределенных систем и утверждает, что все эти три характеристики не могут быть обеспечены решением одновременно.

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

Доступность определяет эксплуатационные требования системы, гарантирующие, что когда поступает запрос пользователем, он должен ответить на нее, несмотря на ее состояние. Толерантность разделов относится к способности системы работать, несмотря на выход с лада раздела да потерю сообщений. Это также можно описать как способность системы работать независимо от сбоя сети. Различные решения баз данных и их статус CAP были описано ниже. Отмечено, что ни одна распределенная система не может владеть всеми тремя характеристиками. На основании этого по утверждению, системы NoSQL могут быть CA (последовательно доступны), AP (толерантны к доступным) разделов) или CP (последовательные толерантные к разделам) [28].

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

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

Рисунок 2.7 иллюстрирует классификацию решений NoSQL на базе данных. Подробное описание реализаций вместе с поддерживаемыми моделями данных приведены в таблице 2.1. «+» указывает на поддержку соответствующих данных модель, тогда как «-» нет предлагает никакой поддержки для соответствующей модели данных.

Таблица 2.1 Анализ баз данных с указанием поддерживаемых моделей

Продолжение таблицы 2.1

Продолжение таблицы 2.1

Продолжение таблицы 2.1

Продолжение таблицы 2.1

Продолжение таблицы 2.1

Продолжение таблицы 2.1

Продолжение таблицы 2.1

Hadoop предлагает один с наиболее экономически эффективных да эффективных способов хранения данных в огромных объемах Более того, структурированные, полуструктурированные да неструктурированные типы данных можно хранить, а затем обрабатывать с помощью таких инструментов, как Pig, Hive и Spark, чтобы получить результаты, необходимы для любого будущего анализа или визуализации. Hadoop разрешает пользователю сохранять данные в своему хранилища несколькими способами. Некоторые общедоступны да понятны рабочие форматы включают XML, CSV да JSON.

Хотя JSON, XML и CSV – это удобные для чтения форматы, но это не лучший способ хранить данные на Hadoop. На самом деле, в некоторых случаях хранение данных в таких необработанных форматах может оказаться очень неэффективным.

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

CERN [29] выбрал четыре технологии-кандидаты, ORC Parquet, Kudu и Avro для этой цели. Однако мы включили в это другие форматы файлов данных, такие как Arrow да текстовые форматы дискуссия для понятности. 3 показывает классификацию и иерархию форматов больших данных. Каждый из форматов файлов имеет ряд преимуществ да недостатков в названии. Этот раздел исследует или аспекты файла больших данных форматов и обеспечит обсуждение критериев, которые необходимо использовать для выбора формат файла.

Текстовые форматы

Самый простой пример такого формата файла данных – это записи, что сохраняются поочередно, заканчиваемые символом новой строки или возврат кареты. Для сжатия данных нужно использовать кодек сжатия на уровни файла, такой как BZIP2. Три в этой категории доступны форматы, а именно текст или CSV, JSON да XML.

Обычный текст

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

XML

Можно использовать внешние определение схем в XML. Однако исполнение сериализации да десериализации, как правило, плохая.

JSON

JavaScript Object Notation (JSON) эффективнее XML, но проблема в эффективности сериализации да десериализации существует.

Файл последовательности

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

Avro

Apace Avro используется для компактного двоичного формата как стандарт сериализации данных Как правило, он используется для хранения постоянных данных, связанных с протоколами связи и HDFS. Одна из главных преимуществ использование Apache Avro отличается высокими показателями поглощение, что объясняется быстрой да легкой десериализацией да сериализацией, предусмотренной прежним. Важно отметить, что Avro не имеет внутреннего индекса Однако технику разделение на основе каталогов, доступную в HDFS, можно использовать для облегчение случайного доступ к данным. Сжатие данных алгоритмы, поддерживаемые Apache Avro, включают DEFLATE и Snappy.

Существуют другие рамки сериализации да десериализации, такие как буферы экономности и протокола [30] конкуренция с Авро. Однако Avro является встроенным компонентом Hadoop, хотя эти рамки есть внешними.

Кроме этого, определение схемы в Avro выполняется с помощью JSON, тогда как буферы Thrift и Protocol зависят от интерфейса языка определения (IDL) [30] для определение схемы

Формат файла столбчатого записи (RC)

Это самый примитивный столбчатый формат записей, созданный в рамках проекта Apache Hive. RCFile [31] – это двоичный формат, подобный к SequenceFile, какой обеспечивает высокое сжатие для операций, что включают несколько строк.

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

Оптимизированный формат файла столбца (ORC)

Оптимизированный столбик строк [32] похож на Parquet да RCFile в в том смысле, что все эти три формата файлов данных существуют в рамках Hadoop. Производительность чтение лучше. Однако записи медленнее за средние.

Кроме того, возможности кодирования и сжатия этого формата файла лучшие, нож в его аналогов, с ORC, что поддерживает Zlib и Snappy.

Parquet

Apache Parquet [33] – стандарт сериализации данных, который ориентирован на столбцы и, как известно, улучшает эффективность существенно. Этот формат данных также включает в себя оптимизацию, как сжатие ряда принадлежащих значений к колонны, что приводит к улучшение коэффициентов уплотнение. Кроме этого, такие кодирование, как упаковка битов, словарь да запуск кодирование длины являются дополнительной оптимизацией. Для сжатия данных Snappy и GZip поддерживаются алгоритмы.

CarbonData

Этот формат данных был разработан Huawei для управления имеющимися недостатками в уже доступных форматах.

CarbonData - относительно новый формат файла данных, какой разрешает разработчикам воспользоваться преимуществами ориентированных на столбце хранения, а также предоставляет поддержку для обработки запросов произвольного доступа. Данные сгруппированы в блокеты, хранящиеся рядом с другой информацией о таких данные, как схема, индексы да оползни, кроме других. Метадани есть сохраняется в

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

Форматы в памяти

Apache Arrow [34] - это платформа для разработки программ, что используют данные в памяти. Более того, это работает по всему языку, что делает его стандартом для столбчатого формата памяти поддержку как иерархического, так и плоского языка данных. Данные организованы для обеспечение высокопроизводительной аналитики современного оборудование. Межпроцессовый связь поточного передача работает на нулевой копии или не имеет десериализации и сериализации. Кроме этого, он предлагает много вычислительные библиотеки для сложных задач.

Kudu [35] – это система хранения, которая обеспечивает масштабируемость и базируется на концепции распределенного хранилища. Данные хранятся внутри таблиц. Больше того, этот формат данных обеспечивает оптимизированный компромисс между производительностью да скоростью проглатывание, какое приписывается столбчатой организации данных и поддержке индекса. Сжатие данные алгоритмы, поддерживаемые Apache Kudu, включают LZ4, Zlib и Snappy.

Сравнение форматов файлов больших данных

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

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

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

Использование соответствующего формата файла может воспользоваться системой следующими способами:

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

Таблица 2.2 Сравнение форматов файлов данных

Продолжение таблицы 2.2

Продолжение таблицы 2.2

С сравнительной таблицы можно сделать заключение, что хочет текстовые форматы просты и легки, они представляют множество недостатков, которые могут существенно повлиять на производительность системы. Для того, чтобы преодолеть ограничение текстовых форматов, Hadoop имеет встроенные форматы файлов данных. Первый из этих форматов – это данные на основе строк формат файла под названием SequenceFile (файл последовательности) [36]. Другие форматы файлов данных, которые базируются на SequenceFile да включены к экосистемы Hadoop включает MapFile, SetFile да BloomMapFile. Или форматы файлов назначены для специализированных случаев использование. SequenceFile поддерживает только Java, что делает его зависимым от языка и не поддерживает версии. Как результат, Avro, какой преобладает SequenceFile, оказался наиболее популярным на основе строк форматом файла данных. Понятно, что Avro есть лучшим вариантом среди форматов файлов данных на основе строк.

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

Важно отметить, что для форматов файлов данных, ориентированных на столбцы, нужен буфер для разделения строк, поскольку он работает больше одного строки одновременно. Больше того, невозможно контролировать процесс написание. Если процесс не удается, текущий файл нельзя восстановить. Это причина, почему форматы, ориентированные на столбце, не используются для потоковой передачи. Кроме того, использование Avro позволяет читать к того момента, к которого состоялась синхронизация. Флюм делает использование форматов, ориентированных на строки, благодаря этой свойства [37].

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

RCFile [27] – это наиболее примитивный формат файла данных на основе столбцов, а ORCFile – это оптимизированная версия. Хотя ORCFile [32] считается пригодным для приложений с транзакциями ACID и предлагает быстрый доступ с его функцией индексирования, Parquet продвигается Cloudera и, как известно, самое лучшее работает с Spark. Самым совершенным да новейшим форматом файлов в этой категории есть CarbonData [38] но благодаря новом статуса совместимость с технологиями сомнительна. Это делает Parquet самым популярным форматом файла данных на основе столбцов.

Arrow и Kudu [35] поддерживают столбчатое представление с той разницей, что Arrow поддерживает "in-memory" хранение, в тот время как Kudu обеспечивает хранилище, которое можно изменять на диске против формата Parquet, какой неизменный на диска и на дисковом хранилище. Компромиссы за использование неизменного формата файла данных (Parquet) включают большее пропускную способность для записи, проще одновременный общий доступ, доступ и тиражирование, а также отсутствие накладных расходов, связанных с операциям. Однако для изготовление любых модификаций, набор данных нужно переписать. Изменяемый (Kudu) обеспечивает большую гибкость в компромисс между скоростью обновления и чтения. Время задержки короткого доступ ниже через репликацию кворума и индексацию первичного ключа. Более того, семантика подобна семантике баз данных. С учетом этого отдельный демон это необходимость для управление.

Сравнивая память Parquet на диске с временной памятью Arrow, важно заметить, что первый разрешает получить доступ к нескольких запросов с приоритетом, предоставляемым уменьшению ввода-вывода, но пропускная способность процессора должна быть доброй, однако хранилище на диска считается пригодным только для поточного доступа. С другого стороны, в памяти хранилище поддерживает потоковую передачу, а также произвольный доступ и ориентированное на исполнение одного запроса. В этом случае пропускная способность процессора является приоритетной, хотя пропускная способность ввода-вывода также должно быть хорошим. Некоторые проекты используют Arrow и Parquet вместе. Pandas [39] – один из примеров такого использования. Кадр данных от Pandas можно сохранить на паркете, который затем можно прочитать на стрелке. Способность Pandas работать на колоннах Arrow разрешает это легко интегрировать с Spark.

Технологии, что используются для хранение больших данных, с временем созрели, чтобы уступить местом таким технологиям, как блокчейн, какой продемонстрировал значительное рост популярности да использование в обширной коллекции доменов [40]. Как есть в случае с любой технологией, которая используется в разных доменах, в ней было определено несколько проблем и проблем приложения к реальным сценариям. Одной из самых глубоких проблем этой технологии есть масштабируемость.

Однако способность этой технологии вывести Интернет на следующий этап путем создание децентрализованной сети делает это стоим обсуждение.

Одним с фундаментальных компонентов децентрализованной сети есть децентрализованное хранилище [41]. на приложение к блокчейн, некоторые другие технологии, такие как Интернет вещей (IoT) да искусственный интеллект, также есть испытательные полигоны существующих решений для хранение данных да их возможности. Подъем Интернета вещей (IoT) да его ожидается, что покрытие 20 миллиардов подключенных устройств к 2020 года нуждается приобретение, хранение, управление да обработка огромных резервов данных.

Спрос на решения для хранения данных растет, учитывая проблемы, перед управлением данными подключены устройства, обмен данными и необходимость персонализации в приложениях[42]. Происходит изменение подхода к интенсивно используемых данных, особенно с обзора на зависимость компаний от купи данных. Однако, или данные сохраняются в централизованных центрах обработки данных, что приводит к многочисленным нарушениям безопасности и проблем [43]. Этот аргумент поддерживает использование децентрализованных решений для хранение данных.

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

Поэтому, когда или решение вынуждены выполнять свои возможности, они потребляют больше пространства и больше времени. Видение децентрализованного хранение - объединить особенности технологии блокчейна с решениями могут удовлетворить практические требования хранения обширных данных. С самой названия видно, что распределенное хранилище делит данные на меньшие единицы данных и распределяет их по разных узлах, где они хранятся. Эта характеристика может быть по сравнению с технологией распределенной книги [44], которая обычно ассоциируется с блокчейном. В настоящее время даже облачные базы данных слишком централизованные и их легко ориентировать хакеры [45]. Больше того, пункты поражения очень очевидны, что делает их тем более, что их легче атаковать. Отключение электроэнергии является одной из таких точек отказа[46]. Напротив, децентрализованная система лишена таких проблем ввиду того, что узлы есть географически удаленные да физически нет связаны. Итак, ожидается отключение или атака на месте отказа, что влияет только на соответствующий узел. В общем, система будет оставаться неизменной, как и другие узлы системы продолжайте функционировать как обычно. Кроме того, что делает систему надежной и доступной, децентрализация также способствует масштабированности и производительности системы [47].

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

Данные сохраняются и управляются путём создания большой группы узлов, которая называется роем. Эта группа узлов подобна сети узлов, созданных для блокчейную.

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

Выводы

РАЗДЕЛ 3

ПРАКТИЧЕСКОЕ ПРИМЕНЕНИЕ НА ПРИМЕРЫ РАБОТЫ С МЕДИЦИНСКИЙ ДАННЫМИ

Результат каждого обследования – это заполненный медицинским работником протокол исследование. Все данные можно разделить на три категории:

Множество измерений и информация о визите к врачу предназначены для описания изучаемого объекта – анатомии. Однако наша сущность анатомии имеет более широкое значение, чем анатомия в биологическом смысле. Она включает в себя части тела (голова, шея и т.п.), органы (печень, сердце и т.п.), ткани, продукты жизнедеятельности организма (мочь, кал), кости, жидкости, что есть деятельностью любых органов (грудное молоко, секрет предстательной железы), разные новообразование, слизистые оболочки, микроорганизмы да другое. С одного стороны, все объекты входят в разные системы – функциональный подход. С другой стороны, можно разглядеть данные в структурном срезе. Именно так возникает иерархия анатомии – исследуемый объект.

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

Множество измерений, например, лабораторные исследования, каждое из которых могут иметь текстовое значение да числовое (диапазоны значений), поскольку много параметров (например, размеры органов, частота сердечных сокращений, количество имеющихся веществ) зависит от таких данных как возраст, пол, рост, вес, фаза цикла, беременность, курение, время взятия анализа. Для числового значения используется референтный интервал. Референтный интервал – это границы нормы.

Множество мультимедийных материалов занимает значительный объем в медицинских. информационных системах и важно источником данных при диагностике, оценке и планировании терапии. Например, компьютерная томография, магнитно- резонансная томография, рентген, молекулярная визуализация, ультразвуковое исследование, Фотоакустическая томография, рентгеноскопия, позитронно- эмиссионная томография с компьютерной томографии.

Семейство нереляционных моделей данных разделяют на четыре виды: ключ-значение, документоориентированные, столбцовые и графовые базы данных. Проанализировав каждый вид, для медицинских карт были выбраны документо- ориентированную базу данных.

База данных NoSQL, какая использует документы для хранение да поиск данных, называется документо-ориентированной базой данных[48]. Другие названия этой модели данных NoSQL – это база данных документов [49] и хранилище документов [50]. Она прежде всего используется для управление полуструктурированными данными из-за гибкости и поддержки переменной схемы. Документо-ориентированные базы данных очень похожи на ключ-значения в некоторых из областей их применение. Но в них единицей является документ.

Каждый документ может хранить в себе, как правило, XML, JSON или BSON – бинарно-сохраняемый JSON. Но сейчас практически всегда JSON или BSON.

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

К примеру, профили пользователей. Кто-то указал свой любимый фильм, кто-то – любимую пищу. Чтобы не засовывать все в одно поле, которое будет хранить непонятно что, мы можем все записать в JSON документоориентированных базы данных.

Документы группируются вместе, образуя структуру, которая называется коллекцией[5]. Может быть несколько коллекций баз данных. Эта структура подобна функционирование таблицы, какая присутствует в реляционной базе данных.

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

Требования к базы данных

Кроме основных общепринятых требований к БД следует вывести собственные дополнительные требования, каким должна удовлетворять БД и соответственно СУБД управляющая ей.

3.3. MongoDB

В качества СУБД решено выбрать MongoDB. MongoDB - это кросс- платформенная документоориентированная система управление базами данных с открытым кодом.

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

В кратком учебнике MongoDBTheLittleMongoDBBook от автора KarlSeguin [51] приведены шесть основных концепций MongoDB:

"Документов". Документ есть аналогом записи в таблицы (строки).

Документ состоит из одного или более «полей», поля, в свою очередь, есть аналогом "колонки".

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

Основная же отличие документоориентированных баз данных от реляционным является то, что в реляционных базах данных «колонки» определяются на уровни «таблицы», тогда как документоориентированных базы данных определяют

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

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

BSON - это практически то же именно, что и JSON (распространенный формат представление данных в web), но в бинарном виде. Тот факт, что данные сохраняются именно в бинарном виде, значительно ускоряет время их обработки.

3.4.1. Представление данных в БД

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

Также приведено частичное решение проблемы локализации основных элементов данного формата В конце приведены листинги с моделями основных документов с комментариями.

Основными документами в базе данных есть: "Пациент" ("Testsubject"), "Врач" ("Researcher") и "Исследование" ("Research"). Все документы сохраняются в своей отдельной коллекции, соответственно "Пациент", "Врач", "Исследование". на рисунка 3.3 наглядно показаны связи между тремя основными объектами базы данных Все документы хранятся в своей отдельной коллекции, соответственно "Пациенты", "Врачи", "Исследование".

Врач

Документ "Врач" есть аккаунтом реального научного сотрудника и содержит в себе:

Пациент

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

исследование

Документ "Исследование" является связующим звеном, предоставляемым "Врачам" доступ к данным определенного набора "Пациентов". Только из-за него большинство научных сотрудников ("Врачей" в БД) смогут получить доступ к данным "Пациента", исключение могут составлять только "Врачи", имеющие приоритетные права доступа в коллекцию "Пациенты". Документ "Исследование" содержит в себе:

Для удобства структурирования данных хранятся внутри основных объектов, используются секции. Структура документов в MongoDB позволяет хранить документы внутри документов, такой подход в MongoDB называется денормализованная модель данных.

"Секция" есть отдельным документом и сохраняется внутри основных документов ("Пациент", "Врач", "Исследование") или же проще говоря, основные документы состоят из "секций".

Важно отметить тот факт, что основные документы не ссылаются на свои "Секции", а каждая "Секция" сохраняется именно внутри своего основного документа. Также стоит заметить, что для хранение списка "Врачей" и "Пациентов" в "Исследование" используются массивы (данный тип данных также присутствует в MongoDB), в которых уже как раз будут храниться ссылка на соответствующие объекты.

"Пациент" имеет разный набор секции. Дополнительные секции создаются пользователем (научным сотрудником) в которого есть право для добавление новых и изменения данных уже существующих "Пациентов".

Для того, чтобы сохранять созданы пользователем новые типы секций и исключить создание дубликатов, создается коллекция секций. Вернее говоря коллекция типов секций, в которой хранятся "скелеты" уже созданных секций. В листинге 2.1 приведена структура документа "Секция" в формате JSON (в подобном виде она сохраняется в MongoDB), в комментарии приведены объяснение основных полей.

Задача

"Задания" ("Issues") является необходимым документом для распределения задач между врачами. Каждый врач может назначить определенное "Задача" другому врачу, если только этот врач не выше его в правах доступа. "Задача" также может быть назначена и самому себе, например, нужно, чтобы определенная деятельность была зафиксирована и ее, на текущий момент, может выполнить только сам врач, тогда он просто назначает сам себе "задание".

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

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

Структура документа "Задача" приведена в листинга 2.2.

Роли

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

Рис. 3.6 Модель документа "Роль" Каждая роль имеет следующий набор полей:

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

Листинги основных объектов

{

_id : <Researcher-ID>,

rer_main_section : {

_id : <Section-type-ID>,

sec_data : {

// идентификатор врача, генерируется случайно

// секция с основными данным

last_name : <'Фамилия'>,

first_name third_name : <'Имя'>,

age

: <'Отчества'>,

: <Bool>,

: <'Возраст'>,

// true - мужской, false - женский

dBirth : <'Дата рождение'>

job : <'Место работы'>

}

},

rer_resources_section : {

_id : <Section-type-ID>,

sec_data : {

equipment : [

{

// ресурсная секция

// массив оборудование

eq_name : <'Название оборудование'>,

eq_desc : <'Описание оборудование'>

},

...,

{

eq_name : <'Название оборудование'>,

eq_desc : <'Описание оборудование'>

},

] ,

methods : [ //Массив исследовательских методов

{

md_name : <'Название метода'>,

md_desc : <'Описание метода'>

},

...,

{

md_name : <'Название метода'>,

md_desc : <'Описание метода'>

},

] ,

}

},

rer_busyness_section : {

_id : <Section-type-ID>,

sec_data : {

// бизнес секция

status : <'Текущий статус (занят; свободный ...'>,

role : <Role-ID>

}

},

rer_db_section : { // секция с флагами базы данных

_id : <Section-type-ID>,

sec_data : {

login : "Login", // Логин врача

pass : "Password hash", // Хешкод пароля для входа в систему

deleted : <Bool>, date_created : <date>, date_modified : <date>

}

}

}

Листинг 2.4. Модель документа "Врач"

Рис. 3.7 Модель документа «Врач»

{

_id : <TestSubject-ID>,

ts_main_section : {

_id : <Section-type-ID>,

// идентификатор пациента, генерируется случайно

// секция с основными данным

sec_data : {

last_nam e first_nam e third_ n : a m < e ' П a р n и o из n в y и m еще ' s > e , x

age

: <'Имя'>,

: <'Отчества'>,

: <Bool>,

: <'Стать'>,

: <'Возраст'>,

// если значение true, то вышеописанные поля пустые и

// нет рассматриваются

dBirth : <'Дата рождение'>

}

},

ts_0_section : { // назначена для пользователя секция

_id : <Section-type-ID>,

sec_data : {

data1 :

<Some- Data>, data2 :

<Some- Data>, data3 :

<Some- Data>,

...

dataN : <Some-Data>,

}

},

...

ts_N_section : {

_id : <Section-type-ID>,

sec_data : {

data1 : <Some-Data>, data2 : <Some-Data>, data3 : <Some-Data>,

...

dataN : <Some-Data>,

}

},

db_section : { // секция с флагами базы данных

_id : <Section-type-ID>,

sec_data : {

deleted :

<Bool>,

date_created :

<date>,

date_modified

: <date>

}

}

Листинг 2.5. Модель документа

"Пациент"

Рис. 3.8 Модель документа «Пациент»

Выводы

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

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

ОБЩИЕ ВЫВОДЫ ПО РАБОТЕ

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

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

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

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

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

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

формат на основе строк. SequenceFile и Avro относятся к этой категории, среди которых первая есть наиболее примитивной на основе строк формат, что предоставляется пользователям. Также доступны другие специализированные форматы на основе строк, которые используют SequenceFile в своей основе в Хадупе. До их принадлежат MapFile, SetFile и BloomMapFile. Avro – это наиболее часто используемый формат строк и есть лучшим для программ, которые могут требовать всех или большинства столбцов.

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

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

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

TRRao, P. Mitra, R. Bhatt, A. Goswami. // Knowledge and Information Systems.

– 2018. – С. 1–81.

2018.

Импала, and Spark. Apress / Quinto. – 2018.

A. J. Elmore. // Proceedings of the 14th International Workshop on Data Management on New Hardware. – С. 6.

– С. 595-604.

М. Ансар, М. Фатима. // International Journal of Computer Science and Network Solutions. – 2018. – №6. – С. 10–19.