5.2.2. Учет и расчеты

В локально автономных системах сервер может в уплату за предоставление сервиса потребовать перечисления определенной денежной суммы. В прежних распределенных СУБД предполагалось, что вся информация является собственностью одной корпорации, и этот "неудобный" вопрос не возникал.

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

Еще один интересный вопрос – выработка стратегий реализации запросов с учетом их денежной стоимости. Допустим, вас интересует библиография публикаций о динозаврах. Местный музей предоставляет информацию бесплатно, но она может быть менее полной, чем та, которой располагает коммерческая библиографическая служба. Желательно, чтобы механизм реализации запросов учитывал плату, взимаемую разными источниками, и использовал бы, в первую очередь, бесплатные источники. Предположим, что после извлечения бесплатных данных запрос к дорогостоящему источнику был бы сформулирован следующим образом: "Пришлите список всех публикаций о динозаврах, за исключением следующих 2000, о которых я уже знаю". Логично предположить, что коммерческая служба отвергнет подобный запрос, реализация которого потребует больших затрат ресурсов, а результат, скорее всего, окажется мизерным или пустым, и плата за него будет невелика (что, впрочем, зависит от алгоритма вычисления стоимости). Задача исследователей состоит в разработке согласованных механизмов ценообразования, сервисных политик, алгоритмов оптимизации с учетом цен, алгоритмов обработки счетов за обслуживание.

5.2.3. Безопасность и конфиденциальность

В распределенных системах, включающих автономных партнеров, требуется поддержка безопасности информации. Во многих случаях это нужно для обеспечения конфиденциальности персональных данных. Например, информационная система здравоохранения должна беспрепятственно предоставлять информацию о пациенте его лечащему врачу, но обязана защитить ее от несанкционированного доступа. В других случаях необходимость защиты связана с коммерческой ценностью данных. Примеры – распределенное проектирование (разд. 3.5) и электронные публикации (разд. 3.4). Можно выделить следующие важные направления исследований.

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

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

5.2.4. Репликация и согласование данных

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

Разумеется, компоненты базы данных, связь между которыми сохраняется, должны продолжать функционировать независимо наилучшим возможным способом. Запросы на выборку и модификацию данных, затрагивающие доступные узлы, должны выполняться, а остальные – отвергаться.

Из соображений эффективности данные часто реплицируются на нескольких узлах. Когда все эти узлы связаны сетью, можно поддерживать идентичность копий. Однако в ситуациях, когда связь нарушается, в копиях могут появиться различия. После восстановления связи должен включаться механизм согласования (reconciliation), который должен согласовать все копии и сформировать одну новую копию, отражающую все сделанные изменения.

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

Отметим также, что, в связи с растущей зависимостью производственных процессов от информационных систем, для многих приложений необходимым требованием становится стопроцентная доступность, или, как это иногда обозначают, "доступность 7х24" (7 дней в неделю х 24 часа в сутки). Некоторые проблемы повышения надежности решаются за счет совершенствования аппаратных средств. Однако в среде баз данных для повышения доступности необходимо исследование новых репликационных схем, обеспечивающих идентичность копий данных и корректное функционирование системы в условиях отказа отдельных компонентов.