Реляционно-сетевая модель данных

Реляционная модель потеряла свою исключительность

Требования функциональности и структурированности баз данных (БД), наиболее полно реализованные в реляционных системах, сейчас находятся под давлением новых требований.

Первая проблема – низкая эффективность для больших данных (big data). Источниками больших данных являются социальные сети, системы видеонаблюдения, пространственные сенсоры, биллинг и т.п. Реляционная БД (РБД) хорошо работает, если схема данных точно определена заранее, до запуска прикладного приложения. Но большие данные по своей сути трудно поддаются структурированию на этапе проектирования БД. Только по мере сбора информации, постепенно, ее структура проявляется более очевидно.

Второе – поиск, вычисление запросов в РБД с таблицами огромных размеров – это задача высокой алгоритмической сложности. Использование индексирования и хеширования хорошо работает в более-менее статичных РБД, которые в значительной степени заполняются еще до запуска системы в эксплуатацию. А в условия быстрого поступления новых массивов данных в реальном времени, преимущества этих методов нивелируются, так как накладные затраты резко возрастают.

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

«Красота» и строгость реляционной модели, реализуемой на SQL, на протяжении 3-х десятков лет восхищали программистов. «Старые» модели: сетевая или иерархическая были почти забыты. Да программных продуктов таких почти не осталось, за исключением, пожалуй, «почти бессмертной» IDMS [1].

В последнее десятилетие идет активная работа по созданию альтернативных систем управления БД (СУБД), которые так просто и называются – NoSQL. Под это понятие сейчас подпадают очень разные системы, которые сильно отличаются между собой. Интересно, что «старые» сетевая и иерархическая модели в понятие NoSQL не входят! Хорошие обзоры в этой области можно найти в [2,3,4].

В категорию NoSQL включают «графовые» БД [5], которые абстрактно близки к канонической сетевой модели CODASYL [6]. Как и следует из самого названия, такие системы представляют собой два неорганизованных множества – узлы (вершины) и ребра (дуги). Главное преимущество сетевых БД – навигация «определяется» не в момент обработки запроса, как в РБД, а в момент добавления новых данных (для графов — вершин и ребер), полностью справедливо и для графовых систем. Но графовая БД не структурирована до начала ее наполнения, в отличие от БД по CODASYL.

Другие самые популярные классы NoSQL БД – «ключ-значение» (пример — Redis [7]) и «хранилище документов» (пример — MongoDB [8]). Так как детальный обзор подобных систем не есть цель настоящей статьи, важно отметить только следующее.

NoSQL системы, как правило, работают на базе распределенных файловых систем, обеспечивающих масштабируемость и надежность [9]. Но задача, которая математически строго решается в рамках реляционной модели – целостность и непротиворечивость базы данных (при условии, конечно, профессионально грамотного проектирования нормализованной схемы) в большинстве NoSQL систем вообще не ставится.

В итого на сегодня ситуация примерно следующая: 75% БД – реляционные, NoSQL в чистом виде используются в узко специализированных системах, а комбинации различных моделей БД применяют в высоконагруженных глобальных сетевых проектах: Google, Facebook, Instagram, WhatsApp и подобных.

Реляционные базы данных без SQL

Кроме приведенных выше практических проблем использования РБД в последнее время стали заметны и другие важные тенденции.

Помимо порой чрезмерной «жесткости» реляционной модели, крупный ее практический (не теоретический) недостаток – сложность манипулирования данными. Первый вариант – использование конвейера операций над множествами – объединения, пересечения, фильтрации и т.п. на практике вообще почти не используется, так как связан с затратами колоссальных ресурсов и оправдан только при «пакетной» обработке множеств однотипных запросов. Второй вариант – интерпретатор языка SQL требует высокого профессионализма, хорошего знания теории множеств, теории баз данных, и немалого практического опыта.

Объектно-ориентированное программирование (ООП) в языках стало стандартом, но SQL – процедурный язык и очень плохо «дружит» с ООП. Вследствие этого популярность приобрело решение задачи стыковки программного кода приложений с запросами на SQL на основе библиотеки классов под названием ORM (Object-Relational Mapping — объектно-реляционное отображение (преобразование) [9]).

Использование классов ORM позволяет программисту обходится без SQL при использовании РБД. ORM автоматически генерирует запросы на SQL к РБД для создания таблиц и манипулирования данными. Большинство ORM имеют интерфейсы с различными популярными СУБД – SQLite, MySQL, PostgreSQL и другими, что дает выбор без модификации программного кода.

Реализаций ORM имеется масса, даже по несколько для каждого языка программирования. Все они похожи, поэтому для определённости в дальнейшем под ORM будем понимать соответствующую библиотеку (пакет) models класса Model фреймворка Django [10] на языке Python [11].

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

Поиск данных в ORM реализуется применением цепочек методов, например, “objects.all()”, “objects.get(…)”, “objects.filter(…)” в Django. Просто, красиво и удобно, но к какой алгоритмической сложности исполнения SQL-запросов, сгенерированных ORM, это приведет, не видно «невооруженным» взглядом.

Когда SQL-запрос пишет человек, предполагается, что он думает и понимает затраты вычислительных ресурсов. ORM вуалирует эту задачу.

Гипертаблица как база данных нового поколения

Нами разработана новая концепция, методы и практические способы объединить реляционную и сетевую модели БД с преимуществами идеи ORM – отказ от использования специальных языков запросов, что позволило создать новую модель и технологию баз данных.

Ключевым понятием является гипертаблица (ГТ) – это база данных, как совокупность отношений(таблиц), в которой используются:

1. «реляционные» атрибуты (домены данных), значениями которых, как в РБД, являются поля строк с самоопределенными данными по соответствующим столбцам таблиц
2. «сетевые» атрибуты (домены ссылок). Будем называть их АТС – атрибут типа «ссылка»

Значениями полей АТС в строках таблицы являются явные ссылки на любые строки в любых таблицах, входящих в гипертаблицу.

Понятие гипертаблицы, введённое нами, никак не связано с проектом [13], который был свернут в 2016 году.

Имеется действующий прототип — комплекс инструментальных средств на языке Python – система управления гипертаблицами HTMS (Hyper Table Management System), в которую входят следующие уровни (сверху вниз):

• редактор (клиент) гипертаблиц HTed – технологический вспомогательный сервис, реализованный как веб-сайт на фреймворке Django, который может подключаться к любому серверу с гипертаблицей независимо от приложений (до некоторой степени функционально близок к утилите PgAdmin для PostgeSQL);
• библиотека утилит и классов логического уровня – API для создания БД и манипулирования данными на прикладном уровне программирования (замена ORM);
• библиотека утилит и классов физического уровня работы с БД, на которой основаны утилиты и классы логического уровня (как API может использоваться опытными системными программистами);
• класс Cage, который предназначен для создания на стороне клиента (приложения) «виртуального» слоя кэшированного удаленного доступа к файлам БД;
• файл-сервер CageServer – программное обеспечение, работающее в мультипрограммном и многопоточном режиме, реализующее функции для многопользовательского удаленного доступа к файлам на сервере по протоколу ftp.

Принципиально возможно вместо Cage использовать обычную локальную файловую подсистему ОС для управления файлами, а также использовать API Cage и ПО CageServer как независимый от HTMS инструмент для реализации удаленного распределенного файлового доступа в любых системах.

В дальнейших статьях планируется подробнее познакомить читателей с системой HTMS.