Модели процессов согласования реплик в базах данных Nosql

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 порядка.