Модели баз данных: иерархическая, сетевая, реляционная и ключ-значение

Иерархическая, сетевая, реляционная и ключ-значение

Способов организовать данные придумано немало, и каждый из них отражает своё время и свои задачи. Классификация баз данных по типу модели складывалась постепенно, вслед за развитием самих технологий: одни модели рождались, набирали силу, а затем уступали место более гибким. Сегодня принято выделять несколько основных типов — сетевую, иерархическую, реляционную, объектно-ориентированную и модель «ключ-значение». Разберём ключевые из них, чтобы понять, чем они различаются и почему индустрия двигалась именно таким путём.

Иерархическая и сетевая модели

Начнём с двух самых ранних моделей — они тесно связаны между собой, и одну проще понять через другую.

Иерархическая модель хранит объекты вместе с указателями связей, которые ведут от родительских объектов к их потомкам. Наглядно всю эту конструкцию удобно изображать в виде дерева. На самой вершине располагается корневой объект, ниже идут объекты второго уровня, затем третьего и так далее. При этом у одних объектов-предков потомков может не оказаться вовсе, у других их несколько, но действует жёсткое правило: у любого объекта-потомка всегда лишь один предок.

Иерархическая модель вовсе не музейный экспонат — мы сталкиваемся с ней каждый день. Типичные примеры таких баз:

• файловые системы;
• реестры настроек (скажем, реестр ОС Windows);
• структуры документов — например, объектная модель документа (Document Object Model) у загруженных в браузер HTML-страниц.

Сетевая модель оперирует тремя понятиями — уровень, узел и связь. Центральное из них — узел.

Узел — это совокупность атрибутов, описывающих некоторый объект.

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

Иерархическую модель можно рассматривать как частный случай сетевой. Однако у сетевой есть свои слабые места: даже простые запросы выполняются в ней довольно непросто. Второй заметный минус — жёсткая привязка к обслуживающему приложению, которое приходится переписывать всякий раз, когда меняется структура данных.

Реляционная модель

Следующий шаг в развитии баз данных оказался революционным. Само слово «реляционный» восходит к математическому понятию отношения (relation). Упрощённо отношение принято называть таблицей — так его проще представить.

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

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

Модель «ключ-значение»

При всей своей популярности, простоте и надёжности реляционная модель со временем обнаружила ряд слабых сторон:

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

На этом фоне всё активнее набирает популярность альтернатива — модель «ключ-значение». Появилась она давно, но изначально применялась вовсе не для баз данных, а для удобного доступа к объектам в памяти компьютера. В программировании подобные структуры известны как словари, хэш-таблицы, а иногда их называют просто объектами.

Базы, построенные на этой модели, объединяют под общим именем NoSQL, хотя конкретные реализации внутри этого семейства заметно различаются. Долгое время развитие таких баз сдерживала нехватка вычислительной мощности. Но сегодня, когда в дата-центрах трудятся миллионы производительных машин, хранение данных в формате «ключ-значение» стало привлекательным даже для больших массивов. Больше того, скорость доступа к данным в ряде случаев оказывается выше, чем у реляционных баз.

Ключ вполне может иметь осмысленную структуру. Благодаря этому запросы в таких базах по эффективности порой не уступают запросам SQL. Вот как это выглядит на практике (пример в формате БД Redis):

set writer:1:name:last 'Пушкин'
set writer:1:name:first 'Александр'
set writer:1:date:birth '1799'
set writer:1:date:death '1837'

keys 'writer:1:name*'
keys 'writer:1:date*'
keys 'writer:1:*'
 

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

Удобнее всего держать все модели в голове как линию развития от жёстких структур к гибким. Иерархическая модель раскладывает данные по дереву с единственным предком у каждого узла — она прекрасно ложится на файловые системы, реестр Windows и структуру HTML-документа. Сетевая снимает ограничение «один предок» и позволяет связать любой узел с любым, но платит за это сложностью запросов и привязкой к приложению; иерархическую при этом можно считать её частным случаем. Реляционная модель опирается на математическое понятие отношения, дарит наглядные «таблицы» и язык SQL, а потому с 1980-х годов и доминирует в индустрии. Наконец, модель «ключ-значение» (NoSQL) отвечает на слабости реляционного подхода: она проще справляется со сложными и изменчивыми объектами, хорошо масштабируется в дата-центрах и нередко выигрывает в скорости доступа. Общее правило простое: для строго древовидных данных подходит иерархическая модель, для наглядной структурированной информации со связями — реляционная, а для огромных объёмов гибко устроенных данных — «ключ-значение».