Параллельность в архитектуре, основанной на страницах

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

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

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

Один из подходов состоит в игнорировании наименее важного сценария использования и концентрации усилий на наиболее важном сценарии. Этот подход работает, например, в тех случаях, когда основной сценарий использования системы конфликтует с менее важным вторичным сценарием использования, который проигрывается редко.

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

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

Содержание раздела