Что может быть общего между Виктором Глушковым и группой программ для управления базами данных под общим названием Постгресс?

Загорский Николай, г. Кельце, Польша. Перевод с украинского.

Из материалов конференции «Глушковские чтения» 2022 года.

Смерть Виктора Глушкова и рождение Постгресса разделяют несколько лет и несколько тысяч километров. Но, программно-инженерная мысль Стоунбрейкера,— основателя Постгресса,— как оказалось, имеет очень много общего с теми подходами, которые Глушков считал плодотворными для будущего.

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

Говоря словами из критики политической экономии, это тождественно тому, что текущий живой труд закладывает условия облегчению будущего живого труда, его совершенствованию и расширению, производству всесторонне развитых людей как творческих рабочих.

Как этот принцип относится к Постгрессу? Между нескольких наиболее известных и популярных систем управления реляционными базами данных (Oracle, PostgreSQL, MariaDB/MySQL, Firebird, SQLite, MS SQL, DB2) лишь архитектура и история Постгресса позволяют увидеть главные черты глушковской идеи. Постгресс был заложен как университетское исследование по архитектуре программ, управляющих реляционными базами данных. Главная идея заключалась в том, чтобы максимально отстраниться от какой-то определенной архитектуры баз данных и максимально применять модульный принцип, чтобы без полной перекомпиляции всех программ СУБД могла получать принципиально новые функции. Например, по умолчанию Постгресс предлагал пользователям определенный способ хранения данных в файлах, но они могли по аналогии написать свой модуль хранения и применять его рядом со стандартным или вместо него. То же самое касалось и типов данных. Стоунбрейкер разработал модульную систему, где каждый тип данных был реализацией нескольких определенных функций (операторов): преобразований из строки в строку, взаимных преобразований с другими типами, уравнения, арифметических действий (если они применимы) и прочего. Таким образом Стоунбрейкер изобрел для себя тот принцип программной архитектуры, который уже был известен Глушкову за несколько лет до того. Именно что, чем более динамичной и способной к изменениям является некая программная система, тем более она стабильна.

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

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

Добавление поддержки языка SQL в 1995 году, а, несколько позже, и поддержки многих человеческих языков в строках данных, и даже в названиях объектов,— вот главные шаги обусловившие популярность Постгресса за счет удачной модульной структуры СУБД. Эта модульность и дальше способствует развитию Постгресса. Например, в Оракл есть механизм, где из одной БД Оракл можно обратиться за данными, которые физически расположены в другой базе данных, но только чтобы она тоже была типа Оракл. В Постгресс, наоборот, были заложены модули оболочек внешних данных, позволяющие пользователям без программирования обращаться за данными в таблицах других, даже не обязательно реляционных, баз данных. В архитектурах других СУБД нет аналогов такого механизма, что имеет безусловное значение для формирования «единого информационного пространства» в случае преодоления коммерческих тайн.

От современности перейдем в историю и увидим, на чем Глушков планировал построить архитектуру хранения данных ОГАС. Вспомним известный принцип Глушкова: начать принцип учета, поочередно охватить им все заинтересованные организации на основе обязательной технической реализации и, впоследствии, объединить эту группу учетных данных с другими, которые тоже должны появиться раньше или позже. Эта логика, очевидно имеющая черты из произведений Бенедикта Спинозы, однако, не находит выразительной поддержки в спецификации КОДАСИЛ/CODASYL (далее Кодасил). О чем идет речь? СУБД «ОКА», которая, вместе с языком программирования ПЛ-1 планировалась как основа архитектуры хранения данных ОГАС, является иерархической базой данных. Это означает, что есть понятие о начальном узле и о том, что все данные хранятся по определённому адресу, примерно так как это делается в файловой системе, которая тоже является классической (в Униксах и Линуксах) иерархической базой данных.

Примерно так же как и в файловой системе мы можем договориться, что по определенному адресу хранится строка, а рядом будет файл с почтовым индексом, а рядом — с признаком «да/нет». Можем даже дописывать тип данных в специальных файлах, чтобы контролировать типизацию основных файлов данных. Но в этом процессе, который почти эквивалентен программированию хранения данных в файловой системе, никак нельзя увидеть логики Спинозы — предоставление общего принципа целостности еще до того, как начаты отдельные реализации архитектуры учета и хранения данных.

Направления Кодасил и СУБД «ОКА», в которой эта спецификация была образцовой, предлагали хранить каждому узлу данных отдельную типизацию в духе первых версий XSD описывающих типизацию в XML. Кстати, как раз XSD и XML до сих пор сохраняют главные черты иерархических баз данных со всеми их особенностями за исключением разве что транзакционности. Очевидно что для обобществления данных они непригодны, служа, в лучшем случае, его промежуточными агентами. Это касается не только программ на Кодасил и XML/XSD, но также новой пары — JOSN и JSONSchema. Во всех этих случаях труд по формированию схемы данных (ответ на вопрос «где что будет?») не является принципиально меньшим, чем труд по формированию именно данных.

В противоположность иерархическим СУБД, реляционные СУБД «действуют» по Глушкову.

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

В них данные преимущественно сами себе являются образцом, в то время как в реляционной модели данных все данные ограничены единым образцом (типизацией). Очевидно, что общественные идеи ОГАС гораздо легче находят реализацию именно в реляционной модели данных, которые, тоже не случайно, даже сейчас являются наиболее распространенными и популярными по сравнению с СУБД других моделей данных.

Идея автоматической фабрики, техническим развитием которой является серия проектов ОГАС, также предполагает экономию труда по программированию, о которой уже задумывался Глушков, имея образцом экономию труда по проектированию больших интегральных схем. За рамками очевидной реализации этой идеи в форме «банка программ» в «Центрпрограмсистеме» в г. Калинин, есть и другая форма проявления экономии этого труда по программированию, которая, опять же, наиболее заметна в отношении именно реляционных баз данных. Эта экономия наиболее заметна в СУБД именно «коллективных» реляционных баз данных из-за того, что программирование авторов СУБД как главная часть «образа совместной работы с данными» используется максимальное количество раз, в то время, как в конкретной сфере применения остается лишь отдельный проект структур данных, над которыми предполагается коллективная работа.

Не только такие широкие идеи Виктора Глушкова, как ОГАС, опередили свое время. Даже некоторые его инженерные и технико-архитектурные идеи его опередили.

Прошло примерно 50 лет с тех пор, как Глушков сформировал свои главные общественные, технические и исследовательские идеи. Энгельс считал, что ученые, не умеющие пользоваться диалектическим способом мышления в своей сфере, делают состояние науки отсталым как раз на те же 50 лет. И мы видим, что идея об использовании целокупных принципов для хранения данных, которая относительно ОГАС находила небольшую поддержку в тогдашней технике хранения данных — эта идея сейчас является ведущей в виде использования реляционных схем данных, которые должны существовать до первого заполнения, и более того, обуславливают порядок заполнения данных в разных таблицах, если применен инструментарий внешнего ключа. По оценкам, в 2019 году более 75% случаев применения баз данных в коллективной работе — это реляционные базы данных. В отдельной технической сфере — это триумф логики Спинозы, Гегеля и тех гегельянцев, последователем которых был Глушков.

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