Следствия сетевой модели
Различные сетевые модели могут влиять на производительность приложений за счет воздействия на число сетевых взаимодействий и коэффициент полезного использования пропускной способности сети, на который влияет объем значимых данных, пересылаемых по сети. Поведение в сетевой среде тесно связано с моделями приложений и характеристиками доступа.
Приложение с почти фиксированной моделью доступа, хорошо сегментируемой в независимый кластер с не конфликтующими обновлениями и/или не слишком большим числом транзакционных обновлений, как правило, хорошо выполняется в архитектуре, основанной на контейнерах или страницах. Это связано с ограниченным числом сетевых взаимодействий, поскольку фиксированный контейнер связанных объектов захватывается и перемещается в кэш клиента за одно сетевое взаимодействие. Фиксированные модели, относящиеся к сценарию, в котором доступ к логически связанным объектам производится одновременно в одной транзакции, хорошо работают в этих архитектурах, поскольку все логически связанные объекты попадут в клиентский кэш сразу после первого доступа к объекту, и сетевые взаимодействия минимизируются с высоким коэффициентом полезного использования пропускной способности сети. Архитектура, основанная на объектах, обычно приводит к большему числу сетевых взаимодействий, по одному обмену по сети на каждый уровень глубины связей в модели. Например, для модели на приведенном выше рисунке могло бы потребоваться в три раза большее число сетевых взаимодействий. Однако так произойдет, если все объекты, показанные на этом рисунке, находятся в одном и том же контейнере или в одной и той же странице. Если они сегментированы (физически кластеризованы) по-другому, то в архитектуре, основанной на контейнерах или страницах, может потребоваться даже большее число сетевых взаимодействий, чем в архитектуре, основанной на объектах. По этой причине для архитектур, основанных на контейнерах и страницах, сетевая производительность, а фактически, и производительность в условиях параллельного доступа существенно связана с физическим размещением объектов на диске.
В приложении с такими характеристиками коэффициент полезного использования пропускной способности будет достаточно высоким во всех архитектурах, поскольку будут пересылаться группы логически связанных объектов, и избыточные объекты пересылаться по сети не будут.
При возрастании числа конфликтующих обновлений производительность систем с архитектурами, основанными на контейнерах и страницах, уменьшается, и преимущество получают архитектуры, основанные на объектах. Это связано с тем, что конфликтующие обновления вызывают необходимость обновления кэшей конфликтующих клиентов. Для архитектур, основанных на контейнерах и объектах, это означает, что для поддержания согласованности кэшей по сети требуется пересылать страницы или контейнеры. Наибольшей потерей здесь является пропускная способность сети, поскольку при обновлении единственного объекта из нескольких байт потребуется обновить в кэше потенциально большого числа клиентов несколько тысяч байт – страницу или контейнер. Требуется полное обновление страницы или контейнера, поскольку в соответствующей сетевой модели они являются наименьшими единицами гранулированности.
Поясним, что здесь имеется в виду под конфликтующими обновлениями. Это не обязательно означает обновление одного и того же объекта. Конфликтуют обновления объектов, которые находятся в одной и той же странице или одном и том же контейнере. Поэтому в архитектурах, основанных на контейнерах и страницах, требуется хорошая сегментация модели в физическом кластере, поскольку, если модель не является хорошо сегментированной, при обновлении даже не связанных объектов может возникнуть конфликт на уровне страницы или контейнера, который приведет к ожиданию блокировке и нагрузке на сеть для обеспечения согласованности кэшей. Причина, по которой в архитектурах, основанных на контейнерах и страницах, требуется избегать небольших транзакционных обновлений, кроется в том, что при обновлении требуется произвести запись по сети в долговременное хранилище наименьшей единицы передачи данных – страницы или контейнера.
Если обновления хорошо группируются в одну транзакцию, затрагивающую единственный контейнер или страницу, то производительность в таких архитектурах не падает, и в действительности производительность приложения будет намного выше, чем при использовании традиционной реляционной системы.
При возрастании числа конфликтующих обновлений сетевая модель, основанная на объектах, демонстрирует преимущества, поскольку гранулированность пересылок гораздо меньше. Если обновляется объект размером всего в несколько байт, и требуется обновление кэшей клиентов для поддержания их согласованности, то по сети передается всего несколько байтов. Кроме того, немного изменяется понятие конфликтующих обновлений. Во всех архитектурах обновления вынуждают работать механизм согласования кэшей. Поэтому, если модели являются фиксированными и хорошо сегментированными, то архитектуры, основанные на объектах, страницах и контейнерах, ведут себя почти одинаково, если не считать того, что различается объем данных, пересылаемых по сети. Однако если модели не являются хорошо сегментированными, и/или связи между объектами соединяют страницы или контейнеры, которые содержат всего несколько объектов, участвующих в связи, то потенциально потребуется обновлять в кэше многие страницы или контейнеры, содержащие многочисленные избыточные объекты. Это означает, что пропускная способность сети будет использоваться для пересылки избыточных объектов наряду с теми, которые действительно должны быть обновлены в кэше.
Еще одним следствием механизма параллельного доступа и сетевой модели для каждой архитектуры является то, как они ведут себя в трехзвенной архитектуре, будучи встроенными в промежуточное программное обеспечение сервера приложений. Здесь применимы все отмеченные выше аспекты, поскольку кэширование производится локально на серверах приложений, и поэтому для поддержания согласованности кэшей в кластере серверов приложений, который, по существу, является кластером клиентов ООСУБД, требуется обсуждавшееся ранее поведение.
Конечно, на все упомянутое выше влияет увеличение числа пользователей или процессов, получающих доступ к базе данных. Рассмотренные проблемы усложняются при возрастании числа пользователей или процессов. Вообще говоря, архитектура, основанная на объектах, лучше всего подходит для обслуживания большого количества пользователей или процессов, особенно в системах, которые не являются хорошо сегментированными для изоляции, или в которых требуется гибкость для обеспечения в будущем новых паттернов доступа.
Надеюсь, что из приведенного обсуждения стало ясно, что у сетевой модели каждой архитектуры имеются свои преимущества и недостатки. В архитектурах, основанных на страницах и контейнерах, для достижения оптимальной производительности требуется тщательное физическое планирование моделей приложений. В правильно сегментированной фиксированной модели это способствует эффективному использованию пропускной возможности сети. В архитектуре, основанной на объектах, для достижения оптимальной производительности требуется понимание логических сценариев использования. В отличие от архитектур, основанных на страницах и контейнерах, в которых требуется понимание физического моделирования, в архитектуре, основанной на объектах, требуется понимание логики, так что в каждом приложении могут использоваться специальное кодирование или метаданные для определения загрузки модели на основе сценариев использования. Эта работа способствует достижению высокого уровня параллелизма и масштабируемости для исключительного большого числа транзакций, одновременно повышая уровень гибкости для обеспечения возможности перекрывающихся паттернов доступа при будущем использовании данных.
