Данная статья захватывает ключевые моменты (по-моему мнению) в развитии систем управления базами данных, от первых иерархических моделей до современных реляционных, NoSQL и NewSQL систем.
Содержание:
-
-
Ключ-значение
-
Документ-ориентированное хранилище
-
Колоночное хранилище
-
Графовое хранилище
-
Эволюция СУБД: от иерархических к реляционным
В 1960 возникла потребность в надежной модели хранения и обработки данных, особенно важной для банков и финансовых организаций. В то время отсутствовали единые стандарты работы с данными и моделями, и вся работа сводилась к ручной упорядоченной организации информации. Банкам удавалось записывать информацию о транзакциях в виде файлов в заранее подготовленную структуру, причем у каждой организации было собственное представление о том, как это должно выглядеть и функционировать. Также отсутствовали понятия
Иерархическая модель данных — модель данных, где используется представление базы данных в виде древовидной (иерархической) структуры, состоящей из объектов (данных) различных уровней.
Такая модель данных представляет собой:
-
Запись может иметь только одного «предка».
-
Возможны отношения только «один к одному» или «один ко многим».
-
Невозможность реализации отношения «многие ко многим».
-
Проблема дублирования.
-
Сложность в поддержке.
В 60-х годах иерархическая модель баз данных была популярной, но недостаточно гибкой. В такой модели каждая запись могла иметь только одного «предка», даже если у отдельных записей было несколько «потомков». Это приводило к тому, что базы данных представляли только отношения «один к одному» или «один ко многим». Невозможность реализации отношения «многие ко многим» приводила к проблемам при работе с данными и усложняла модель. Из-за этого вопросы о консистентности данных и отсутствии дублирования информации часто не удавалось эффективно решить. Первая иерархическая система управления базами данных (СУБД) получила название IMS и была разработана компанией IBM.
Для решений проблем такого подхода появилась новая модель данных — Сетевая.
Сетевая модель данных
В ней появилась новая концепция «многие ко многим». Эта модель данных, являющаяся расширением иерархического подхода, — у потомка может быть любое число предков.
Данный подход был предложен как спецификация модели CODASYL в рамках рабочей группы DBTG (Data Base Task Group).
И даже такая модель имела недостатки на тот момент:
-
Высокая сложность структуры базы данных, требующая дополнительных усилий для разработки и поддержки.
-
«Жесткость» структуры базы данных, что затрудняло внесение изменений и модификацию данных.
-
Неполная независимость модели от приложения, что могло усложнять интеграцию с различными приложениями и изменения в структуре данных.
Эти недостатки сетевой модели данных могли замедлять разработку и поддержку баз данных, а также усложнять их адаптацию к изменяющимся потребностям бизнеса.
Появление реляционных баз данных
Франк Кодд существенно упростил задачу сбора и обработки данных, что привело к возникновению реляционных баз данных, которые стали неотъемлемой частью практически всех отраслей. Он также предложил язык Alpha для управления реляционными данными.
Когда Кодд опубликовал свою работу, которая послужила основой для создания реляционной модели данных. Он выделил преимущества данной модели:
-
Отсутствие дублирования данных
-
Исключение ошибок и аномалий данных
-
Представление всех данных как фактов, хранящихся в виде отношений (
Пример реляционной модели данных Одной из первых реляционных СУБД была dBase-II от компании Ashton-Tate. Она была выпущена в 1979 году и разошлась тиражом около 100 000 копий, став самой популярной среди всех существовавших в то время продуктов. Это действительно стало началом, и другие компании также начали предоставлять свои продукты, включая такие известные системы как Oracle и Ingress.
Развитие баз данных усилилось после распространения локальных и глобальных сетей. Пользователи также хотели иметь возможность параллельной работы с реляционными базами данных, что способствовало развитию многопользовательских приложений для локальных сетей. В результате была создана
Появление Not Only SQL систем
Not Only SQL (далее NoSQL) — это подход к проектированию баз данных, который предоставляет механизмы хранения и извлечения данных, отличные от традиционных реляционных баз данных. NoSQL базы данных разработаны для работы с конкретными моделями данных и обладают гибкими схемами, которые легко масштабируются для современных приложений.
Необоримость появления такого подхода произошла из-за:
-
Рост объемов данных: Во время больших данных компании столкнулись с необходимостью обработки огромных массивов информации, превышающих возможности традиционных реляционных СУБД.
-
Распределенные вычисления: С появлением интернета вещей (IoT) и мобильных приложений возросла потребность в распределенных системах обработки данных, где реляционные СУБД показали свои ограничения по масштабируемости и географической дистрибуции
-
Разнообразие типов данных: Современные приложения часто работают с неструктурированными или полу-структурированными данными (текст, изображения, видео, социальные медиа), для которых реляционная модель не всегда является оптимальной.
Существует четыре типа NoSQL
-
Ключ-значение (Key-value) — наиболее простой вариант хранилища данных, использующий ключ для доступа к значению в рамках большой хэш-таблицы.
Пример ключ-значение модель -
Документ-ориентированное хранилище, в котором данные, представленные парами ключ-значение, сжимаются в виде полуструктурированного документа из тегированных элементов, подобно JSON, XML.
Пример документ-ориентированная модель -
Колоночное хранилище, которое хранит информацию в виде разреженной матрицы, строки и столбцы которой используются как ключи.
Пример Колоночной модели
Одежда
Цвет
Размер
Футболка
Белый
70
Перчатки
Красный
40
-
Графовое хранилище представляют собой сетевую базу, которая использует узлы и рёбра для отображения и хранения данных.
Пример графовой модели В начале 2010-х годов, на фоне стремительного роста объемов данных и популярности облачных технологий, стало очевидно, что как традиционные реляционные, так и новаторские NoSQL системы управления базами данных не могут в полной мере удовлетворить все растущие требования рынка. С одной стороны, реляционные базы данных сталкивались с проблемами масштабируемости и гибкости в обработке больших объемов данных. С другой стороны, NoSQL системы предлагали решения для этих проблем, но зачастую жертвуя согласованностью данных и совместимостью с SQL.
Появление NewSQL систем
NewSQL системы были разработаны как попытка объединить преимущества обеих подходов, предлагая масштабируемые и высокопроизводительные решения для управления данными, которые при этом поддерживают строгие транзакционные гарантии и полностью совместимы с SQL. Это позволило создать новый класс систем
Причины появления NewSQL:
-
Требование к
Последствия появления NoSQL и NewSQL систем
С появлением систем NoSQL и NewSQL, мир управления базами данных столкнулся с значительными изменениями, которые затронули как большие организации, так и индивидуальных разработчиков. Эти изменения оказали глубокое влияние на способы хранения, обработки и анализа данных.
Следствием этого стало и ускорение процесса разработки. Благодаря возможностям, предоставляемым как NoSQL, так и NewSQL системами, разработчики смогли более эффективно адаптировать свои приложения к специфическим требованиям проектов, обеспечивая более быстрое и качественное выполнение работ.
Итог. В этой статье я рассмотрел кратко историю развития систем управления базами данных, начиная с иерархических и сетевых моделей 60-х годов и заканчивая современными реляционными, NoSQL и NewSQL системами. При написания статьи я не рассчитывал, что сможете узнать все про базы данных. Но надеюсь с помощью этого вы познакомились с ключевыми моментами, которые помогут в дальнейшем разбирать эти темы более подробно.
-
ссылка на оригинал статьи https://habr.com/ru/articles/803247/
Добавить комментарий