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

Добавление / удаление узлов(серверов)выполняетсявRiakоднойкомандой,приэтомданныеперераспределяются между всеми узлами автоматически в фоновом режиме. Этосущественно упрощает процесс изменения размера системы. Виртуальные узлыимеютодинаковуюпроизводительность.Согласно[83]рекомендуетсянастраивать число виртуальных узлов в кольце так, чтобы на каждом узлехранилось минимум 10 разделов (виртуальных узлов).

Поэтому установим размеркольца, равным 256.Для анализа были использованы следующие значения характеристикаппаратных ресурсов: интенсивность чтения данных из оперативной памяти – 8000 МБайт/с; производительность процессора – 2000 млн операций в с.В период эпидемии сеть передачи данных и дисковые массивы могут бытьсильно перегружены, поэтому были использованы следующие параметры: интенсивность передачи данных внутри сети ЦОД – 1 Гбит/с(стандартная скорость ЦОД);141 загрузка сети передачи данных в ЦОД – 0.6; интенсивность дискового ввода/вывода – 40 Мбайт/с; количество ремонтных бригад кластера – 1; время наработки на отказ одного узла– 90 дней; при отказе узла: вероятность случайного сбоя операционной системы –P1=0.835, вероятность сбоя аппаратного обеспечения – P2=0.15,вероятность отказа дисков – 0.015; время перезапуска операционной системы – 10 мин; время восстановления аппаратного обеспечения узла – 4 ч; время восстановления дисков – 5 ч;Пусть система работает на территории с населением в 42,8 млн человек(население Украины на 01.12.2015 [84])на протяжении 5 лет.

Еслипредположить, что человек в среднем болеет один раз в 5 лет каким-либозаболеванием, регистрируемым в системе, то среднее число записей можнооценить как (42.8млн/5)∙5∙3=128.4 млн (3 означает, что одна запись сохраняется всегменте «Human Case» и две записи – в сегменте «Human Case Sample»).Согласно[85, 86]имеется476районов,165городовобластногоиреспубликанского подчинения, имеем 476+165=641 точек входа в систему.Среднюю интенсивность обновления какой-либо записи можно установить в0.0012 1/с (1 раз в 13.5 минут).

Средний размер агрегата определим следующимобразом: сегмент «Human Case» – 6000 байтов, «Human Case Sample» – 2125байтов. Эти значения были получены из полного описания спецификацийрассматриваемых сегментов. Тогда средний размер записи примерно равен 3417байтов ((6000+2·2125)/3). На одном узле хранится 128.4 млн /15 = 8.56 млнзаписей, средний объем записей на одном узле - 8.56 млн ∙ 3417 байтов= 27.25Гбайт.Рассмотрим проблемы согласованности, которые могут возникнуть приработе с системой:1421.

Может возникать задержка чтения записей из сегмента «Human CaseSample», т.к. в период эпидемий интенсивность чтения и обновленияданных сегмента высока.2. При высокой интенсивности чтения данных из сегмента «Human Case»пользователям может быть возвращена неактуальная информация(устаревшие записи), т.к. данный сегмент согласован в конечном счете.Исследование показателей согласованности и отказоустойчивости быловыполнено с помощью инструментального средства, разработанного в Глава 4.На рисунке 5.3 показаны зависимости среднего времени ожидания (T)требованием на чтение окончания обновления W репликв зависимости отинтенсивности поступления требований на чтение записей из сегмента «HumanCase Sample» к одной реплике (λ).

W=R=N/2+1, если N четное, и W=R=(N+1)/2,если N нечетное.Рисунок 5.3 – Зависимости среднего времени ожидания T (мс) от интенсивностипоступления требований на чтение λ (1/с) при различных значениях числа репликзаписи N.На рисунке 5.4 приведены зависимости вероятности P того, что клиентпрочитает устаревшую запись за время распространения обновлений записи по ееN-W репликам сегмента «Human Case» (W=R=1).143Из рисунка 5.3 видно, что даже при больших значениях интенсивностипоступления требований на чтение λ время ожидания не превышает 3 мс. Однакопри выполнении аналитических запросов это время может возрасти.

Из рисунка5.4 видно, что при N=7 вероятность P не превышает величины 0,13 даже прибольших λ.На рисунке 5.5 приведена зависимость вероятности P0 того, что привыполнении операции чтения произойдет отказ в доступе к записи базы данныхNoSQL (пользователь не получит ответа), от числа реплик записи (N).Рисунок 5.4 – Зависимость вероятности P от интенсивности поступлениятребований на чтение к одному узлу кластера λ (1/с) при различных значенияхчисла реплик записи N.144Рисунок 5.5 – Зависимость вероятности отказа P0 от числа реплик записи N.Из рисунка 5.5 видно, что при увеличении числа реплик записи вероятностьотказа P0 уменьшается по показательному закону: при увеличении числа репликтолько на 1 вероятность уменьшается примерно на 2 порядка.5.6.

Выбор параметров репликации сегментов хранилищаВыбор параметров репликации сегментов хранилища NoSQL был выполненна основании требований, предъявляемых к задержке чтения, согласованности иотказоустойчивости. Заказчик системы установил следующие требования:1. Задержка чтения (время ожидания требованием на чтение окончанияобновления W реплик) – не более 2 мс (это важно, если при выполнениизапроса читается большое число записей).2. Вероятность доступа к рассогласованным данным (вероятность того, чтоклиентпрочитаетустаревшуюзаписьзавремяраспространенияобновлений записи по ее N-W репликам) – не более 0.1.3. Вероятность отказа в доступе к записи БД (вероятность того, что на запроспользователя не будет возвращено значение) – не более 10-12.145Из рисунка 5.4 видно, что для числа реплик N=3…6 вероятность чтенияустаревшей записи не превышает 0.1 при максимальном λ, что удовлетворяеттребованию 2.

Однако из рисунка 5.3 следует, что при N=6 задержка чтенияпревышает 2 мс при максимальном λ, это приводит к нарушению требования 1.Из рисунка 5.5 видно, что вероятность отказа в доступе к какой-либо записи приN=5…7 не превышает 10-12, что удовлетворяет требованию 3. Таким образом,число реплик N записей сегментов «Human Case» и «Human Case Sample»примем равным 5.

Параметры W и R для строгого согласования записей сегмента«Human Case Sample» установим равными W=R=(N+1)/2=3. Параметры W и Rдля согласования в конечном счете записей сегмента «Human Case» установимравными W=R=1.Выводы по 5-й главе1.Проанализированымодулипроектируемойсистемы«Надзорзазаболеваемостью - NoSQL».2. Приведено обоснование выбора технологии NoSQL для реализациианалитического модуля системы.3.ПроанализированывариантыбазданныхNoSQL,рассмотреныследующие системы: MongoDB, Cassandra, Riak. Анализ показал, что длявыбраннойпредметнойобластибазаданныхRiakявляетсяболеепредпочтительной.4. Приведены спецификации основных свойств JSON-документов длясегментов «Human Case» и «Human Case Sample» проектируемой системы.5.

Подготовлены исходные данные длямоделирования. Полученызависимости среднего времени ожидания чтения записи из БД, вероятностичтения устаревшей записи, вероятности отказа в доступе к записи БДотинтенсивности поступления требований на чтение.6. В соответствии с предъявленными требованиями к системе в периодпиковой нагрузки (среднее время ожидания чтения записи – не более 2 мс,вероятность чтения устаревшей записи – не более 0.1, вероятность отказа в146доступе к записи – не более 10-12) были выбраны параметры репликации базыданных Riak: N=5, W=R=3 - для сегмента «Human Case Sample» (строгоесогласование реплик), N=5, W=R=1 - для сегмента «Human Case» (согласованиереплик в конечном счете).147ЗаключениеВкачествеосновныхрезультатовработыопределеныследующиеположения:1.

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

Разработанамодифицированнаямодель«ремонтника»,позволяющаяоценить влияние числа реплик записи базы данных и режимов ихвосстановления на вероятность отказа в доступе к этой записи.5. Для доказательства адекватности разработанных моделей согласованиярепликимоделиведенияверсийзаписивыполненынатурныеэксперименты в облачной среде DigitalOcean на кластере размером до 24виртуальных узлов с использованием базы данных NoSQL Riak. Средняяотносительная погрешность модели согласования реплик в конечном счетесоставила 7.86%, модели строгого согласования реплик – 7.42%, моделиведения версий записи – 4%.6.

Разработано инструментальное средство анализа баз данных NoSQL,позволяющееоценивать показатели согласованности реплик, веденияверсий записи, отказов и восстановления доступа к записи БД на этапепроектирования информационной системы.7. Выполненосистемыисследование«Надзорзааналитическогозаболеваемостью-модуляNoSQL»информационнойнастадииее148проектирования в режиме экстремальной нагрузки. Выбраны параметрырепликации записей: N=5, W=R=3 - для строго согласованных сегментов иN=5, W=R=1 - для сегментов, согласованных в конечном счете.