Новые виды ответственности
Понятно, что расширяемость и функциональные возможности,
получаемые при добавлении объектных свойств к среде VLDB,
приводят к появлению новых видов ответственности для всех
сторон, связанных с созданием приложений.
Разработчики новых типов данных и методов могут теперь не
являться сотрудниками компании-поставщика СУБД, как это было при
применении чисто реляционных данных. В этом случае они будут
отвечать за оптимизацию данных и обеспечение оценочных функций.
Они также должны обеспечить новые средства индексации и методы
доступа к данным, когда это требуется. При тестировании этого
программного обеспечения потребуются механизмы изоляции и
разрешения проблем. В будущем эти разработчики будут должны при
необходимости предоставлять параллельные версии своих методов.
Новые виды ответственности появляются и у разработчиков
приложений. Они должны более тщательно обдумывать управление
внешней памятью и буферами и решать, что и когда следует
журнализовать. Как и администратор баз данных, они должны
реализовывать стратегии управления внешней памятью и буферами,
наиболее соответствующие проекту приложения, формулировать и
реализовывать стратегию журнализации, соответствующую требованиям
целостности и восстанавливаемости данных, производить более
сложный выбор средств индексации и денормализации и выбирать, где
следует выполнять разные функции для достижения оптимального
соотношения стоимость/эффективность - на сервере баз данных, на
сервере приложений или на стороне клиента.
Наконец, для достижения успеха новые виды ответственности должны
принять на себя и поставщики СУБД. В дополнение к обязанности
поставлять надежно работающие ОР-продукты для параллельных сред
они должны обеспечивать простые для использования интерфейсы,
поддерживающие обсуждавшиеся выше вспомогательные функции:
определение и внедрение новых типов данных, операторов, методов
доступа и индексации, оценочных функций и т.д. Более того, должны
обеспечиваться не только новые средства разработки приложений, но
новые учебные материалы и средства проверки того, что новые
функциональные возможности позволяют производить прикладные
программы настолько же надежные и мощные как и сегодняшние
реляционные приложения.
Многие из этих комментариев применимы не только к сверхбольшим
ОР-базам данных и приложениям, но и к более мелким. Однако
сравнение задач конфигурирования, управления и написания методов
и приложений для этих типов баз данных похоже на сравнение
операций супертанкера и парома. Имеется сходство на уровне
базового набора функций, но многие вопросы, возникающие в
гигантских системах, отсутствуют или неуместны в системах
меньшего масштаба.
Наиболее очевидным различием является то, что параллелизм
абсолютно необходим в случае VLDB и является необязательным (или
даже вредным в связи с накладными расходами) для баз данных более
скромного размера. Другие различия связаны со сложностью
управления метаданными, операций обновления, операций архивации
и восстановления и т.д. Наконец, дополнительную сложность
вызывает потребность в расширении сферы оптимизации. Эта
потребность не ограничивается расширением набора способов оценки
альтернатив, что само по себе представляет принципиальную
проблему для разработчиков ОР-СУБД. Необходима создание
алгоритмов для новых методов на очень больших наборах новых типов
данных, разработка функций для оценки эффективности выполнения
этих новых методов, понимание того, какие ограничения существуют
при распараллеливании выполнения методов. За решение этих
вопросов главным образом отвечают те, кто проектирует и реализует
оптимизатор.
