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

SetProgress – функция, принимающая числовой аргумент – номертекущего прогона модели. Она устанавливает прогресс согласно номерутекущего прогона (см. стрелку «Отобразить текущий прогон» на рисунке4.4).1214. SetFinishVersions – функция без параметров, сообщает системе, чтомоделированиезавершеноинеобходимоотобразитьрезультатымоделирования (см. стрелку «Закончить моделирование» на рисунке 4.4).Для упрощения программы PLUS основной модуль передает не массивкоэффициентовk,амассиврассчитанныхсреднихзначенийвремениобдумывания клиентом результатов работы с версиями записи.Алгоритм работы программы на языке PLUS.Вход: массив числа клиентов NKL_ARR, размер массива числа клиентовNKL_ARR_SIZE, массив времени обдумывания LBMD_ARR, размер массивавремениобдумыванияLMBD_ARR_SIZE,имяфайласрезультатамиFILE_NAME, время одного прогона модели ITER_TIME.Алгоритм:STOP = 0 //флаг остановки моделирования пользователемCALL(SetResultFileName, FILE_NAME)CALL(SetTotalProgress, NKL_ARR_SIZE * LMBD_ARR_SIZE)ЦИКЛ по количеству элементов массива i = 0..NKL_ARR_SIZE-1ЦИКЛ по количеству элементов массива j = 0..LBMD_ARR_SIZE-1ЗАПУСТИТЬ модель на время ITER_TIME с параметрамиNKL_ARR[i], LMBD_ARR[j].ЗАПИСАТЬ результаты моделирования в файл FILE_NAMESTOP = CALL(SetProgress, i * j)ЕСЛИ (STOP == 1) ТО КОНЕЦ АЛГОРИТМАКОНЕЦ ЦИКЛАКОНЕЦ ЦИКЛАCALL(SetFinishVersions)КОНЕЦ АЛГОРИТМАНа рисунке 4.5 представлен пример окна с результатами моделирования,полученных с помощью инструментального средства.

Моделирование быловыполнено при входных данных, изображенных на рисунке 4.3.122Рисунок 4.5 – Пример результатов моделирования процесса ведения версийзаписи.4.3. Подсистема для работы с моделями отказов и восстановлениядоступа к записиНа третьей вкладке программы (см. рисунок 4.6) доступна работа смоделями отказов и восстановления доступа к записи в базах данных NoSQL.При помощи инструментального средства можно получить оценкувероятности отказа в доступе к какой-либо записи базы данных NoSQLаналитическим (выражение (2.41)) и /или имитационным методом.Для моделей отказов можно задавать несколько значений для одногопроцесса моделирования для следующих входных параметров: размер кластера(число узлов), количество ремонтных бригад, число реплик и время наработки наотказ узла (через точку с запятой).Окно программы (третья вкладка) содержит элементы управления длянастройки исходных данных (они одинаковы как для аналитической, так и дляимитационной модели), кнопку для расчета вероятности по аналитическоймодели и кнопку запуска имитационной модели.

Имитационное моделирование123выполняется в среде GPSS посредством проведения эксперимента на языке PLUS.Текст программы на PLUS и модели на GPSS генерируется инструментальнымсредством автоматически после ввода исходных данных.Схема работы инструментального средства с имитационной модельюотказов практически совпадает с имитационной моделью ведения версий записи(см. рисунок 4.4). Отличие заключаетсяSetFinishVersions(стрелка«Закончитьв том, чтомоделирование»вместонафункциирисунке4.4)используется функция SetFinishReliability библиотеки NoSQLGPSSLib.dll, котораясообщает системе, что моделирование завершено и необходимо осуществитьвозврат в главное окно программы.

После этого таблица с результатамианалитическихрасчетовдополняетсярезультатамиимитационногомоделирования.Алгоритм работы программы на языке PLUS.Вход: массив изменяемых параметров ARR, размер массива изменяемыхпараметров ARR_SIZE, имя файла с результатами FILE_NAME, время одногопрогона модели ITER_TIME.Алгоритм:STOP = 0 //флаг остановки моделирования пользователемCALL(SetResultFileName, FILE_NAME)CALL(SetTotalProgress, ARR_SIZE)ЦИКЛ по количеству элементов массива i = 0..ARR_SIZE -1ЗАПУСТИТЬ модель на время ITER_TIME с параметром ARR[i].ЗАПИСАТЬ результаты моделирования в файл FILE_NAMESTOP = CALL(SetProgress, i)ЕСЛИ (STOP == 1) ТО КОНЕЦ АЛГОРИТМАКОНЕЦ ЦИКЛАCALL(SetFinishReliability)ЗАКРЫТЬ GPSSКОНЕЦ АЛГОРИТМАНа рисунке 4.6 представлен пример окна с результатами аналитического иимитационного моделирования, полученных с помощью инструментальногосредства.124Рисунок 4.6 – Пример результатов моделирования отказа в доступе к какой-либозаписи базы данных NoSQL.Выводы по 4-й главе1.Представленыструктураиосновныеособенностиразработкиинструментального средства анализа показателей согласования реплик в базахданных NoSQL.2.

Подсистема для работы с моделями согласования реплик позволяетоценивать вероятность чтения устаревшей записи (для случая согласованияреплик в конечном счете) а также характеристики случайного времени ожиданиятребованием на чтение окончания обновления W реплик и времени чтения Rреплик с учетом этого ожидания (для случая строгого согласования реплик) дляразличных исходных данных.1253. Подсистема для работы с моделью ведения версий записи (варианты 1, 2)позволяет получать оценки характеристик случайного числа версий записи,одновременно хранящихся в базе данных, и времени их обработки клиентом.Инструментальное средство автоматически генерирует программу на языке PLUS,обеспечившую автоматическую смену итераций моделирования и заменуисходных данных в модели на GPSS.4. Подсистема для работы с моделью отказов и восстановления доступа ккакой-либо записи базы данных NoSQL позволяет получать оценки вероятностиотказа в доступе к записи БД по результатам аналитического и имитационногомоделирования.126Глава 5.

Использование разработанных моделей иинструментального средства на этапе проектированияинформационной системыРазработанные модели и инструментальное средство были использованыпри проектировании информационной системы (ИС) «Надзор за заболеваемостью– NoSQL», которая должна обеспечивать хранение и обработку большого массиваданных о заболеваниях, пациентах, результатах лабораторных анализов и т.д.Задачей исследования был выбор параметров репликации (N, W, R)распределенной базы данных NoSQL с учетом специфики предметной области итребований заказчика к показателям производительности, согласованности иотказоустойчивости.В процессе решения поставленной задачи были реализованы следующиеэтапы:1.

Описание предметной области.2. Обоснование отказа от реляционной модели данных в пользу технологииNoSQL.3. Определение доступных вариантов NoSQL систем, которые могут бытьиспользованы для реализации исследуемой информационной системы.4. Построение структуры хранилища информационной системы (описаниеагрегатов).5. Оценкапоказателейотказоустойчивостипроизводительности,информационнойсогласованностисистемынаэтапеиеепроектирования с использованием моделей, разработанных в Глава 2, иинструментального средства анализа баз данных NoSQL, разработанногов Глава 4.6.

Выбор параметров репликации на основании требований, предъявляемыхк производительности, согласованности и отказоустойчивости ИС, сучетом выполненных оценок.1275.1. Описание предметной областиПроектируемаясистема“Надзорзазаболеваемостью-NoSQL”предназначена для сбора, передачи, хранения и анализа информации озаболеваниях человека и животных, а также связанных с ними данных обобразцах и лабораторных тестах. Она позволяет обрабатывать информацию озаболеваниях человека (медицинский модуль системы), заболеваниях животных(ветеринарный модуль системы) и связанных с ними лабораторных исследований(лабораторный модуль). Одной из отличительных особенностей системы являетсяинтеграция эпидемиологического и ветеринарного компонентов между собой, атакже интеграция каждого из этих компонентов с лабораторными данными.Медицинский модуль предназначен для сбора информации как обиндивидуальных случаях заболевания (обычно это особо опасные заболевания,требующие немедленного извещения, такие как сибирская язва, чума и т.п.), так ио групповых случаях заболевания (обычно это менее опасные заболевания,требующие регулярных извещений, например, в виде месячных отчетов).Информацияобиндивидуальномслучаезаболеваниявключаетдемографические данные о человеке, данные об экстренном извещение, диагнозы(предварительный, клинический, окончательный), клинические признаки, данныеэпидемиологическогорасследования,данныеоконтактахчеловека,еговакцинации, данные о собранных образцах и результатах их исследований,интерпретация этих данных.Групповой случай описывается административной единицей (например,район), временным интервалом (например, месяц), списком заболеваний и рядомколичественных параметров (например, количество заболевших младше 1 годаили количество заболевших беременных женщин).Ветеринарный модуль содержит информацию о хозяйстве, в которомобнаружено заболевание, описание структуры такого хозяйства и особенностейего функционирования (например, тип выпаса скота, система кормления скота ит.п.), описание структуры стада или стаи, с указанием типов животных (в случаекрупного рогатого скота с указанием конкретных животных), информацию о128клинических признаках у вида животных или конкретных особей, информацию овакцинации животных, данные о собранных образцах для анализа, результатыанализов и их интерпретацию.Лабораторный модуль содержит информацию об образцах, поступивших наисследование в лабораторию, о назначенных тестах и их результатах, о культурах,полученных из образцов, о проведении высевания и размножения культур, орезультатах тестов над хранящимися образцами, информацию о связи образцов сослучаями заболевания, информацию о различного рода ежедневных операциях влабораториях (например, разделение образцов, уничтожение образцов, передачана дополнительные исследования в другое учреждение).Лабораторный модуль позволяет сотрудникам лаборатории получитьдоступ к информации о случае заболевания человека или животного, повышаятем самым вероятность верной интерпретации проведенных анализов образцов.

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

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