Содержание к диссертации
Введение
Глава 1. Анализ существующих методов оценки показателей качества согласования реплик в базах данных NoSQL 10
1.1. Тенденции развития рынка Больших Данных (Big Data) 10
1.2. Реляционные базы данных и хранилища NoSQL
1.2.1. Преимущества и недостатки реляционных баз данных 11
1.2.2. Преимущества и недостатки баз данных NoSQL 14
1.2.3. Классификация баз данных NoSQL 17
1.3. Функции согласования реплик в базах данных NoSQL 18
1.3.1. Размещение реплик записей БД в кластере и обеспечение их согласования при обновлении записи 19
1.3.2. Влияние параметров N, W, R на показатели согласования реплик 24
1.3.3. Ведение версий реплики и их согласование 27
1.3.4. Согласование реплик после устранения сбоя или отказа в узле 31
1.4. Анализ существующих моделей и методов оценки показателей качества
функционирования баз данных NoSQL 32
1.4.1. Анализ методов повышения качества согласования данных 32
1.4.2. Анализ моделей и методов оценки характеристик согласования реплик NoSQL 37
1.4.3. Анализ методов оценки показателей отказоустойчивости в базах данных NoSQL 39
1.5. Постановка задачи 41
Выводы по 1-й главе 43
Глава 2. Разработка моделей процессов согласования реплик в базах данных NoSQL 45
2.1. Разработка моделей процессов согласования реплик при обновлении какой-либо записи
базы данных 45
2.1.1. Преобразование Лапласа-Стилтьеса 46
2.1.2. Разработка модели процесса согласования реплик в конечном счете 47
2.1.3. Разработка модели процесса строгого согласования реплик 51
2.1.4. Преобразование Лапласа-Стилтьеса функции распределения вероятностей времени обновления i-й реплики 55
2.2. Анализ моделей процессов согласования реплик при обновлении какой-либо записи базы
данных 59
2.2.1. Анализ моделей согласования реплик в конечном счете 59
2.2.2. Анализ модели строгого согласования реплик 62
2.3. Разработка модели процесса ведения версий записи 64
2.3.1. Ведение вектора часов в базах данных NoSQL 64
2.3.2. Вариант 1 модели – время обработки версий записи клиентом зависит от текущего числа этих версий 66
2.3.3. Анализ варианта 1 модели ведения версий записи 70
2.3.4. Вариант 2 модели - время обработки версий записи клиентом зависит от числа обновлений, выполненных ранее другими клиентами 71
2.3.5. Анализ варианта 2 модели ведения версий записи 74
2.3.6. Анализ стационарности и эргодичности модели ведения версий записи 75
2.4. Разработка моделей отказов и восстановления доступа к записи в базах данных NoSQL 77
2.4.1. Аналитическая модель отказов и восстановления доступа к записи в базах данных NoSQL 77
2.4.2. Имитационная модель отказов и восстановления доступа к записи в базах данных NoSQL 78
2.4.3. Оценка времени восстановления узла в базах данных NoSQL 80
2.4.4. Анализ и сравнение аналитической и имитационной моделей отказов и восстановления доступа к записи в базах данных NoSQL 84
Выводы по 2-й главе 89
Глава 3. Анализ адекватности моделей 91
3.1. Описание экспериментальной установки 91
3.2. Анализ адекватности модели (1) процесса согласования реплик в конечном счете
3.2.1. Подготовка эксперимента 1 93
3.2.2. Проведение экспериментов и оценка адекватности модели (1) 95
3.3. Анализ адекватности модели (2) процесса строгого согласования реплик 100
3.3.1. Подготовка эксперимента 2 100
3.3.2. Проведение экспериментов и оценка адекватности модели (2) 102
3.4. Анализ адекватности модели (3) процесса ведения версий записи 106
3.4.1. Подготовка эксперимента 3 106
3.4.2. Проведение эксперимента и анализ адекватности модели (3) 110
Выводы по 3-й главе 113
Глава 4. Разработка инструментального средства анализа процессов согласования реплик в базах данных NoSQL 114
4.1. Подсистема для работы с моделями согласования реплик 114
4.2. Подсистема для работы с моделью ведения версий записи 118
4.3. Подсистема для работы с моделями отказов и восстановления доступа к записи 122
Выводы по 4-й главе 124
Глава 5. STRONG Использование разработанных моделей и инструментального средства на этапе
проектирования информационной системы STRONG 126
5.1. Описание предметной области 127
5.2. Обоснование выбора технологии NoSQL 131
5.3. Анализ вариантов баз данных NoSQL для реализации аналитического модуля 132
5.4. Построение структуры хранилища данных аналитического модуля 135 5.5. Оценка показателей производительности, согласования реплик и отказа в доступе к записи базы данных 140
5.6. Выбор параметров репликации сегментов хранилища 144
Выводы по 5-й главе 145
Заключение 147
Литература
- Размещение реплик записей БД в кластере и обеспечение их согласования при обновлении записи
- Разработка модели процесса согласования реплик в конечном счете
- Вариант 2 модели - время обработки версий записи клиентом зависит от числа обновлений, выполненных ранее другими клиентами
- Проведение экспериментов и оценка адекватности модели (1)
Введение к работе
Актуальность. В последние несколько десятилетний в области обработки данных доминировали реляционные СУБД. В таких системах данные хранятся в виде таблиц, они также предполагают наличие схемы базы данных. Но при создании больших систем (Big Data) с использованием реляционных СУБД разработчики стали испытывать значительные затруднения: 1) осложнилась процедура агрегирования данных, т.к. это требует чтения записей из большого числа связанных таблиц (возникла проблема потери соответствия), 2) возникло противоречие между необходимостью хранения больших объемов неструктурированных данных и необходимостью их как-то структурировать посредством разработки схемы базы данных, 3) для хранения больших объемов информации необходимо покупать дорогие специализированные аппаратно-программные комплексы параллельных систем баз данных (Teradata, Sun Oracle Database Machine и др.), 4) при наличии большого числа узлов возникает проблема обеспечения требуемой отказоустойчивости системы.
Как попытка решить накопившиеся проблемы реляционных баз данных появились альтернативные средства хранения и обработки данных, получившие название «базы данных NoSQL». Пионерами в этой области выступили две компании: Google и Amazon. В БД NoSQL для обеспечения высокой отказоустойчивости используется многократная репликация (копирование) записей. Но базы данных NoSQL обладают недостатком: в этих системах не поддерживается режим ведения транзакций и блокировок, поэтому возникает проблема согласования реплик. В диссертации под согласованием реплик понимается 1) согласование реплик какой-либо записи после обновления одной из этих реплик (распространение обновлений), 2) согласование версий реплики (сведение нескольких версий записи к одной записи), 3) согласование (восстановление) реплик после устранения сбоя в узле.
Важными показателями согласования реплик в системах баз данных NoSQL являются вероятность чтения устаревшей записи за время распространения обновлений по узлам системы, время ожидания начала чтения записи из обновленного кворума серверов, число версий записи в базе данных NoSQL и время их обработки, вероятность отказа в доступе к записи БД и др. Эти характеристики необходимо оценивать на этапе проектирования системы, т.к. это позволяет избежать ручного подбора значений требуемых параметров для большого числа типов записей БД на этапе наладки системы и необходимости натурного моделирования экстремальной нагрузки на систему.
Так как технология разработки информационных систем на основе баз данных NoSQL является достаточно новой, математические модели, необходимые для оценки показателей согласования реплик, либо отсутствуют, либо являются неадекватными.
Поэтому разработка адекватных математических моделей и программных средств, позволяющих на этапе проектирования систем NoSQL оценивать показатели согласования реплик и выбирать требуемые параметры, является актуальной задачей.
Цель работы. Целью работы является разработка математических моделей и программных средств оценки показателей согласования реплик в базах данных NoSQL на этапе проектирования информационных систем.
В работе решаются следующие задачи:
разработка аналитических и имитационных моделей процессов согласования реплик в базах данных NoSQL;
разработка инструментального средства анализа показателей согласования реплик на этапе проектирования информационной системы;
применение разработанного инструментального средства для анализа показателей согласования и выбора параметров репликации на этапе проектирования информационной системы.
Объект исследования. Объектом исследования являются распределенные базы данных NoSQL.
Предмет исследования. Предметом исследования являются процессы согласования реплик в распределенных базах данных NoSQL.
Научная новизна (положения, выносимые на защиту). В работе получены следующие новые научные результаты:
1. Разработаны аналитические модели процессов согласования реплик в
конечном счете, позволяющие рассчитать вероятность чтения устаревшей за
писи из базы данных NoSQL для режимов синхронного и асинхронного об
новления записи.
-
Предложена аналитическая модель процесса строгого согласования реплик, которая позволяет оценить характеристики случайного времени ожидания начала чтения записи из обновленного кворума серверов.
-
Разработана имитационная модель процесса ведения версий записи, позволяющая получить характеристики случайного числа версий записи в базе данных NoSQL и времени их обработки.
-
Предложена модифицированная модель «ремонтника», позволяющая оценить влияние числа реплик записи базы данных и режимов их восстановления на вероятность отказа в доступе к этой записи.
Методы исследования. Исследования проводились на базе комплексного системного анализа с использованием методов теории массового обслуживания, теории вероятностей и математической статистики, имитационного моделирования, численного дифференцирования.
Практическая ценность. Для оценки адекватности разработанных моделей реализованы натурные эксперименты в облачной среде DigitalOcean на кластере до 24 виртуальных узлов с использованием базы данных NoSQL Riak. Средняя относительная погрешность модели согласования реплик в ко-
нечном счете составила 7.86%, модели строгого согласования реплик – 7.42%, модели ведения версий записи – 4%.
Для практического использования полученных теоретических результатов разработано инструментальное средство анализа баз данных NoSQL (АПСОР), позволяющее оценивать показатели согласованности реплик, ведения версий записи, отказов и восстановления доступа к записи БД на этапе проектирования информационной системы.
Внедрение результатов исследований. Разработанные модели и инструментальное средство были использованы на стадии проектирования информационной системы «Надзор за заболеваемостью - NoSQL». Система обеспечивает сбор данных о заболеваниях и связанных с ними лабораторных исследованиях, обработку этих данных и предоставление полученных результатов аналитикам. С учетом специфики предметной области выполнено проектирование структуры аналитического компонента системы. В соответствии с предъявленными требованиями согласованности реплик было проведено исследование с помощью инструментального средства и определены параметры репликации для сегментов базы данных Riak: N=5, W=R=3 для строго согласованных сегментов и N=5, W=R=1 для сегментов, согласованных в конечном счете. Данные параметры обеспечивают заданные ограничения на показатели согласования реплик и отказов в доступе к записям БД Riak: вероятность отказа в доступе к записи - не более 10-12, вероятность доступа к рассогласованным данным - не более 0,1, задержка начала чтения - не более 2 мс.
Публикации по теме. По материалам работы опубликовано 15 печатных работ, из них 9 – в журналах, рекомендованных ВАК.
Апробация результатов. Материалы работы были изложены автором на следующих конференциях: XXIX Международная научно-практическая конференция «Естественные и математические науки в современном мире» (Новосибирск, 2015); XXXIV-XXXV Международная научно-практическая конференция «Научная дискуссия: вопросы технических наук» (Москва, 2015); XVII Международная научно-практическая конференция «Новое слово в науке и практике: гипотезы и апробация результатов исследований» (Новосибирск, 2015); XLV Международная научно-практическая конференция «Инновации в науке» (Новосибирск, 2015).
Область исследования из паспорта специальности 05.13.17. «1. Исследование, в том числе с помощью средств вычислительной техники, информационных процессов,…»; «2. Исследование информационных структур, разработка и анализ моделей информационных процессов и структур»; «3. …Разработка и исследование моделей данных и новых принципов их проектирования»; «12. Разработка математических, логических, семиотических и лингвистических моделей и методов взаимодействия информационных процессов, …».
Объем работы. Диссертационная работа содержит 157 страниц, 53 рисунка и 20 таблиц, список литературы из 101 наименования.
Размещение реплик записей БД в кластере и обеспечение их согласования при обновлении записи
Стандарт REST был описан в 2000 году одним из создателей протокола HTTP, Роем Филдингом [16]. Данные в REST должны передаваться в виде небольшого количества стандартных форматов (например, HTML, XML, JSON). Антиподом REST является подход, основанный на вызове удаленных процедур (Remote Procedure Call — RPC). Подход RPC, используемый в архитектуре «сервер приложений» [17], позволяет использовать небольшое количество сетевых ресурсов с большим количеством методов и сложным протоколом. При подходе REST количество методов и сложность протокола строго ограничены, из-за чего количество отдельных потребляемых ресурсов может быть большим [14].
Для достижения высокой горизонтальной масштабируемости и повышения производительности в NoSQL пришлось отказаться от ограничений ACID [3]. Это привело к появлению ряда существенных недостатков: 1. NoSQL невозможно использовать в приложениях, где ACID-транзакции необходимы: в банковских и других финансовых системах [18]. 2. Базы данных NoSQL обеспечивают согласованность копий записей (реплик) на разных серверах, но с некоторой задержкой, связанной с распространением обновлений по нескольким репликам (согласованность в конечном счете, Asynchronous Replication). Поэтому возможно чтение устаревших данных. Строгая согласованность записи/чтения обеспечивается только при наличии кворума реплик. Но это приводит к увеличению времени выполнения операций записи/чтения. 3. В NoSQL для доступа к данным необходимо использовать процедурный язык (в отличие от SQL, который является непроцедурным языком программирования). При этом сложность программирования возрастает. Например, чтобы выполнить соединение (join) нескольких таблиц, в SQL достаточно закодировать один оператор. Для реализации этого запроса в NoSQL программист должен представить его в виде нескольких заданий (job), для каждого из них написать программы Map и Reduce и запустить их в среде MapReduce. Отказ от поддержки ACID-транзакций оказывает сильное влияние на производительность баз данных NoSQL. Но отказ от свойств ACID не является полным. Например, в СУБД Riak [19] можно указывать процедуры, выполняемые до и после фиксации данных – это некоторая аналогия триггеров [20]. В [4] отмечается, что свойство атомарности реализуется за счет агрегации всех изменяемых данных в одной записи БД. Конечно, если клиенту необходимо обновить несколько взаимосвязанных агрегатов, атомарность не будет гарантироваться. Отказ в NoSQL от блокировки обновляемых записей БД привело к отказу от требования изолированности, поддерживаемого ACID-транзакциями.
Итак, и реляционные базы данных (РБД), и базы данных NoSQL имеют преимущества и недостатки. Стоунбрейкер, в частности, отмечает [21]: «Сейчас у каждого из вертикальных рынков имеются свои проблемы, для решения которых требуются наиболее удобные средства, и нет нужды ограничиваться унаследованными из прошлого реляционными системами». Каждый тип СУБД (РБД, NoSQL и др.) имеет свою нишу, и они еще долго будут сосуществовать вместе.
В NoSQL данные хранятся в виде записей ключ, значение . Эти базы являются сильно агрегатно-ориентированными [4], т.е. в качестве «значения» выступает агрегат. Выделяют четыре типа баз данных NoSQL [4, 22, 23]: «ключ-значение», документная, «семейство столбцов», графовая. В базе данных «ключ-значение» агрегат является непроницаемым для NoSQL. Чтение записи выполняется по ключу. Структуру агрегата видит только приложение. Поиск по индексу возможен для атрибутов, хранящихся в специальном заголовке записи (Riak). Примерами баз данных «ключ-значение» являются Riak, Redis, Amason Dynamo.
В остальных базах данных агрегат является проницаемым для NoSQL, т.е. база данных видит структуру агрегата. Чтение записи выполняется по значениям полей агрегата. Поиск по индексу возможен для атрибутов, хранящихся в агрегате.
В документной базе данных в каждом агрегате есть поле уникального идентификатора, которое используется в приложении как ключ. В качестве агрегата могут выступать данные, структура которых определяется конкретной базой данных NoSQL. Например, в агрегате базы MongoDB [24] хранится объект JSON (JavaScript Object Notation) / BSON (Binary JavaScript Object Notation) [25], который может содержать структуры с произвольным уровнем вложенности. Примерами документных баз данных являются MongoBD, CouchBD.
Базы данных «семейство столбцов» ориентированы на хранение данных по столбцам. Наборы столбцов в разных записях могут быть разными. Примерами этого типа баз данных являются BigTable, HBase, Cassandra.
В графовой базе данных данные представляются в виде графов: в виде вершин и связей между ними. Каждому узлу и связи соответствует запись базы данных, в агрегате которой сохраняются свойства соответствующего элемента графа. Приложение читает свойства исходного узла и связи и осуществляет переход к следующей вершите. Пример базы данных - Neo4j.
Разработка модели процесса согласования реплик в конечном счете
Формула (2.6) следует из (2.4). Формула (2.7) доказывается, исходя из классического определения вероятности - это отношение благоприятного числа комбинаций к общему числу комбинаций. В данном случае благоприятное число комбинаций - это число вариантов, при которых после поступления требования на чтение записи из необновленной реплики будет считано из БД (R-1) необновленных записей из оставшихся (N-W-i-І) необновленных реплик. Общее число комбинаций - это число вариантов, при которых можно считать данные из (R-1) реплик этой записи из ее оставшихся (N-1) реплик (обновленных и необновленных реплик).
Из (2.5) получим: Qw+i+1(0) - это вероятность, что за время обновления (\У+і+1)-ой реплики не поступят требования, по которым будут прочитаны R записей из N-W-i необновленных реплик, (1 - Qw+1+1(0)) - это вероятность, что за время обновления (\У+і+1)-ой реплики поступит хотя бы одно требование на чтение и по нему будет прочитано R записей из (N-W-i) необновленных реплик. Таким образом, вероятность, что за время обновления N-W реплик поступит хотя бы одно требование на чтение пары ключ/значение и по нему будет прочитано R записей из необновленных реплик, равна:
Выражение (2.8) следует из формулы полной вероятности. Это и есть вероятность, что клиент прочитает устаревшую запись за время распространения обновлений записи по ее N-W репликам. Синхронный режим обновления реплик поддерживает база данных NoSQL Riak. Этот режим поддерживает и система Hadoop. Только здесь обновления распространяются последовательно от предыдущей реплики к последующей.
На рисунке 2.3 представлена модель согласования реплик для случая W+RN (асинхронный режим) [88, 96, 97, 101]. Входящий поток требований на чтение из одной реплики также принимается пуассоновским с параметром .
На рисунке 2.3 введены следующие обозначения: ai – случайная сетевая составляющая времени обновления i-ой реплики, bi – случайная локальная составляющая времени обновления i-ой реплики. В каждый момент времени с интенсивностью независимо друг от друга поступают требования на чтение записи БД из каждой реплики. Случайные промежутки времени между началом обновления t0 и моментом поступления требования на чтение из i-ой реплики обозначим через i. Задача состоит в том, чтобы оценить вероятность H, что за время обновления N-W реплик поступит хотя бы одно требование на чтение и по нему будет прочитана запись из ее необновленных реплик (R=1).
Чтение из i-ой реплики будет несогласованным, если i. ai. Вариант, когда требование на чтение поступает в промежуток времени bi (см. N на рисунке 2.3) не приводит к рассогласованию чтения, т.к. эта операция будет выполнена после обновления записи. Получим: Н = P(3i: 4,- щ) = 1 - Р(3г: а = 1 - P(\/i at) (2.9) P(\/i t at) является вероятностью того, что не поступит ни одного требования на чтение из N-W реплик за время распространения обновления по сети. Пусть i(s) - преобразование Лапласа-Стилтьеса функции распределения вероятностей Fi(t) сетевой составляющей (гц) времени обновления і-ой реплики (выражение (2.24)). Тогда из (2.4) получим производящую функцию числа требований на чтение из і-ой реплики, поступивших за время аі: Qai(z) = Al(A(\-z)) (2.10) Вероятность того, что за сетевое время обновления і-ой реплики не поступит ни одного требования на чтение равно Qa. (z) = Л,-(Я). Т.к. требования на чтение из каждой реплики поступают независимо друг от друга, выражение (2.9) с учетом (2.10) можно переписать как:
Это и есть вероятность, что клиент прочитает устаревшую запись за время распространения обновлений записи по ее N-W репликам (для асинхронного режима).
Асинхронный режим обновления реплик поддерживает база данных NoSQL Amazon Dynamo, а также базы данных с типом репликации «master-slave» и «master-master».
При анализе строгой согласованности будем рассматривать синхронный режим распространения изменений. На рисунке 2.4 представлена модель согласования данных для этого случая [88, 91, 96, 98, 101]. Входящий поток требований на чтение из одной реплики так же принимается пуассоновским с параметром . NA NA
На рисунке 2.4 обновляемые реплики обозначаются 1, 2, …, W, буквой К обозначен координатор. (s) - преобразование Лапласа-Стилтьеса функции распределения вероятностей времени обновления і-ой. Требования на чтение поступают с суммарной интенсивностью N. Требования могут поступить как в процессе обновления W реплик, так и до начала обновления. Задача состоит в том, чтобы оценить характеристики случайного времени ожидания требованием на чтение окончания обновления W реплик.
Для решения поставленной задачи сначала предлагается получить производящую функцию Wq(z) числа тех требований на чтение из N реплик, которые поступят за время обновления W реплик. Из (2.4) следует, что требуемая ПФ числа требований на чтение из N реплик, поступивших за время обновления i-ой реплики, равна (ЩІ-z)). Т.к. требования на чтение из каждой реплики поступают независимо друг от друга, ПФ числа требований на чтение из N реплик, поступивших за время обновления W реплик, будет равна:
Вариант 2 модели - время обработки версий записи клиентом зависит от числа обновлений, выполненных ранее другими клиентами
Докажем (2.44). Среднее время копирования одной записи равно tx =[L/iDR +L(l/iN +l/iDW)](l-e-XTF1), (2-45) где L - длина записи (байт). Суммируя (2.45) по всем записям восстановленного узла (основные реплики записей узла, реплики других N-1 узлов) с учетом наличия неразделяемых и разделяемых ресурсов, получим (2.44). 2. Вариант отказа А2 (неисправность устраняется на месте или станция заменяется из ЗИП, но старые диски сохраняются). Если время устранения неисправности TF2 ТГР, имеет место способ В1 копирования записей на восстановленный узел: TC2=Tc(TF2) (см. (2.44)), иначе восстановление происходит согласно способу В2 (синхронизация реплик): ТС2 = VH/jDR + (VH + (N-1) VH)4iN + Тм + TC(TF2), (2.46) где VH - средний объем дерева Меркле на один виртуальный узел (v-узел); N - среднее число реплик на одну запись; (N-1)VH - объем деревьев Меркле на данном физическом узле от (N-1) узлов по кольцу против часовой стрелки; Тм -среднее время сравнения хешей деревьев Меркле в ОП узла; TC(TF2) - время чтения, передачи и сохранения новых обновлений записей, пришедших за время устранения неисправности. VH=LH(QH+Q + Q + ...+ Ц ) = LH(2QH-1), (2.47) где LH - длина поля хеша, байт; QH=Q/S - число записей базы данных в одном v-узле (секции), Q - число записей (документов), хранимых во всей базе данных (основные реплики записей); S - число v-узлов (в скобках в (2.47) указано число узлов дерева Меркле на каждом уровне). TM = (2QH-l + (N-l)(2QH-l))-(3/ip) = N(2QH-l)-(3/ip)- (2.48) сравниваются пары значений хешей на всех уровнях дерева (2QH-1) для каждого v-узла физического узла, включая секции реплик других узлов (N-1); 3 -учитывает сравнение пары хешей и перемещение к следующей паре; Р - число циклов, выполняемых процессором (1/с). 3. Вариант отказа A3 (станция заменяется из ЗИП с новыми дисками). Время устранения неисправности - TF3. Восстанавливаются все реплики путем их копирования из других узлов. TC3=V/iDR+(V+(N-l)-y)(l/iN+l/iDW) (2.49) Процесс получения формулы (2.49) аналогичен (2.44), но восстанавливаются все записи узла.
Эти результаты анализа опубликованы в [94]. Перед проведением модельных экспериментов необходимо оценить вероятности Рь Р2, Р3 (случайный сбой, выход из строя системного блока, повреждены диски) при условии, что сервер отказал. В [61] приводится сравнение кластера и «обычного» сервера. В этой работе описан расчет вероятности отказа сервера за год, которая складывается из вероятностей отказа комплектующих. На основе этих данных можно сделать вывод, что вероятность Р2 превышает вероятность Р3 примерно на порядок, т.к. часто выходят из строя блоки питания, элементы охлаждения и т.д. Но аппаратное обеспечение выходит из строя гораздо реже, чем программное, поэтому положим Pi=5(P2+P3), Р2=10Р3. Т.к. Рі+Р2+Р3=1, определим вероятности следующим образом: Рі=0.835, Р2=0.15, Р3=0.015.
В [61] вероятность отказа PPh сервера за период t=12 месяцев составляет 0.457. Т.к. вероятность Р безотказной работы за период t рассчитывается по формуле P=exp(-t), где - интенсивность отказа, то имеем ph=-ln(l-0.457)/12=0.05 - интенсивность отказа физических компонентов узла. Вероятность отказа программного обеспечения (операционной системы), согласно предположениям, в пять раз превышает вероятность отказа комплектующих, поэтому примем интенсивность отказа узла =(5+l)Ph=0.3. Получаем среднее время наработки на отказ 1/ = 3.33 месяца. Для расчетов примем 1/=3 мес (90 дней). В расчетах по умолчанию были использованы следующие исходные данные: U= 3000 – число узлов кластера; N= 3 – число реплик записи БД; K= 2 – число ремонтных бригад; V= 1 Гбайт – объем основных реплик записей одного узла; S = 8192 – число виртуальных узлов (в каждом узле располагаются S/U виртуальных узлов); Q= 1 млрд – число записей БД; = 0.1 (1/с) – интенсивность обновления какой-либо записи БД; TF1= 600 с – время устранения неисправности по варианту отказа A1, т.е. время перезапуска операционной системы (см. раздел 2.4.3); TF2= 4 часа – время устранения неисправности по варианту отказа A2, т.е. время устранения неисправности на месте или восстановления узла из ЗИП, но со старыми дисками; согласно документации Cassandra, временные реплики хранятся 3 часа, примем это значение за TГР, тогда TF2 TГР и имеет место B2 способ автоматического восстановления данных узла; TF3= 5 часов – время устранения неисправности по варианту отказа A3, т.е. станция заменяется из ЗИП с новыми дисками и восстанавливается программное обеспечение; LH – размер хеша в деревьях Меркле – 25 байт.
Значения интенсивностей обработки данных в устройствах: N= 12.5106 байт/с – интенсивность передачи данных по сети; P = 2 млрд операций в секунду – производительность процессора; DR= 80 Мбайт/с – интенсивность чтения байтов с диска; DW= 30 Мбайт/с – интенсивность вывода байтов на диск.
Результаты модельных экспериментов представлены на рисунках 2.19 -2.23. При построении графиков для вероятности P0 отказа в доступе к записи принят логарифмический масштаб. На графиках «расчет» обозначает зависимости, построенные по формуле (2.41), «имит» – зависимости, полученные по результатам имитационного моделирования.
Проведение экспериментов и оценка адекватности модели (1)
Указанные группы факторов необходимо анализировать в совокупности друг с другом, что позволяет выявлять причины заболевания, специфику его распространения, возможности дальнейшего распространения заболеваний и т.д. Если для хорошо известных заболеваний уже сформирован ряд критериев, позволяющих отслеживать их активность, то для новых заболеваний, появляющихся в результате мутаций или передачи от животных к человеку, выявление факторов, влияющих на распространение и активность заболевания, является критически важной задачей. 1. Транзакционный модуль – узел, занимающийся сбором, обработкой и последующей передачей данных на аналитический модуль. Данный элемент системы может работать на основе любой надежной реляционной СУБД, поддерживающей ACID транзакции. 2. Аналитический модуль – набор (кластер) узлов, занимающихся аналитической обработкой данных. Это один из основных компонентов системы. Он позволяет представлять собранные данные в виде различного рода отчетов, строить разнообразные диаграммы и отображать информацию в привязке к географическим координатам на карте. Данный элемент системы позволяет параллельно обрабатывать аналитические запросы и выдавать отчеты различного уровня сложности.
В штатном режиме работы системы число запросов, поступающих к аналитическому модулю невысоко, с нагрузкой вполне может справится один узел. Однако во время эпидемии нагрузка на систему может значительно возрасти. Например, при вспышке заболевания, связанного с вирусом «Ебола» [73] в Западной Африке, число заболеваний за 4 месяца выросло в 100 раз [74].
При вспышке подобных заболеваний [75-77] многие аналитики во всех странах будут заинтересованы получать актуальные аналитические отчеты о скорости распространения вируса, числе заболевших и т.д. В дальнейшем рассматривается аналитический модуль системы «Надзор за заболеваемостью – NoSQL».
До недавнего времени доступ к базе данных чаще всего осуществлялся с использованием классической реляционной системы управления базами данных (РСУБД). В настоящее время львиная доля информации хранится в РСУБД. Это объясняется внешней простотой реляционной модели, наличием такого мощного и в то же время простого для изучения языка доступа к данным, как SQL, а также наличием оптимизаторов выполнения транзакций и запросов к базе данных, обеспечивающих их «дробление» на более мелкие задания и параллельную реализацию этих работ на многопроцессорных или многомашинных комплексах.
Рассмотрим основные проблемы организации данных, которые могут возникнуть при использовании реляционной базы данных в процессе реализации аналитического модуля:
1. Проблема потери соответствия и низкой производительности. Как отмечалось в Глава 1, она проявляется в том, что реляционные базы данных не позволяют хранить агрегаты. Например, чтобы отобразить информацию о пациенте, месте пребывания, месте проживания, госпитализации и т.д., программист должен собрать в оперативной памяти данные из многих таблиц. При значительном росте числа таблиц разработчик часто просто забывает назначение той или иной таблицы, осложняется связывание таблиц при выполнении запроса, т.е. существенно осложняется формирование агрегата. Операции соединения многих таблиц выполняются сравнительно медленно. Теоретически возможен вариант использования одной плоской таблицы. Но в таком случае таблица не будет находиться в третьей нормальной форме и будет обладать недостатками, такими как избыточность, потенциальная противоречивость и т.д. При этом объем базы данных может возрасти на порядок.
2. Проблема сегментации данных. Как отмечалось в Глава 1, с увеличением объема хранимых данных возникает задача фрагментации таблиц базы данных по разным серверам, объединенных в кластер. Но параллельные системы реляционных баз данных демонстрируют невысокую масштабируемость [5]. При выполнении сложных запросов производительность системы существенно уменьшается в результате межмашинного обмена данными между серверами кластера [6].
3. Проблема обеспечения отказоустойчивости. Как отмечалось в Глава 1, в параллельных системах баз данных число реплик невелико, что не может гарантировать высокую отказоустойчивость. Более того, при отказе какого-либо узла необходимо перезапускать всю систему целиком.
Базы данных NoSQL не имеют указанных недостатков (см. пункт 1.2.2), поэтому в данном проекте целесообразно использовать базу данных этого типа.
В настоящее время под понятие «база данных NoSQL» попадает очень широкий спектр систем хранения и обработки данных [78]: хранилища «ключ-значение» (Riak, Redis, DynamoDB, Project Voldemort), хранилища семейств столбцов (HBase, Apache Cassandra, HyperTable), документо-ориентированные (CouchDB, MongoDB, eXist), базы данных на основе графов (Neo4j, OrientDB, InfiniteGraph). Среди всего множества систем NoSQL в проекте были рассмотрены следующие базы данных: MongoDB, Apache Cassandra и Riak. Базы данных на основе графов не рассматривались, т.к. они не являются распределенными (реплицируется весь граф).
База данных MongoDB, реализованная на C++, обладает достаточно богатой функциональностью и является одной из самых популярных систем NoSQL на данный момент [79]. MongoDB позволяет оперировать JSON-документами, которые объединяются в коллекции. Каждый документ в коллекции должен содержать уникальный идентификатор (сгенерированный автоматически или пользователем), который не может изменяться после создания документа. Кроме идентификатора документ может содержать произвольный набор полей, включая массивы и вложенные документы. Система поддерживает работу со слабоструктурированными данными: документы в одной коллекции могут содержать разные наборы полей. Масштабируемость в MongoDB достигается за счет «сегментирования», т.е. распределения документов коллекции по узлам на основе выбранного ключа (shard key). Также поддерживается репликация в режиме «главный-подчиненный»: операции записи обрабатываются только главным узлом, а операции чтения могут выполняться на главном узле или на подчиненных узлах (рисунок 5.2).