Варианты архивации баз данных

Замета специалиста Британской библиотеки Карла Уилсона (Carl Wilson – на фото) была опубликована  20 февраля 2012 года на его блоге  на сайте проекта Open Planets.

Прошлую неделю я провел на семинаре по архивации баз данных, организованном фондом Open Planets на площадке Государственных архивов Дании (Statens Arkiver) в Копенгагене. Там образовалась хорошая «смесь» участников – «технарей» и практиков; был сделан ряд информативных докладов, и было интересно посмотреть на различные подходы к решению проблемы.

Как мне кажется, четко выделяются два различных подхода к архивации баз данных (use cases):

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

В этом случае требуется обеспечить сохранность всей системы, т.е.

• Структуры таблиц, включая типы данных и связи.
  
  
• Содержащуюся в базе данных бизнес-логику, - например, сохраненные в ней процедуры, триггеры, ограничения и т.д.,
  
  
• В идеале, учетные записи и права доступа пользователей также должны быть сохранены, чтобы обеспечить аутентичность доступа.

В этом случае напрашивается применение метода эмуляции, однако здесь есть и потенциальные проблемы:

• Обеспечение сохранности системы / набора систем, вместе с правами пользователей и сопутствующими приложениями, - нетривиальная задача даже для сравнительно простых систем;
  
  
• Оригинальная среда может быть не такой уж сложной, и в этом случае может быть трудно получить какую-то новую отдачу от старых данных;
  
  
• Обеспечение сохранности старых систем потенциально связано с издержками в виде сохранения технических навыков, необходимых для их использования, - например, сохранение навыков администрирования базы данных может стоить очень дорого.

2. Извлечение / миграция исходных данных и структуры таблиц из оригинальной базы данных.

Второй подход фактически является подмножеством первого:

• Данные и метаданные таблиц могут быть преобразованы в доступный формат на основе XML, например, в формат SIARD,
  
  
• По мере возможности сохраненные процедуры, ограничения и т.д. также преобразуются в XML,
  
  
• Для повторного использования преобразованные (сериализованные) данные могут быть загружены в различные реляционные СУБД либо в альтернативные базы данных.

Хотя такой подход прагматичен, главный его недостаток связан с тем, что именно не будет извлечено из оригинальной базы данных. Будет информация, которую не удастся мигрировать в новую базу данных. Так, я не могу припомнить ни одного диалекта для записи сохраняемых процедур, который бы не нарушал стандарт SQL самыми различными способами.

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

Метод преобразования (сериализации) используется более широко. В ходе семинара в нескольких докладах были продемонстрированы соответствующие инструменты. Проблема в том, что ни одна из продемонстрированных систем не использует общего формата для сериализации. По крайней мере в двух представленных инструментах использовался формат SIARD, однако разработчики кое в чем адаптировали его в соответствии со своими потребностями. Это сводит на нет преимущества использования единого формата, то есть теряется интероперабельность.

Если бы мне пришлось выбирать единый формат, то я бы выбрал бы SIARD, который используется уже в течение нескольких лет, и будет представлен на стандартизацию в Международную организацию по стандартизации (ИСО).

Карл Уилсон (Carl Wilson)

Источник: блог Карла Уилсона на сайте Open Planets Foundation
http://www.openplanetsfoundation.org/blogs/2012-02-20-use-cases-database-archiving