Архитектуры хранения данных в кластерных системах.

Существует две основных схемы организации хранения данных в кластерных системах.

6) Подключение к кластерной системе внешних дисковых (и, при необходимости, ленточных) накопителей, соединенных в сеть (сети) хранения данных SAN. Это позволяет каждому узлу кластера в любой момент времени получить доступ к данным, расположенным на любом носителе. Впрочем, для этого необходимо использование специальной файловой системы, например, GFS (для Linux систем). Такая архитектура часто используется в кластерах смешанного типа для получения максимально возможной производительности и надежности.

7) Когда в рамках одной задачи возможно разделить данные так, чтобы некоторое количество запросов можно было обработать, используя только часть имеющихся данных, бывает целесообразно использовать раздельную схему хранения данных. Необходимо, впрочем, учитывать, что такая архитектура приводит либо к снижению отказоустойчивости системы хранения данных, либо к дополнительным затратам на зеркалирование систем хранения. Использование внутренних накопителей узлов крайне нежелательно по следующим причинам: недостаточная надежность встраиваемых RAID – контроллеров, затратность вычислительных ресурсов серверов на поддержку и организацию доступа к внутренним данным, сложность мониторинга и управления ресурсами хранения.

 

Объектно-ориентированные СУБД.

Объектно-ориентированные СУБД. Идентификатор объекта. Языки запросов.

 

Появление объектно-ориентированных СУБД вызвано потребностями программистов на ОО-языках, которым были необходимы средства для хранения объектов, не помещавшихся в оперативной памяти компьютера. Также важна была задача сохранения состояния объектов между повторными запусками прикладной программы. Поэтому, большинство ООСУБД представляют собой библиотеку, процедуры управления данными которой включаются в прикладную программу. Примеры реализации ООСУБД как выделеного сервера базы данных крайне редки.

Пример ООСУБД: Versant, Jasmine

 

Идентификатор объекта

Как это следует из модели данных, каждый объект в базе данных уникален. Существует несколько подходов для идентификации объекта. Самый простой — присвоить ему уникальный номер (OID — object identificator) в базе и никогда больше не повторять этот номер, даже если предыдущий объект с таким номером уже удален. Недостаток такого подхода состоит в невозможности перенести объекты в другую базу без потери связности между ними. Решение этой проблемы заключается в использовании составного идентификатора. Например, в Versant идентификатор OID имеет формат xxxxxxxx:yyyyyyyy, где xxxxxxxx — идентификатор базы данных, yyyyyyyy — идентификатор объекта в базе. Составленный таким образом OID позволяет переносить объекты из базы в базу без потери связи между объектами или без удаления объектов с перекрывающими номерами.

 

В Jasmine применяется другой способ — формирование OID из имени класса объекта и собственно номера объекта. Идентификатор имеет вид classnamexxxxxxxx, где classname — имя класса, а xxxxxxxx — номер объекта этого класса. Недостаток такого подхода заключается в том, что проблема переноса объектов не решена полностью. В разных базах могут оказаться объекты одного класса, а уникальность номеров соблюдается только в пределах одной базы. Преимущество подхода — в простоте извлечения объектов нужного класса: объекты одного класса будут иметь идентификатор, имеющий общую часть. Идеальный же вариант — использование OID, состоящего из трех частей: номер базы, номер класса, номер объекта. Однако и при этом остается вопрос о том, как обеспечить уникальность номеров баз и классов на глобальном уровне — при использовании ООСУБД на различных платформах, в разных городах и странах.

 

Языки запросов.

К сожалению, в объектно-ориентированном программировании отсутствуют общие средства манипулирования данными, такие как реляционная алгебра или реляционное счисление. Работа с данными ведется с помощью одного из объектно-ориентированных языков программирования общего назначения, обычно это SmallTalk, C++ или Java.

 

Общепризнанны две группы вариантов языков запросов. Первая объединяет языки, унаследованные от SQL и представляют собой разновидность OQL (Object Query Language), языка, стандартизованного ODMG. Хотя он существенно отличается от SQL, некоторое подобие явно прослеживается. Например, в Versant поддерживается большинство функций стандарта SQL-92, включая и большой набор арифметических действий и констант. Однако некоторые функции принципиально не могут быть реализованы для объектных баз данных только средствами SQL (например, функции модификации структуры данных). Это обусловлено прежде всего возможной потерей связи с объектами в прикладных программах. Объектно-реляционные СУБД используют различные варианты ограниченных объектных расширений SQL.

 

Вторая, сравнительно новая (применяется с 1998 года) группа языков запросов базируется на XML. Собирательное название языков этой группы — XML QL (или XQL). Они могут применяться в качестве языков запросов в объектных и объектно-реляционных базах данных. Использование в чисто реляционных базах не целесообразно, поскольку языком предусматривается объектная структура запроса