QBE, встроенный в СУБД

В силу случившегося со мною в жизни возможно первым дам аргументированный ответ на вопросы:

   Почему в конце XX века в Японии с многомиллиардными убытками был провален проект ЭВМ 5-го поколения на основе физической (процессоры и др.) реализации реляционных баз данных (БД), баз знаний и др?

  Что потеряли при этом все мы и тем более в условиях, когда современные ЭВМ подошли к пределу миниатюризации и быстродействия (ограничение скорости света), оставаясь по-прежнему в рамках исходной (40-годы XX века) модели фон Неймана - чисто последовательных вычислений?

   Почему это особенно чревато для персональных ЭВМ, по-прежнему ограниченных структурой Intel?

История

 1) Горбачевская перестройка вынудила крупные предприятия освобождаться от больших (мэйнфреймы) ЭВМ ЕС-50 и выше в силу затрат на ремонт и электропитание, площади. Потому встала проблема переноса задач с мэйнфреймов на `Персоналки`, тогда еще Intel 386/486. В первую очередь это коснулось ежедневно решаемой сложной задачи оптимальной комплектации изделий поступающими на сборку узлами и деталями на основе планов предприятия, цехов. Такую задачу на машиностроительных предприятиях бывшего СССР (Брянск, Людиново и др.) сопровождал целый отдел (порядка 50 сотрудников) Луганского ПТИМаш на основе многотомного проекта , приобретенного задолго до этого в Орле. Метавселенная ВДНХ 2.7 т

В перестройку в отсутствие денег (расчеты бартером) Людиновский машзавод предложил отделу ПТИМаш деньги для переноса этой задачи на персональную ЭВМ. Отдел бездумно согласился и… НЕ смог даже начать работу, через полгода и руководство институтом предложив это решить мне. – Первая моя реакция: Я объявил отдел безответственным, а задачу - НЕ решаемой на основе архитектуры Intel: отсутствие единого адреса ячейки оперативной памяти и каналов – отдельных процессоров, параллельно с вычислениями (основной процессор) перемещающих много КБ блоков и др. Тем НЕ менее согласился на эксперимент: попытаться оптимизационный процесс комплектации изделий и узлов прокрутить хотя бы за 5 часов на Intel/486 вместо 25 минут ЕС-55. При удаче (во что заранее НЕ верил!) соглашался взять решение всей задачи (в комплексе) на себя

 2) Даже на ЕС ЭВМ оптимальная комплектация изделий решалась поэтапно раздельно по цехам предприятия и в условиях отсутствия на Intel/486 мощных стандартных средств (программ) сортировок и слияния нужно было искать принципиально другие решения. От использования КЭШ UNIX даже версии Беркли, как панацеи, пришлось сходу отказаться. И тут я впервые обратился к реляционным алгебре и СУБД как механизмам параллельной (групповой) обработки строк таблиц (данных) на языке запросов к СУБД - решение задачи потоком запросов (queries): перенести нагрузку с относительно медленного винчестера на Процессор и оперативную Память. К этому времени машиностроение уже осваивало Paradox 3.5-4.5 для MS DOS и в этой среде мне предоставили образец БД изделий и узлов порядка 20 тысяч и около 60 тысяч деталей. Первая же попытка составить и запустить связный (к узлам и деталям одновременно) запрос к этой БД в языке QBE привела в ужас: после 1.5 часов бесплодного ожидания ЭВМ пришлось отключить на ходу. Предстояло разобраться в проблемах – стандартах оптимального конструирования как реляционных БД, так и самих запросов и их потоков, сложных вычислений в рамках языка запросов, включая интерполяцию и экстраполяцию, разузлование изделий. В итоге через 2 месяца напряженнейшей работы удалось время оптимизационной части (процесса) на Intel/486 ограничить 4 часами. Более 80% этого времени занимал последний уже относительно простой этап доукомплектации с нерегулярной структурой алгоритма, вынуждавший этот этап решать уже старыми приемами вне потока Queries – обычной поочередной обработкой строк реляционных таблиц (кортежей). Позднее обнаружил неточности в алгоритме доукомплектации, снятие которых сделало этот этап (алгоритм) регулярным с возможностью реализации потоком запросов: время решения задачи сократилось до 40 минут, что казалось невероятным.

 3) Журнал `К+П` № 5 (Май 1995 г., Киев) на `первой полосе` опубликовал результаты этой задачи в виде тестов - отдельных весьма поучительных QBE-запросов (Paradox 3.5-4.5) над той же БД Людиновского маш.Завода сравнением с идентичным решением в Local SQL FoxPro 2.0. По мере усложнения запросов FoxPro 2.0 `выдохся`, отказавшись их выполнять (завис), в то время как Paradox’ы продолжали работать как ни в чем НЕ бывало. В редакцию журнала посыпалась лавина писем возмущенных фанатов FoxPro 2.0, традиционно НЕ использовавших Local SQL и вместе с тем заподозривших меня в чем угодно, кроме главной истины: за фасадом тестов предлагались стандарты реляционной технологии решения задач на персональной ЭВМ – как метода переноса сложных задач АСУП с дорогостоящих мэйнфреймов на персоналки.

 4) Ровно через год в том же № 5 журнала `К+П` некто М. Виноградов, похвалив мою работу, сообщил, что уж теперь с появлением мощных SQL-серверов предложенное решение задач АСУП потоком Queries обеспечивается автоматически этими серверами. Тогда я принял это, наивно полагая, что любой реляционный СУБД эффективно (как и Paradox для MS DOS) решает проблемы переноса нагрузки с винчестера на процессор эффективной организацией буферного пула. Лишь через 5 лет решил проверить на практике корректность этого вывода. Теперь проще: Взял исх. реляционную таблицу чисел от 0 до 9 (строк). Из нее автоматически запросами сгенерировал случайным образом связные между собой (индексы) также чисто числовые таблицы (4-5 реквизитов в строке) в 1000, 10000 и 100000 строк. Затем организовал набор тестов в виде различных многотабличных (связных) Queries к этой БД, часть из которых включала и группирование (group by). К моему изумлению эмулируемый в среде Windows 16-и-битовый Paradox 4.5 для MS DOS, использующий всего 16 МГб оперативной памяти, опередил (время выполнения) в 200-300 раз SQL-серверы Interbase, MSQL (SQL-2000) и даже PostgreSQL (Linux). Точно также он обошел своего потомка Paradox 6/7 для Windows: из него (по не пониманию) изъяли сердце – встроенный QBE, заменив на Interbase, тем самым фактически похоронив Paradox. Эти тесты с возможностью их проверки буквально в течении часа направил экспертам той же редакции `К+П`. – В ответ последовал отказ: `Этого НЕ может быть, потому что НЕ может быть!` - Жираф (SQL-сервер) БОЛЬШОЙ (В. Высоцкий)!. – Стало очевидным: Мы давно уже живем в `Матрице`

 5) Пару лет назад повторил, усложнив тесты (исх.таблица теперь от 0 до 19 и последняя - порядка 1 млн строк), противопоставив в них все тот же Paradox для MS DOS современному Oracle 9i: может все это (см.выше) мне приснилось! Но УВЫ! – В этих тестах старенький предельно ограниченный ресурсами Paradox сохранил преимущество, правда, только в 4 раза. При этом Oracle 9i сожрал все ресурсы моего современного Pentium.

Ответы на вопросы

 1) Главная причина невероятной эффективности Paradox для MS DOS в плане оптимизации времени обработки данных кроется во встроенном QBE: запрос строится (структура) от данных к связям и отношениям между ними, а не наоборот, как в SQL. Дополнительные отсутстствующие в SQL возможности:
  - автоматически формируемые при выполнении QBE-запроса рабочие таблицы Answer, Inserted, Deleted и др., далее эффективно используемые в том же потоке запросов
  - одновременное выполнение в одном запросе нескольких различных операций в отношении различных таблиц , включая insert, delete и update

 Попутно удалось выяснить возможности QBE, существенно превосходящие возможности SQL.- В виде развлечения одним QBE-запросом мне удалось как-то получить из рассмотренной ранее (тесты) таблицы с 0-9 таблицу умножения Паскаля (задняя обложка школьной тетрадки). На предложение перевести этот запрос в SQL СУБД Paradoх 9 ответил отказом, переводимом с англ. примерно как: `Слишком много хотите!`

P.S. Похоже, не случайно автор реляционной алгебры проф.Кодд считал язык SQL НЕ соответствующим реляционной технологии.

 2) Сложная задача комплектации изделий решалась потоком примерно из 800 QBE-запросов, легко читаемых даже не специалистом в области программирования с объемом текста меньшим в 20 раз, чем программы для той же задачи на ЕС ЭВМ.

 3) Помимо встроенного QBE – безусловно сердца Paradox вызывал восхищение и механизм связных форм (Linked Forms): не взирая на ограниченность их связей двумя уровнями (Master-Slave) быстродействие в переходе по отображаемой формой (интерактивно) связям почти на порядок превышало аналогичное действие оператора Locate, выполняющего то же в программе. Впрочем хорошему программисту не сложно было отобразить многоуровневую структуру связей в реальной форме на ограничиваемую Paradox двухуровневую, обойдя это ограничение. В значительной мере эта эффективность обеспечивалась размещением экранных форм, как и данных в том же буферном пуле СУБД

 4) Как и UNIX (Linux), Paradox был программируемым на всех уровнях, включая генерацию экранных форм, форм отчетов и даже QBE-запросов и их обработку. Это позволяло генерировать потоки QBE-запросов в той же задаче комплектации изделий, еще многократно сокращая тексты (2) программ. Пакет программ задачи комплектации изделий НЕ содержал QBE-запросы (их описания), но генерировал их в потоке Queries, как и сам поток. Это же свойство Paradox позволяло создавать генераторы его Приложений в его собственной среде

 5) На возможностях Paradox 4.5 для MS DOS в генерации (программируемости) QBE-запросов, экранных форм и форм отчетов мне удалось построить реляционный бухгалтерский калькулятор, позволяющий бухгалтеру самому определять объекты, их группы, свойства и буквально в несколько привычных для него фраз (словарь) задавать вычисления для множеств объектов. Каждая такая фраза незаметно для бухгалтера генерировала 1-4 QBE-запроса, выполняемых с максимальным быстродействием. Так испытание показало сокращение затрат и машинного времени для начисления зарплаты сотрудникам ПТИМаш (порядка 1200 чел) почти в 500 раз в сравнении с официально действующей программой в среде FoxPro 2.

 6) Опыт выше определил причину провала японского проекта ЭВМ 5-го поколения: Преждевременность проекта – отсутствие мирового опыта в построении специализированных реляционных процессоров типа (5)на основе эффективных решений встроенного QBE и прочих средств их генерации. - Paradox для MS DOS оказался уникальным и до конца НЕ понятым решением: первые его версии были ориентированы непосредственно на инженеров и экономистов. Как и многие прочие уникальные решения, включая UNIX, он оказался погребенным коммерческими амбициями фирм типа Microsoft.

 Понятно, что в силу почти достигнутого ограничения скорости света и минимальных размеров микросхем рано или поздно нам придется вернуться к, надеюсь, НЕ безвозвратно утерянным решениям, включая QBE, встроенный в СУБД, и средствам генерации QBE-запросов.