Как всё начиналось
Разговор начался с практической задачи: найти всех друзей друзей пользователя (глубина 2) в графе из 1 млн узлов и 10 млн рёбер. Казалось бы, тривиальный запрос. Но как он выполняется в разных системах — вопрос, который открывает дверь в мир фундаментальных различий между моделями данных.
Собеседник А: В PostgreSQL рекурсивный запрос с CTE будет использовать nested loop join. На глубине 5 разница с графовой базой — в сотни раз.
Собеседник Б: Но ведь физически данные можно представить одинаково. Фундаментальной разницы в хранении «простых записей» между моделями нет, если не считать связей.
Это замечание оказалось ключевым. Собеседник Б был прав: любую модель можно эмулировать на любой другой с помощью подходящих индексов и структур. Но реальные СУБД выбирают разные точки оптимизации. Реляционные — для плоских таблиц и агрегаций. Графовые — для обходов связей с переменной глубиной. Разница появляется именно при работе со связями, а не с простыми свойствами.
Собеседник А: Резюмируя: вы правы в том, что фундаментальной физической разницы в хранении «простых записей» между моделями нет. Но реальные СУБД выбирают разные точки оптимизации — и вот здесь начинается самое интересное.
Собеседник Б: То есть разница не в том, что можно хранить, а в том, как быстро можно получить нужное?
Собеседник А: Именно. И это приводит нас к вопросу о выборе правильной модели под конкретную задачу.
Сетевая модель и многомерные массивы
Развивая тему, собеседники перешли к вопросу: какую модель данных представляет собой схема на многомерных массивах, где пользователи и организации хранятся в одних массивах, а связи между ними — в отдельных?
Собеседник Б: Есть объекты — пользователи: ^user(1,name)="alex", организации: ^org(1,name)="JPL". И есть отдельно связи: ^sv(1,1)=1. Это какая модель?
Собеседник А: Очень интересный пример! Вы описали гибридную модель, ближе всего к сетевой модели данных (network model), реализованную через глобальные многомерные массивы — классический пример подхода MUMPS / СУБД "ГЛОБАЛ" / Caché / IRIS.
Такая конструкция позволяет быстро найти все связи для пользователя: $ORDER(^sv(1, "")), быстро найти всех пользователей организации: $ORDER(^sv("", 2)) и гибко добавлять новые измерения без миграции схемы.
Собеседник Б: При этом я могу увеличить вложенность, при явном разделении каких-либо объектов между собой, и получить ещё более размытое понятие, потому что появится ещё и иерархия в данных. На мой взгляд, это самая универсальная конструкция данных для применения.
Собеседник А: Вы бросили великолепный вызов. Действительно, многомерный массив с произвольной вложенностью может эмулировать любую модель: иерархическую, реляционную, графовую, документную, объектную. Спорить с тем, что это самая универсальная конструкция — почти как спорить, что «машина Тьюринга универсальна». Но давайте разберёмся, что практично, эффективно и безопасно для человека и команды.
СУБД "ГЛОБАЛ" — сверхбыстрая многомерная база данных
До 1 млн операций в секунду на запись и чтение. Полная поддержка ACID-транзакций, журналирование, репликация и масштабирование. Совместимость с AstraLinux и RedOS.
В основе — проверенный десятилетиями язык MUMPS (ISO/IEC 11756:1999). При этом СУБД "ГЛОБАЛ" предоставляет API для работы с C, PHP, Java, Python, Go и другими популярными языками — вы не ограничены одним языком программирования.
Включена в Единый реестр отечественного ПО (приказ Минцифры № 486 от 29.09.2020).
Универсальность как вызов
Собеседник Б выдвинул сильный тезис: многомерный массив с произвольной вложенностью может эмулировать любую модель данных — иерархическую, реляционную, графовую, документную, объектную. Это самая универсальная конструкция. На первый взгляд, это утверждение неоспоримо. Как машина Тьюринга универсальна для вычислений, так многомерный массив универсален для представления данных. Однако универсальность имеет свою цену.
Аргументы против «абсолютной универсальности»
1. Понятность. Многомерный массив — это «ассемблер данных». На нём можно всё, но читать такую схему спустя полгода — боль. Что означает запись ^data("user", 123, "profile", "name", "en") = "Alex"? Без документации — гадание. В реляционной модели SQL-запрос SELECT name FROM users WHERE id = 123 ясен сразу.
2. Схема данных. Универсальная конструкция не имеет встроенной схемы. Ошибка в имени атрибута (^user(1,"наме") вместо "name") обнаружится только в runtime. Миграции данных требуют полного сканирования массива, тогда как в реляционной БД — ALTER TABLE ... RENAME COLUMN.
3. Оптимизация запросов. В SQL оптимизатор за 30 лет накопил тысячи human-years оптимизаций: выбор плана, параллелизм, оценка селективности, материализация, hash join vs merge join. На многомерном массиве вы пишете циклы вручную.
4. Стандартизация. SQL — это стандарт. JOIN, GROUP BY, DISTINCT, UNION, WINDOW — понятны любому разработчику. На многомерном массиве эти операции нужно реализовывать заново.
5. Инструменты и экосистема. Реляционные БД имеют визуализацию (Tableau, Power BI), ORM (SQLAlchemy, Hibernate), генерацию отчётов, ролевую модель безопасности, бэкапы и репликацию. У многомерного массива — всё надо писать самому.
6. Целостность данных. Как гарантировать, что ссылка в ^sv(1,2)=1 ведёт на реально существующие записи? В реляционной БД — FOREIGN KEY декларативно. На массиве — ручные триггеры.
Собеседник Б: Убедительные аргументы. Но универсальность конструкции — это не про практическое использование, а про математическую выразительность. А для работы с данными людям нужны контракты, стандарты, оптимизаторы и инструменты. Согласен.
Собеседник А: Ваша конструкция — это отличный низкоуровневый кирпич. На нём можно построить реляционную СУБД, графовую, документную. Но пользоваться напрямую этим кирпичом — всё равно что писать сайт на ассемблере: можно, но зачем?
Сравнительная таблица наглядно показывает разницу:
| Критерий | Многомерный массив | Реляционная модель |
|---|---|---|
| Выразительная сила | Максимальная (полна по Тьюрингу) | Высокая |
| Декларативность запросов | Нет (императивные обходы) | Да (SQL) |
| Автоматическая оптимизация | Нет (вы пишете циклы) | Да (оптимизатор запросов) |
| Схема данных | Неявная, в коде | Явная (DDL) |
| Целостность ссылок | Ручная | Декларативная (FK) |
| Стандартизация | Нет (ad-hoc) | Есть (ANSI SQL) |
| Инструментарий | Свой для каждого проекта | Огромный |
| Обучение разработчиков | Долго (домен + массив) | Быстро (SQL известен) |
Искусственный интеллект меняет правила игры
И тут прозвучало то, что перевело дискуссию на совершенно иной уровень.
Собеседник Б: А теперь прибавьте к моим мыслям ИИ, который будет быстро писать код и следить за его правильностью и архитектурой, применять оптимальную структуру для хранения и выборки данных, наращивать библиотеку самых эффективных функций работы с данными, применяя всю мощь многомерных массивов, поддерживать установленные стандарты при смене версий. Держать в голове все сложности и все связи у человека отпадёт — он только будет пользоваться информацией, а ИИ будет выбирать самый оптимальный подход для работы с данными. На мой взгляд, многомерные массивы и ИИ — это будущее для работы с информацией.
Собеседник А: Теперь вы перевели дискуссию на совершенно иной уровень. Это уже не спор «какая модель лучше», а видение архитектуры следующего поколения. И оно, я должен признать, внутренне непротиворечиво и очень мощно.
Это видение архитектуры следующего поколения: ИИ + многомерные массивы как универсальный бэкенд + автоматическое поддержание схемы и оптимизация. Человек работает с информацией (семантический уровень), а ИИ — с данными (физический уровень).
Собеседник А: Давайте разберём, что в этой идее действительно сильно. Единый формат хранения — не нужно конвертировать данные между PostgreSQL, Neo4j и Redis. Всё в одном. ИИ как интеллектуальный оптимизатор — он может выбирать стратегию хранения динамически, под конкретную нагрузку: колонку, граф, документ. Автоматическая эволюция схемы — ИИ мигрирует данные без участия человека, меняя вложенность и индексы под новые запросы. Код и данные вместе — ИИ пишет функции доступа к данным, оптимизируя их под физическую структуру текущего массива.
Собеседник А: Но есть и риски. ИИ не ясновидящий — оптимальная структура данных зависит от будущих запросов. Если нагрузка изменится, потребуется миграция терабайт данных — дорого и с простоем. Проклятие размерности — когда измерений становится много (десятки), даже ИИ не может гарантированно выбрать оптимальный порядок измерений и предсказать селективность запроса.
Собеседник А: Проблема доверия. Запрос «Найди всех мошенников» вернул пустой список. Почему? ИИ оптимизировал структуру под что-то другое? Ошибка в индексе? В текущих СУБД вы смотрите план запроса (EXPLAIN). В системе с ИИ объяснимость становится проблемой. И lock-in — библиотека эффективных функций, наращиваемая ИИ, создаёт проприетарную экосистему. Без ИИ данные прочитать нельзя.
Собеседник А: Вы описали будущее, которое возможно. Оно наступит, когда ИИ сможет надёжно объяснять свои решения по структуре данных, появятся стандарты для «интеллектуальных многомерных хранилищ», а человек перестанет быть контролёром и станет только постановщиком задач. Но сегодня — гибрид выиграет.
Собеседник Б: Для проблемы сложности и доверия нужно применять десяток базовых моделей, пример одной из них я описал выше, и они уже не похожи полностью на классические схемы. Они будут применяться ИИ исходя из поставленной человеком задачи. Даже если будет ошибка в выборе модели, ИИ намного легче перейти к другой модели, чем человеку.
Компромисс: базовые модели и эволюция
Собеседник Б уточнил свою позицию, и это полностью изменило характер дискуссии. Он предложил не один универсальный формат, а ограниченный набор базовых моделей, которые ИИ выбирает и комбинирует в зависимости от задачи:
- Плоская таблица — колоночное и строчное хранение
- Иерархическая — дерево, вложенные множества
- Графовая — узлы и рёбра с index-free adjacency
- Документная — агрегаты с вложенностью
- Временная — таблица с версиями, битемпоральная
- Векторная — для эмбеддингов и поиска по сходству
- Ключ-значение — для кэшей и сессий
- Очередь и лог — append-only, event sourcing
- Мультимодельная — комбинации вышеперечисленных
Многомерный массив становится «металлом», из которого ИИ «куёт» специализированные структуры. Эти модели становятся стандартами де-факто для данной предметной области, накапливаются в библиотеке, но при необходимости ИИ может быстро перестроить их в другую форму.
Собеседник А: Вы сделали очень важное уточнение, которое полностью меняет характер дискуссии. Теперь это не «многомерные массивы vs всё остальное», а эволюционный путь: от хаотичной гибкости к стандартизированным паттернам, управляемым ИИ. Я снимаю предыдущие возражения, которые били в «абсолютную универсальность».
Собеседник Б: Многомерный массив — это «металл», из которого ИИ куёт специализированные структуры данных под конкретную задачу. Человек работает с этими моделями на семантическом уровне, а не с массивами напрямую.
ИИ легче перейти к другой модели, чем человеку. Сейчас смена модели данных (например, с реляционной на графовую) — это месяцы работы. В системе с ИИ: решение принято, индексы перестроены, библиотека функций адаптирована. Человек продолжает писать те же запросы — семантический слой не меняется.
Архитектура будущего
В итоге участники диалога сошлись на таком видении:
| Компонент | Роль |
|---|---|
| Многомерный массив | Универсальное физическое представление (разреженный тензор) |
| Искусственный интеллект | Выбирает, комбинирует и мигрирует модели |
| Набор базовых моделей | Стабильные логические интерфейсы (таблица, граф, документ) |
| Человек | Задаёт цели, требования, проверяет результат |
Многомерные массивы как «металл» + ИИ как «кузнец» + библиотека стандартных моделей как «наковальня» — это жизнеспособная архитектура будущего для работы с данными. Это не утопия, а направление, которое можно начинать строить уже сегодня. Проблема не в принципиальной возможности, а в инженерной сложности и зрелости ИИ для принятия решений о моделях данных в реальном времени. Но направление — абсолютно правильное.