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

Riak поддерживает вторичные индексы и технологию MapReduceдля реализации более сложных запросов. Функциональность Riak делает этусистему близкой к документным базам данных NoSQL. Подсистема храненияданных в Riak является подключаемым модулем, что позволяет использоватьразличные системы хранения для разных задач. Согласно [81] Riak используется вдостаточно большом количестве проектов.Исследуемый аналитический модуль должен обеспечивать горизонтальнуюмасштабируемость, отказоустойчивость, допускать конкурентное обновлениезаписи.

Также требуется обеспечивать разные уровни согласованности для разныхсегментов данных. Исходя из перечисленных требований, дальнейший проектаналитического модуля рассматривается для базы данных NoSQL Riak.5.4. Построение структуры хранилища данных аналитического модуляДля анализа рассмотрим два сегмента: Human Case (содержит информациюо случаях заболевания людей) и Human Case Sample (содержит информацию обобразцах, взятых у пациентов).В таблице 5.2 приводятся спецификации основных свойств JSONдокументов (поле «значение» записи) агрегатов исследуемого хранилища всистеме Riak.136Таблица 5.2 – Спецификации агрегатов.ПолеТип поляКомментарийСегмент «Human Case»Age_GroupStringВозрастная группа пациентаAntibiotic_Date_First_AdministratedDateДата назначения антибиотикаAntibiotic_DoseStringДоза антибиотикаAntibiotic_NameStringНазвание антибиотикаContact_Date_of_Last_ContactDateДата последнего контактаContact_InformationStringИнформация о последнем контактеContact_NameStringИмя контактировавшего лицаContact_Place_of_Last_ContactStringМесто последнего контактаContact_RelationStringТип контактаDiagnosis_History_Change_Date/TimeДатаизмененияисторииDateдиагностикиDiagnosis_History_Changed_DiagnosisStringНовый диагнозDiagnosis_History_Changed_Diagnosis_Is_ZStringЯвляется ли диагноз зоонознымoonoticDiagnosis_History_OrganizationStringОрганизация, изменившая диагнозDiagnosis_History_PersonStringСотрудник, изменивший диагнозDiagnosis_History_Previous_DiagnosisStringПредыдущий диагнозDiagnosis_History_Previous_Diagnosis_Is_ZЯвляется ли предыдущий диагнозStringoonoticзоонознымDiagnosis_History_Reason_for_Changed_DiStringПричина изменения диагнозаagnosisAgeIntegerВозраст пациентаAge_TypeStringТип возрастаAntibiotics_AdministratedStringНазначен ли антибиотикBasis_of_Diagnosis_ClinicalStringКлинический диагнозBasis_of_Diagnosis_Epidemiological_LinksStringЭпидемиологический диагнозBasis_of_Diagnosis_Laboratory_TestStringЛабораторные тестыCase_ClassificationStringКлассификация заболеванияCase_IDStringИдентификатор заболеванияCase_StatusStringСтатус заболеванияChanged_DiagnosisStringИзмененный диагнозChanged_Diagnosis_Is_ZoonoticЯвляется ли измененный диагнозStringзоонознымChanged_Diagnosis_CodeStringКод измененного диагнозаDate_EnteredДатарегистрациизаписиоDateпациентеDate_Last_SavedDateДата последней модификацииDate_of_BirthDateДата рожденияDate_Of_Changed_DiagnosisDateДата изменения диагнозаDate_of_Completion_of_Paper_formDateДата составления заключенияDate_of_DeathDateДата смертиDate_of_DischargeDateДата выпискиDate_of_ExposureDateДата осмотра137Продолжение таблицы 5.2ПолеDate_of_Final_Case_ClassificationDate_of_Final_DiagnosisDate_of_HospitalizationDate_of_Last_Patient_Presence_at_WorkDate_of_Symptom_OnsetDate_Patient_First_Sought_CareDays_after_First_Sought_Care_until_NotificationDays_after_Initial_Diagnosis_until_Final_DiagnosisТип поляDateDateDateDateDateDateIntegerIntegerDays_after_Initial_Diagnosis_until_NotificationIntegerDays_after_Notification_until_Entered_in_the_systemIntegerDays_after_Notification_until_Case_InvestigationIntegerDays_after_Onset_of_Patient_Symptoms_until_NotificationIntegerDays_after_Patient_First_Sought_Care_until_EnteredIntegerDays_after_Patient_First_Sought_Care_until_Final_DiagnosisIntegerDays_after_Symptom_Onset_until_First_Sought_CareIntegerDiagnoses_GroupDiagnosisDiagnosis_Is_ZoonoticDiagnosis_CodeDiagnosis_DateEmployer_NameEmployer_Phone_NumberEntered_by_OfficerEntered_by_Organization_IDEntered_by_Organization_NameEpidemiologist_NameStringStringStringStringDateStringStringStringStringStringStringКомментарийДатаокончательнойклассификации заболеванияДата окончательного диагнозаДата госпитализацииДата последнего рабочего дняДата начала симптомовДата обращения за помощьюКоличество дней после первогообращения до оповещенияКоличестводнейотпервоначальногодоокончательного диагнозаКоличестводнейотпервоначальногодиагнозадооповещенияКоличестводнейпослеоповещения до регистрации всистемеКоличестводнейпослеоповещениядоисследованиязаболеванияКоличество днейпосле началапроявлениясимптомовдооповещенияКоличество дней от первогообращениязапомощьюдорегистрацииКоличество дней от первогообращениязапомощьюдоокончательного диагнозаКоличество дней после началапроявлениясимптомовдообращения за помощьюГруппа диагнозаДиагнозЯвляется ли диагноз зоонознымКод диагнозаДата диагнозаИмя работодателяТелефон работодателяИмядолжностноголица,вводившего записьИдентификаторорганизации,вводившей записьНаименованиеорганизации,вводившей записьИмя эпидемиолога138Продолжение таблицы 5.2ПолеFacility_Where_Patient_First_Sought_Care_IDТип поляКомментарийИдентификатор организации, вStringкоторую пациент обратился запомощьюFacility_Where_Patient_First_Sought_Care_Наименование организации, вNameStringкоторую пациент обратился запомощьюFinal_Case_ClassificationИтоговаяклассификацияStringзаболеванияFinal_DiagnosisStringИтоговый диагнозFinal_Diagnosis_Is_ZoonoticЯвляется ли итоговый диагнозStringзоонознымFinal_Diagnosis_CodeStringКод итогового диагнозаСегмент «Human Case Sample»Accession_DateDateДата доступаCase_IDStringИдентификатор случаяCollected_By_InstitutionStringУчреждение, взявшее образецCollected_By_OfficerStringСотрудник, взявший образецCollection_DateDateДата сбораCommentStringКомментарийCondition_ReceivedStringПолученное состояниеCurrent_LaboratoryStringТекущая лабораторияDays_after_First_Sought_Care_until_SampleКоличество дней от обращения заInteger_Collectionпомощью до сбора образцаDays_after_Notification_until_Sample_ColleКоличество дней от оповещения доIntegerctionсбора образцаDays_in_TransitКоличество дней, затраченных наIntegerтранспортировкуDays_until_Sample_Accessioned_Since_SentКоличество дней с моментаInteger_Dateотправки до доступа к образцуDays_until_Sample_Sent_Since_CollectionКоличество дней с момента сбораIntegerматериала до отправкиDestruction_MethodStringМетод уничтоженияDiagnosisStringДиагнозDiagnosis_Is_ZoonoticStringЯвляется ли диагноз зоонознымFunctional_AreaStringФункциональная областьInitially_Collected_Sample_Accession_DateДата доступа к первичномуDateобразцуInitially_Collected_Sample_Collected_By_InОрганизация, выполнившая сборStringstitutionпервичного образцаInitially_Collected_Sample_Collection_DateDateДата сбора первичного образцаInitially_Collected_Sample_Current_LaboratТекущая лаборатория первичногоStringoryобразцаInitially_Collected_Sample_Lab_IDStringИдентификатор лабораторииInitially_Collected_Sample_Local_IDЛокальныйидентификаторStringпервичного образцаInitially_Collected_Sample_Sent_to_OrganizОрганизация, в которую былStringationотправлен первичный образец139Продолжение таблицы 5.2Initially_Collected_Sample_StatusInitially_Collected_Sample_TypeLab_Sample_IDLocal_Sample_IDSample_TypeSent_DateSent_to_OrganizationStringStringStringStringStringDateStatusStringStringСтатус первичного образцаТип первичного образцаИдентификатор лабораторииЛокальный идентификатор образцаТип образцаДата отправкиОрганизация, в которую былотправлен образецСтатусВ разделе 5.2 были описаны проблемы, которые могут возникнуть в проектепри использовании реляционной базы данных.

Далее показано, как решаются этипроблемы, используя базу данных Riak.Исходя из строения сегмента «Human Case», можно сделать вывод, что дляполучения необходимой информации о случае заболевания следует выполнитьчтение только одной записи из базы данных по ключу. Данные не требуетсячитать из нескольких таблиц и соединять их (они хранятся в виде одногоагрегата), следовательно, решается проблема потери соответствия (проблема 1).База данных Riak автоматически распределяет записи по большому числу узлов,используя консистентное хеширование. Межмашинный обмен данными нетребуется при доступе к указанным сегментам (решается проблема 2). Базаданных Riak хранит N реплик каждой записи на разных серверах, содержитвстроенныемеханизмы(восстановлениеперераспределениявозможностичтения),репликобновленияприотказахустаревшихузловреплик,восстановленных после сбоя.

Таким образом решается проблема обеспечениявысокой отказоустойчивости (проблема 3). Но при использовании Riak остаетсязадача выбора параметров репликации для сегментов, исходя из требований кпроизводительности, согласованности и отказоустойчивости. Выбор может бытьосуществлен с использованием аналитических и имитационных моделей,разработанных в Глава 2, и инструментального средства, разработанного в Глава4.1405.5. Оценка показателей производительности, согласования реплик иотказа в доступе к записи базы данныхВ этом разделе оцениваются следующие показатели функционированияаналитического модуля: 1) среднее время ожидания требованием на чтениеокончания обновления W реплик для режима строгого согласования реплик; 2)вероятность того, чтоклиент прочитает устаревшую запись за времяраспространения обновлений записи по ее N-W репликам для режимасогласования реплик в конечном счете; 3) вероятность отказа в доступе к записиБД.Былиопределенытребованиякрежимамсогласованиярепликаналитического модуля системы «Надзор за заболеваемостью - NoSQL»: сегментHuman Case – согласованность в конечном счете, сегмент Human Case Sample –строгая согласованность.Заказчикустановилразмеркластерав15узлов(минимальныйрекомендуемый размер кластера Riak – 5 узлов [82]).