Методы распределенной обработки

В разных СУБД применяются различные способы распределенной обработки. В Oracle и SQL Server поддержка распределенной обработки осуществляется сходным образом, но одни и те же вещи называются по-разному, и наоборот – разные вещи имеют одинаковые названия. У других производителей также имеется своя терминология. Здесь мы сосредоточимся на основных идеях.
Простейшим способом обработки распределенной базы данных является загрузка данных только для чтения. В этом случае обновлением всех данных в базе занимается только один компьютер, но копии данных только для чтения могут посылаться на множество (возможно, тысячи) компьютеров. В Oracle такие копии, предназначенные только для чтения, называются материализованными представлениями. В SQL Server эти копии называются моментальными снимками.
При более сложном способе распределенной обработки запросы на обновление данных могут приходить со множества компьютеров, но на обработку они передаются одному специализированному компьютеру. Например, компьютер А может быть определен как единственный компьютер, который может обновлять таблицу СОТРУДНИК (и основанные на ней представления), а компьютер Б может быть определен как единственный компьютер, которому разрешено обновлять таблицу КЛИЕНТ (и ее представления). Время от времени обновления должны передаваться обратно на все компьютеры в распределенной сети, и базы данных должны синхронизироваться.
Наиболее сложный способ заключается в том, чтобы разрешить множественное обновление одних и тех же данных в различных местах. В этом случае могут возникнуть три вида конфликтов распределенных обновлений). Во-первых, может быть нарушена уникальность. В базе данных галереи View Ridge два разных компьютера могут создать в таблице ROW строку с одинаковыми значениями столбцов Copy, Title и ArtistlD. Другая возможность напоминает проблему потерянного обновления: на двух компьютерах может обновляться одна и та же строка. Третий конфликт возникает в ситуации, когда на одном компьютере обновляется строка, удаленная на другом компьютере.
Для разрешения конфликтов обновлений выделяется специальный компьютер. Он следит за всеми обновлениями, и возникающие конфликты разрешаются либо собственными средствами СУБД, либо приложениями, подобно тому, как это делается в триггерах. В самых крайних случаях делается запись о конфликте в журнале, и он разрешается вручную. Последний способ не рекомендуется, поскольку до устранения конфликта множество строк в работающих базах данных могут зависнуть в неопределенном положении, что приведет к неприемлемому снижению пропускной способности информационной системы предприятия.
Ни один из этих способов не решает проблемы обеспечения атомарности транзакций в распределенной базе данных. Эта проблема становится особенно важной, если имеется вероятность конфликтов обновлений. В какой момент работу с базой данных можно считать выполненной? Если во время разрешения конфликта распределенных обновлений должен произойти откат обновлений, то потенциально возможно, что распределенная транзакция не будет выполнена в течение нескольких часов или даже суток. Ясно, что такая задержка неприемлема.
Если оставить в стороне конфликты распределенных обновлений, остается еще один сложный вопрос — координация распределенных транзакций. Чтобы транзакция была атомарной, ни одно обновление в распределенной транзакции не должно быть сохранено, пока не будут сохранены все действия транзакции. Это означает, что каждый компьютер должен записать свои обновления условно и ожидать от диспетчера распределенных транзакций уведомления о том, что действия всех остальных компьютеров также записаны. Для этой цели используется алгоритм, называемый двухфазной фиксацией.

Дата добавления: 2015-05-09