Архитектуры ООСУБД. Анализ реализаций


Следствия сетевой модели - часть 2


Читая Грина, можно подумать, что он подразумевает обязательность «выталкивания» обновленных страниц в кэши клиентов. Хотя потенциально в серверной архитектуре, основанной на страницах, можно реализовать и такой подход, в ObjectStore это делается совершенно не так. В этой системе страницы «втягиваются» в кэши клиентов по мере необходимости, так что эти обновления не стали бы немедленно посылаться многим клиентам, а попадали бы только к тем из них, которые обращаются к данной странице и, предположительно, нуждаются в обновленных объектах.

«… если модели не являются хорошо сегментированными, и/или связи между объектами соединяют страницы …, которые содержат всего несколько объектов, участвующих в связи, то потенциально потребуется обновлять в кэше многие страницы или контейнеры, содержащие многочисленные избыточные объекты. Это означает, что пропускная способность сети будет использоваться для пересылки избыточных объектов наряду с теми, которые действительно должны быть обновлены в кэше.»

Это утверждение является верным лишь частично. Эта проблема возникает только в том случае, когда используется некорректная стратегия размещения. Конечно, решение состоит в корректной сегментации модели, т.е. приведении в соответствие размещения объектов с особенностями доступа к данным в соответствующих сценариях использования. Тогда этих избыточных пересылок не будет. Как отмечалось выше, путем тщательного размещения экземпляров объектов можно добиться того, чтобы в архитектуре, основанной на страницах, все объекты, необходимые и достаточные для выполнения заданного сценария использования, располагались в минимальном числе страниц. Эти страницы будут пересылаться в минимальном числе сетевых пакетов. Такая конфигурация является предельно эффективной.

«Вообще говоря, архитектура, основанная на объектах, лучше всего подходит для обслуживания большого количества пользователей или процессов, особенно в системах, которые не являются хорошо сегментированными для изоляции, или в которых требуется гибкость для обеспечения в будущем новых паттернов доступа.»

Это обобщение нельзя признать верным, если принять во внимание проблемы узких мест на стороне сервера и накладные расходы на управление блокировками небольших объектов, легко игнорируемые Грином. Проблемы использования данных в будущем и эволюции схемы подробно обсуждаются ниже.




Начало  Назад  Вперед



Книжный магазин