|
5.5.
Оценка показателей производительности, согласования реплик и
отказа в доступе к записи базы данных
В этом разделе оцениваются следующие показатели функционирования
аналитического модуля: 1) среднее время ожидания требованием на чтение
окончания обновления W реплик для режима строгого согласования реплик; 2)
вероятность того, что клиент прочитает устаревшую запись за время
распространения обновлений записи по ее N-W репликам для режима
согласования реплик в конечном счете; 3) вероятность отказа в доступе к записи
БД.
Были определены требования к режимам согласования реплик
аналитического модуля системы «Надзор за заболеваемостью - NoSQL»: сегмент
Human Case – согласованность в конечном счете, сегмент Human Case Sample –
строгая согласованность.
Заказчик установил размер кластера в 15 узлов (минимальный
рекомендуемый размер кластера Riak – 5 узлов [82]). Добавление / удаление узлов
(серверов) выполняется в 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
Гбайт.
Рассмотрим проблемы согласованности, которые могут возникнуть при
работе с системой:
142
1.
Может возникать задержка чтения записей из сегмента «Human Case
Sample», т.к. в период эпидемий интенсивность чтения и обновления
данных сегмента высока.
2.
При высокой интенсивности чтения данных из сегмента «Human Case»
пользователям может быть возвращена неактуальная информация
(устаревшие записи), т.к. данный сегмент согласован в конечном счете.
Исследование показателей согласованности и отказоустойчивости было
выполнено с помощью инструментального средства, разработанного в Глава 4.
На рисунке 5.3 показаны зависимости среднего времени ожидания (T)
требованием на чтение окончания обновления W реплик в зависимости от
интенсивности поступления требований на чтение записей из сегмента «Human
Case 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 приведена зависимость вероятности P
0
того, что при
выполнении операции чтения произойдет отказ в доступе к записи базы данных
NoSQL (пользователь не получит ответа), от числа реплик записи (N).
Рисунок 5.4 – Зависимость вероятности P от интенсивности поступления
требований на чтение к одному узлу кластера λ (1/с) при различных значениях
числа реплик записи N.
144
Рисунок 5.5 – Зависимость вероятности отказа P
0
от числа реплик записи N.
Из рисунка 5.5 видно, что при увеличении числа реплик записи вероятность
отказа P
0
уменьшается по показательному закону: при увеличении числа реплик
только на 1 вероятность уменьшается примерно на 2 порядка.
Do'stlaringiz bilan baham: |
