Диссертация (Модели процессов согласования реплик в базах данных NoSQL), страница 21

Применяется дляслучаев заболевания человека и животных.Клинические признакиИнформацияопроявленииклиническихпризнаков:температура, лихорадка, язвы на коже и т.п. Применяется дляслучаев заболевания человека и животных. Варьируются отзаболевания к заболеванию.ДанныеИнформация, полученная в результате эпидемиологическогоэпидемиологическогорасследования. Например, данные о последнем контакте срасследованияживотными, поездками заграницу и т.п. Применяется дляслучаев заболевания человека и животных. Варьируются отзаболевания к заболеванию.Лабораторные данныеДанные о проведенных лабораторных исследованиях надсобранными образцами для случаев заболевания людей иживотных, а также их результаты. Применяется для случаевзаболевания человека и животных. Варьируются отзаболевания к заболеванию.Связьсовспышками Информация о связи конкретного случая с другими случаямизаболеваниязаболевания людей и животных.Указанные группы факторов необходимо анализировать в совокупностидруг с другом, что позволяет выявлять причины заболевания, специфику егораспространения, возможности дальнейшего распространения заболеваний и т.д.Если для хорошо известных заболеваний уже сформирован ряд критериев,позволяющихотслеживатьихактивность,тодляновыхзаболеваний,появляющихся в результате мутаций или передачи от животных к человеку,выявление факторов, влияющих на распространение и активность заболевания,является критически важной задачей.Рассматриваемая система состоит из двух блоков обработки данных,представленных на рисунке 5.1.130Пользователи системы123...KВвод данныхТранзакционныймодульРаспространение данныхАналитическиймодульАнализ данных123...FПользователи системыРисунок 5.1 – Модули информационной системы.1.

Транзакционный модуль – узел, занимающийся сбором, обработкой ипоследующей передачей данных на аналитический модуль. Данныйэлемент системы может работать на основе любой надежной реляционнойСУБД, поддерживающей ACID транзакции.2. Аналитическиймодуль–набор(кластер)узлов,занимающихсяаналитической обработкой данных. Это один из основных компонентовсистемы. Он позволяет представлять собранные данные в виде различногородаотчетов,строитьразнообразныедиаграммыиотображатьинформацию в привязке к географическим координатам на карте. Данныйэлемент системы позволяет параллельно обрабатывать аналитическиезапросы и выдавать отчеты различного уровня сложности.В штатном режиме работы системы число запросов, поступающих каналитическому модулю невысоко, с нагрузкой вполне может справится одинузел. Однако во время эпидемии нагрузка на систему может значительновозрасти.

Например, при вспышке заболевания, связанного с вирусом «Ебола»[73] в Западной Африке, число заболеваний за 4 месяца выросло в 100 раз [74].131При вспышке подобных заболеваний [75-77] многие аналитики во всех странахбудут заинтересованы получать актуальные аналитические отчеты о скоростираспространения вируса, числе заболевших и т.д. В дальнейшем рассматриваетсяаналитический модуль системы «Надзор за заболеваемостью – NoSQL».5.2. Обоснование выбора технологии NoSQLДо недавнего времени доступ к базе данных чаще всего осуществлялся сиспользованием классической реляционной системы управления базами данных(РСУБД).

В настоящее время львиная доля информации хранится в РСУБД. Этообъясняется внешней простотой реляционной модели, наличием такого мощногои в то же время простого для изучения языка доступа к данным, как SQL, а такженаличием оптимизаторов выполнения транзакций и запросов к базе данных,обеспечивающих их «дробление» на более мелкие задания и параллельнуюреализацию этих работ на многопроцессорных или многомашинных комплексах.Рассмотрим основные проблемы организации данных, которые могутвозникнуть при использовании реляционной базы данных в процессе реализациианалитического модуля:1.

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

существенноосложняется формирование агрегата. Операции соединения многих таблицвыполняются сравнительно медленно. Теоретически возможен вариантиспользования одной плоской таблицы. Но в таком случае таблица небудет находиться в третьей нормальной форме и будет обладать132недостатками, такими как избыточность, потенциальная противоречивостьи т.д. При этом объем базы данных может возрасти на порядок.2. Проблема сегментации данных. Как отмечалось в Глава 1, с увеличениемобъема хранимых данных возникает задача фрагментации таблиц базыданных по разным серверам, объединенных в кластер. Но параллельныесистемыреляционныхмасштабируемостьбазПри[5].данныхдемонстрируютвыполненииневысокуюсложныхзапросовпроизводительность системы существенно уменьшается в результатемежмашинного обмена данными между серверами кластера [6].3.

Проблема обеспечения отказоустойчивости. Как отмечалось в Глава 1, впараллельных системах баз данных число реплик невелико, что не можетгарантировать высокую отказоустойчивость. Более того, при отказекакого-либо узла необходимо перезапускать всю систему целиком.Базы данных NoSQL не имеют указанных недостатков (см. пункт 1.2.2),поэтому в данном проекте целесообразно использовать базу данных этого типа.5.3. АнализвариантовбазданныхNoSQLдляреализациианалитического модуляВ настоящее время под понятие «база данных NoSQL» попадает оченьширокий спектр систем хранения и обработки данных [78]: хранилища «ключзначение» (Riak, Redis, DynamoDB, Project Voldemort), хранилища семействстолбцов (HBase, Apache Cassandra, HyperTable), документо-ориентированные(CouchDB, MongoDB, eXist), базы данных на основе графов (Neo4j, OrientDB,InfiniteGraph).

Среди всего множества систем NoSQL в проекте былирассмотрены следующие базы данных: MongoDB, Apache Cassandra и Riak. Базыданных на основе графов не рассматривались, т.к. они не являютсяраспределенными (реплицируется весь граф).1. MongoDB.База данных MongoDB, реализованная на C++, обладает достаточно богатойфункциональностью и является одной из самых популярных систем NoSQL на133данный момент [79]. MongoDB позволяет оперировать JSON-документами,которые объединяются в коллекции. Каждый документ в коллекции долженсодержать уникальный идентификатор (сгенерированный автоматически илипользователем), который не может изменяться после создания документа.

Кромеидентификатора документ может содержать произвольный набор полей, включаямассивыивложенные документы. Системаподдерживаетработу сослабоструктурированными данными: документы в одной коллекции могутсодержать разные наборы полей. Масштабируемость в MongoDB достигается засчет «сегментирования», т.е. распределения документов коллекции по узлам наоснове выбранного ключа (shard key).

Также поддерживается репликация врежиме «главный-подчиненный»: операции записи обрабатываются толькоглавным узлом, а операции чтения могут выполняться на главном узле или наподчиненных узлах (рисунок 5.2).ГавныйЗаписьЗаписьПодчиненныйПодчиненныйЧтениеКлиентКлиентРисунок 5.2 – Репликация в MongoDB.Клиент может работать в разных режимах: неблокирующем (не дожидаясьподтверждения завершения операции) или блокирующем (ожидая подтвержденияот заданного количества узлов).Однако в MongoDB отсутствует одноранговая репликация,разрешаются по временной метке (last write wins).2.

Apache Cassandra.конфликты134Это распределенная база данных, она написана на языке Java. Поорганизации модели данных Cassandra похожа на BigTable и Hbase, однакотерминология и детали несколько различаются. Здесь база данных называется«пространством ключей» (keyspace) и содержит семейства столбцов (columnfamily), которые являются аналогами таблиц и служат контейнерами для строк(рядов, rows), идентифицируемых уникальными ключами (row key).

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

Параметры репликации W и Rмогут задаваться на уровне запросов к базеданных.Данныесегментируютсяпоузлам,используяконсистентноехеширование. Согласно [80] операции модификации данных атомарны на уровнестрок таблицы (т.е. записей).Также как в MongoDB, конфликты разрешаются только с использованиемвременной метки.3. Riak.Riak – мощная система управления данными типа «ключ-значение» соткрытым исходным кодом, она написана на языке Erlang.

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

Riakиспользует механизм ведения версий записи базы данных (Vector Clock) дляреализации параллельного доступа к этой записи (опционально). Конфликтыобновлений могут разрешаться либо по временной метке, либо на уровне135приложения (в этом случае приложению возвращаются конфликтующие версииобъектов, т.е. записей БД). Поддерживаются триггеры (называемые «commithooks»), позволяющие запускать функции на JavaScript или Erlang перед илипосле модификации объекта.Ключи в Riak объединяются в сегменты, что позволяет задавать параметрырепликации, список триггеров, метод разрешения конфликтов на уровне сегмента.Таким образом, объект однозначно идентифицируется парой (сегмент, ключ).Каждый объект содержит метаданные, в том числе поддерживаются ссылки надругие объекты.