Эффективность и технические требования
В общем случае, при вхождении сервера в состав ЛВС и при разбиении БД на m сегментов, при котором m > n (n — число рабочих станций), вероятность нахождения сегмента на одной из РС в процессе ротации равна


Схема на рис. 2.3 соответствует случаю m = n.
Тогда среднее время Tож ожидания нужного сегмента, то есть возможного начала обращения к нужному сегменту на той РС, которая выработала запрос, находится на основе вероятности того, что он поступит через один такт, через два такта и т.д. Максимальное число учитываемых тактов равно m - 1:
![]() |
(2.1) |
Тогда полное время обслуживания запроса в ротационной БД находится следующим образом:
![]() |
(2.2) |
где tобсл — время выполнения запроса с помощью СУБД.
Сравним это полное время обслуживания со средним временем обслуживания T*обсл "традиционной" БД, реализованной на сервере. Напомним, что при обслуживании такой БД многоканальная система массового обслуживания, где множество рабочих станций обеспечивают массовый доступ, реально, с помощью одноканальной СУБД, на этапе обслуживания потока заявок преобразуется в одноканальную систему массового обслуживания с неограниченной очередью.
Допустив, что время выполнения запроса с помощью СУБД в данном случае совпадает с тем же временем в ротационной БД (ротация не предполагает каких-либо принципиальных изменений "традиционных", известных, широко применяемых СУБД), получим:
![]() |
(2.3) |
где ? — известное отношение


Уточним, что ?* = n?польз, где ?польз — интенсивность потока запросов с одной РС при данной организации БД. Однако здесь мы пренебрегли временем передачи сообщений в ЛВС, учитывая существенный характер ограничений другого рода. А именно, суммарная интенсивность ?* потока запросов в системе должна быть ограничена значением, обеспечивая соотношение ? < 1. Полное время обслуживания T*обсл значительно возрастает при значениях ?, близких единице:
T*обсл

?

В ротационной базе данных каждая РС независимо от других реализует одноканальную систему массового обслуживания с неограниченной очередью, где, несомненно, тоже должно выполняться соответствующее ограничение ?польз < ?польз, где ?польз — интенсивность запросов пользователя с одной РС, ?польз
— интенсивность обслуживания запросов пользователя с одной РС,

![]() | (2.4) |
где ?max — некоторая максимально возможная интенсивность потока запросов, последовательно (по мере выполнения) формируемых пользователем в том случае, если доступ к сегментам базы данных, находящимся в памяти его РС, не ограничен ротацией, т.е. tрот = 0.
Таким образом, исследуя вопрос о целесообразности построения ротационной БД, необходимо изучить практические возможности обеспечения таких характеристик ЛВС, их аппаратных и программных средств, при которых выполняется соотношение

или
![]() | (2.5) |

Напоминаем, что здесь
T0 — время (длина) такта системы,
m — число сегментов БД,
n — число рабочих станций ЛВС,
tобсл — время выполнения одного запроса СУБД (характеристика используемой системы управления базой данных),
?польз — интенсивность потока запросов одного пользователя,
? — интенсивность обслуживания запросов данной СУБД.
Однако выражение (2.5) получено в предположении, что заявка на обслуживание, поступившая от конкретной РС к некоторому сегменту si, не претерпевает какого-либо влияния возможных, в достаточно близкое время, заявок, пришедших к этому же сегменту от других РС "на пути следования" сегмента к данной РС. А именно, за предполагаемое среднее время Tож требуемый сегмент может быть "перехвачен" другой РС, "предшествующей" ожидающей.
При значительной интенсивности ? заявок такой возможностью нельзя пренебречь.
Предположим не более чем однократную возможность такого "перехвата".
Тогда, считая, что поток заявок к БД простейший (пуассоновский, экспоненциальный), вероятность Pi того, что сегмент si без дополнительных помех на пути следования дойдет до данной РС, находится как
![]() | (2.6) |

Если запросы ко всем сегментам равновероятны, то
![]() | (2.7) |
![]() | (2.8) |
"Перехват" дополняет общее время выполнения заявки составляющей (1-P)tобсл. Тогда окончательно среднее время обслуживания заявок в ротационной БД в рассматриваемом случае определяется как
![]() | (2.9) |
![]() | (2.10) |