|
Еще одна подсистема СУБД, которая существенным образом меняется при добавлении версий, — это подсистема управления памятью. Поскольку много версий одного и того же элемента данных могут использоваться параллельно, необходимо эффективное размещение версий в основной памяти. Если заранее неизвестно максимальное число версий, допустимых для одного элемента данных, то это требование трудновыполнимо. Перечисленные трудности проявляются различным образом, в зависимости от выбора алгоритма, что объясняется тем, что алгоритмы фиксируют порядок создания и поддержания версий. Поэтому они влияют как на физическую сторону организации многоверсионной СУБД, так и на логическую. На практике предлагается используются протоколы ROMV и 2V2PL. С одной стороны, эти протоколы достаточно просты в реализации, а с другой — предоставляют пользователю большую часть выгод версионной СУБД. В случае протокола 2V2PL существенную роль также играет его сходство с обычным 2PL. Помимо этого, в 2V2PL решается проблема ограничения числа версий. Сложность решения этой проблемы в случае протокола MVTO, по-видимому, служит одной из причин его малой распространенности. Можно предположить, что та же причина объясняет небольшое количество реализаций, использующих MV2PL. Выводы по разделу 2. 1. Современные СУБД, являющиеся многопользовательскими системами, допускают параллельную одновременную работу большого количества пользователей, что в свою очередь порождает целый комплекс проблем. Выделяют три основные проблемы: проблема потери результатов обновления, проблема незафиксированной зависимости (чтение "грязных" данных, неаккуратное считывание), проблема несовместимого анализа. Анализирование проблем параллелизма показывает, что если не предпринимать специальных мер, то при работе в смеси нарушается свойство (И) транзакций «изолированность». Транзакции реально мешают друг 72 |
Итак, анализ проблем параллелизма показывает, что если не предпринимать специальных мер, то при работе в смеси нарушается свойство (И) транзакций «изолированность». Транзакции реально мешают друг другу получать правильные результаты. Однако не всякие транзакции мешают друг другу. Очевидно, что транзакции не мешают друг другу, если они обращаются к разным данным или выполняются в разное время. Транзакции называются конкурирующими, если они пересекаются по времени и обращаются к одним и тем же данным. В результате конкуренции за данными между транзакциями возникают конфликты доступа к данным. Различают следующие виды конфликтов: • W-W (Запись Запись). Первая транзакция изменила объект и не закончилась. Вторая транзакция пытается изменить этот объект. Результат потеря обновления. • R-W (Чтение Запись). Первая транзакция прочитала объект и не закончилась. Вторая транзакция пытается изменить этот объект. Результат несовместимый анализ (неповторяемое считывание). • W-R (Запись Чтение). Первая транзакция изменила объект и не закончилась. Вторая транзакция пытается прочитать этот объект. Результат чтение "грязных" данных. Конфликты типа R-R (Чтение Чтение) отсутствуют, т.к. данные при чтении не изменяются. Другие проблемы параллелизма (фантомы и собственно несовместимый анализ) являются более сложными, т.к. принципиальное отличие их в том, что они не могут возникать при работе с одним объектом. Для возникновения этих проблем требуется, чтобы транзакции работали с целыми наборами данных. График запуска набора транзакций называется последовательным, если транзакции выполняются строго по очереди, т.е. элементарные операции транзакций не чередуются друг с другом. Если график запуска набора должно приниматься во внимание во многих компонентах СУБД. В связи с этим необходимо обеспечить корректное взаимодействие этих компонентов. Очевидным образом, с учетом версий должно происходить поддержание поисковых структур. С учетом версий должна строиться и журнализация. Более того, поскольку и журнал и версии содержат информацию о старом состоянии базы данных, возможно объединение этих сущностей. Еще одна подсистема СУБД, которая существенным образом меняется при добавлении версий, — это подсистема управления памятью. Поскольку много версий одного и того же элемента данных могут использоваться параллельно, необходимо эффективное размещение версий в основной памяти. Если заранее неизвестно максимальное число версий, допустимых для одного элемента данных, то это требование трудновыполнимо. Перечисленные трудности проявляются различным образом, в зависимости от выбора алгоритма, что объясняется тем, что алгоритмы фиксируют порядок создания и поддержания версий. Поэтому они влияют как на физическую сторону организации многоверсионной СУБД, так и на логическую. На практике предлагается используются протоколы ROMV и 2V2PL. С одной стороны, эти протоколы достаточно просты в реализации, а с другой — предоставляют пользователю большую часть выгод версионной СУБД. В случае протокола 2V2PL существенную роль также играет его сходство с обычным 2PL. Помимо этого, в 2V2PL решается проблема ограничения числа версий. Сложность решения этой проблемы в случае протокола MVTO, по-видимому, служит одной из причин его малой распространенности. Можно предположить, что та же причина объясняет небольшое количество реализаций, использующих MV2PL. 3.7 Выводы 1. Современные СУБД, являющиеся многопользовательскими системами, допускают параллельную одновременную работу большого количества пользователей, что в свою очередь порождает целый комплекс проблем. Выделяют три основные проблемы: проблема потери результатов обновления, проблема незафиксированной зависимости (чтение "грязных" данных, неаккуратное считывание), проблема несовместимого анализа. Анализирование проблем параллелизма показывает, что если не предпринимать специальных мер, то при работе в смеси нарушается свойство (И) транзакций «изолированность». Транзакции реально мешают друг другу получать правильные результаты, что в свою очередь естественным образом сказывается на надёжности функционирования программного обеспечения. 2. Если заранее известен набор всех поступающих транзакций, то теоретически можно перебрать все возможные варианты графиков запусков (их конечное число, хотя и очень большое), и выбрать из них те графики, которые, во-первых, правильные, а во-вторых, оптимальны по выбранному критерию. Однако в реальной ситуации неизвестно не только какие транзакции будут поступать в какие моменты времени, но и неизвестна длительность периода времени, охватывающего набор транзакций. Т.к. транзакции не мешают друг другу, если они обращаются к разным данным или выполняются в разное время, то имеется два способа разрешить конкуренцию между поступающими в произвольные моменты транзакциями: • притормаживать" некоторые из поступающих транзакций настолько, насколько это необходимо для обеспечения правильности смеси транзакций в каждый момент времени (т.е. обеспечить, чтобы конкурирующие транзакции выполнялись в разное время). Данный алгоритм реализуется путем использованием блокировок различных видов или метода временных меток. • предоставить конкурирующим транзакциям "разные" экземпляры данных (т.е. обеспечить, чтобы конкурирующие транзакции работали с разными версиями данными). Данный алгоритм реализуется путем использованием данных из журнала транзакций. |