Ingres (INteractive Graphics and Retrieval System) - название научно-исследовательского проекта в университете Беркли в Калифорнии, в ходе которого были начаты эксперименты с реляционными базами данных. Можно предполагать, что совпадение названия с фамилией французского художника - Jean Auguste Dominique Ingres (1780-1867), говорит о любви участников к живописи и, может быть, намекает на те идеи, которые предполагалось воплотить. Технические решения СУБД Ingres вместе с достижениями экспериментальной разработки системы System R компании IBM составили фундамент современных реляционных СУБД.
Так называемый "University" Ingres, или BerkeleyIngres, Ingres89, "distributed" Ingres, что то же самое, фактически является оригинальной версией результата упомянутого выше проекта 1970-х годов. Эту программу можно получить бесплатно по Internet. Коммерческий продукт Ingres, ныне CA-OpenIngres, прошел большой путь развития и очень сильно отличается от своего предшественника.
Первые коммерческие версии были созданы и продвигались фирмой Relational Technologies, основанной Мишелем Стоунбрейкером (профессором университета Беркли в дальнейшем) - одним из участников проекта. Затем RTI была переформирована в Ingres Corp., которая через небольшой промежуток времени влилась в ASK Corp.
В начале 1990-х СУБД Ingres лидировала по своим техническим решениям. В это время она уже имела настраиваемый многопоточный сервер, расширяемый хранимыми процедурами, правилами, событиями и новыми типами данных, определяемыми пользователем; включала развитый оптимизатор запросов, работающий на основе статистических данных о распределении конкретных значений в колонках по диапазонам; поддерживала управление распределенными базами данных на основе протокола двухфазовой фиксации транзакций (two-phase-commit) с оптимизацией распределенных запросов и прозрачностью для пользователя (отсутствие необходимости знать, на каком компьютере находится таблица, к которой он обращается). Система позволяла использовать для таблиц структуры хранения Heap, Hash, Isam, B-Tree с возможностью установки параметров (например, процент начального заполнения страницы - fillfactor) и строить вторичные индексы со структурами Hash, Isam и B-Tree. Для таблиц и индексов существовала возможность определять стратегию их размещения на различных дисках. Параметры сервера настраивались для оптимального функционирования на различных платформах. Именно в Ingres впервые был использован язык четвертого поколения 4GL, а затем и Windows 4GL для разработки приложений с оконно-графическим интерфейсом, ставшие на сегодняшний день стандартом для разработки приложений на основе СУБД.
В 1994 г. ASK была приобретена компанией Computer Associates International, что вызвало перенос сроков выхода очередных версий с обещанной функциональностью, что, в свою очередь, послужило поводом говорить об увядании продукта. Тем не менее CA добавила СУБД новые возможности, сверх обещанных ASK, и выпустила две версии 1.1 и 1.2 продукта с названием CA-OpenIngres, объявленного одним из ключевых для компании на текущее десятилетие.
Ниже рассматриваются решения, имеющиеся в этих версиях, и тенденции развития, отразившиеся в анонсированной версии CA-OpenIngres 2.0.
1. Решения архитектуры сервера
CA-OpenIngres имеет многопоточную/мультисерверную архитектуру - сервер способен обрабатывать запросы от многих клиентов, имея для каждого свой поток (thread), при этом существует возможность запуска нескольких серверов, в том числе и на различных процессорах, для получения преимуществ SMP- и MPP-архитектур. Существует возможность адресовать конкретную задачу конкретному серверу, тем самым управлять балансом загрузки, определяя, какой сервер будет заниматься вводом данных, а какой - генерированием отчетов. Поиски CA путей повышения производительности продукта привели к перестройке архитектуры. Уже в версии CA-OpenIngres1.2 для Windows NT впервые использованы нити (threads) операционной системы для реализации потоков (threads) сервера, что позволяет существенно снизить накладные расходы и расширить возможности масштабируемости. В версии 2.0 такое решение реализовано на большем количестве платформ. Раньше, для того чтобы позволить различным процессам DBMS работать с одними и теми же данными, необходимо было обеспечить механизм синхронизации посредством ресурсов операционной системы - семафоров и разделяемой памяти. Подобная синхронизация может сильно замедлять обработку транзакций. В версии 2.0 один DBMS-процесс может использовать несколько процессоров машины. Новый DBMS-сервер, сервера, отвечающие за восстановление данных (recovery) и связь по сети (communication), могут использовать нити (threads) операционной системы. Поскольку последние могут работать на различных процессорах в едином пространстве процесса, существенно снижаются потребности в разделяемой памяти и семафорах.
Для операционных систем, не поддерживающих нити, CA-OpenIngres 2.0 поддерживает диспетчер распределенного кэша (Distributed Multi-Cache Manager) (DMCM). Подобное решение расширяет возможности Multi-Server Fast Commit Option (механизм быстрой фиксации транзакций), реализованной в предыдущих версиях CA-OpenIngres. DMCM разделяет кэш DMF (Data Manipulation Facility) на несколько - свой для каждого сервера. Затем DMCM использует ответы системы контроля блокировок для синхронизации кэшей различных серверов.
Реализация этих двух механизмов позволяет добиться максимальной масштабируемости системы в кластерных SMP- и MPP-архитектурах.
2. Управление данными
При выполнении SQL-запросов версии CA-OpenIngres до 1.2 устанавливают блокировки на уровне страниц. При обращении к большему чем некоторое n страниц системой может быть установлен захват на уровне таблицы. В версии 2.0 будет добавлена возможность устанавливать блокировки на уровне записей. Например, в задачах оперативной обработки транзакций, в которых затрагиваются всего несколько строк на странице, подобный подход существенно увеличил бы производительность. Выбор способа блокировок - на уровне страниц или на уровне записей делается приложением.
CA-OpenIngres 2.0 позволяет администратору базы данных определять размер страниц для таблиц и индексов. Если раньше размер страницы был 2K, то теперь он может быть 4,8,16,32 или 64K, что означает возможность оптимального выбора в соответствии с особенностями приложения. Страницы имеют новый формат данных, поддерживающий TID (Tuple IDentifier - число, одновременно включающее информацию о номере страницы и о номере записи на странице) размером в 64 бита, содержащий информацию для минимизации занимаемого деревьями (B-Tree) пространства, информацию для реализации блокировок на уровне записей, а также информацию, необходимую для выполнения операции изменения структуры таблицы (добавление и стирание колонок).
Версия 2.0 поддерживает асинхронный ввод/вывод при взаимодействии сервера с утилитами операционной системы, отвечающими за обращение к диску. Теперь, пока один поток (thread) сервера ждет завершения операций обмена с диском - все остальные продолжают работу. Это устраняет необходимость в специальных процессах ввода/вывода, решавших данную задачу в предыдущих версиях и, соответственно, в семафорах и разделяемой памяти, требовавшихся для синхронизации этих процессов с сервером.
3. Модель данных и синтаксис языка выполнения запросов
CA-OpenIngres поддерживает реляционную модель данных, т. е. хранит данные в таблицах, позволяя определять условия целостности путем определения диапазонов допустимых значений, а начиная с версии 1.1 поддерживает механизм декларативной ссылочной целостности, описанный стандартом ANSI SQL-92 Entry Level. Вместо написания правил и хранимых процедур вы можете воспользоваться опциями (FOREIGN...KEY) REFERENCES нового синтаксиса операторов CREATE TABLE и ATER TABLE, после чего при присваивании значения данной колонке будет проверяться наличие такого же значения в определенной колонке другой таблицы. Тем не менее у вас остается возможность использовать правила и хранимые процедуры, если хотите при нарушении целостности выполнять отличные от стандартных действия.
CA-OpenIngres поддерживает большую часть синтаксиса, описанного стандартом ANSI SQL Intermediate-level, плюс необходимое расширение, не входящее в этот стандарт, включающее функции для работы с типами данных "дата", "время", функции преобразования типов, статистические функции. Начиная с версии 1.1 поддерживается синтаксис для внешних соединений (outer joins) - левых, правых и полных, - позволяя определять как источник данных для оператора SELECT объединение нескольких таблиц по условию, и избавляет от необходимости для получения таких же результатов использовать конструкцию union/not exists.
В версии CA-OpenIngres 2.0 будет поддерживаться ANSI-стандарт команды ALTER TABLE. Появится возможность добавлять и убирать колонки из существующих таблиц базы данных. Изменения в архитектуре сервера сделаны таким образом, чтобы в последующих версиях возможно было изменять параметры существующих колонок.
За счет использования специальных (state-of-the-art) алгоритмов операция реструктуризации таблицы занимает доли секунды, независимо от количества записей в ней. Такое нововведение избавит от необходимости выполнять цепочку действий: выгружать данные, удалять таблицу, создавать таблицу с новой структурой и вновь загружать данные, что для таблиц, составляющих часть хранилища данных (data warehouse) и содержащих большой объем информации, может быть трудно выполнимо или невыполнимо вообще.
4. Расширения сервера
Функциональность сервера CA-OpenIngres может быть расширена за счет включения хранимых процедур, правил, событий и типов данных, определяемых пользователем.
Используя хранимые процедуры и механизм правил, разработчик может определить бизнес правила для своего приложения, переложив часть вычислений на сервер, что уменьшает нагрузку на сеть и упрощает кодирование. Правило срабатывает после выполнения операций INSERT, UPDATE, DELETE над записями в заданной таблице, при этом условие срабатывания может быть ограничено конструкцией WHERE SQL. Для одной и той же операции над заданной таблицей может быть определено несколько правил, которые могут вызывать одну и ту же или различные хранимые процедуры, состоящие из SQL-операторов, операторов присваивания значений локальным переменным и управляющих операторов. Хранимые процедуры могут вызывать друг друга, передавая параметры по определению и по значению, и быть вызванными не только по факту срабатывания правила, но и непосредственно оператором EXECUTE PROCEDURE. Процедуры могут генерировать события в базе данных, которые регистрируются приложениями, способными выполнить необходимые действия, например отправить сообщение по электронной почте или оповестить пользователей звуковым сигналом.
CA-OpenIngres позволяет определять новые типы данных, операции над ними и использовать их в операторах SQL. Определение нового типа данных заключается в определении его имени, размера, написании функций на языке C, компилировании их и сборки редактором связей некоторых модулей СУБД. За создание новых типов данных отвечает компонент OME (Object Management Extention).
Типы данных, такие как графические изображения, текстовые документы больших размеров, оцифрованные записи звука или видео, вообще говоря, могут храниться в базе данных, только разработчик должен сам позаботиться об адекватной обработке их приложениями.
Начиная с версии CA-OpenIngres 1.1 поставляются готовые библиотеки для работы с нестандартными типами данных - пространственными, векторными, временными рядами, - разработанные с использованием OME, например компонент CA-OpenIngres/Spatial Object Library позволяет работать с геометрическими объектами. В версии 2.0 для него введен индекс R-Tree, который для запросов типа: "Найти все объекты, пересекающиеся с заданным" более эффективен, чем использовавшийся ранее B-Tree.
5. Доступ к данным, межоперабельность
Компонент CA-OpenIngres/Enterprise Access включает шлюзы (Gateways) к СУБД других производителей: IBM DB2, Oracle, Informix, Sybase, Rdb, CA-Datacom, CA-IDMS, IBM IMS, Digital RMS, HP Allbase SQL, HP Image SQL, IBM VSAM, CICS VSAM. Поддерживается интерфейс OpenAPI, реализованный в виде функций на языке C, обеспечивающий доступ к CA-OpenIngres или базам данных других производителей через шлюзы. OpenAPI является альтернативой Embedded SQL, для использования которого необходим препроцессор. Преимуществом OpenAPI перед ESQL является то, что он функционирует в асинхронном режиме: после формирования SQL-запроса к базе данных управление передается прикладной программе. После выполнения запроса в приложении выполняется специальная функция, или же об окончании выполнения запроса можно узнать, периодически проверяя значение переменной статуса запроса. Можно организовать и синхронное выполнение, использовав возможность определять поведение для функции, при котором до ее завершения управление вызывающей программе не передается.
Вместе с OpenAPI CA-OpenIngres поддерживает стандарт ODBC, обеспечивающий доступ к данным CA-OpenIngres для приложений, работающих под управлением MS Windows (большинство средств быстрой разработки приложений OpenRoad, NewEra, Delphi, PowerBuilder работают под управлением MS Windows и поддерживают ODBC).
Компонент CA-OpenIngres/DTP (Distributed Transaction Processing) позволяет встроить СУБД как менеджер ресурсов в трехзвенную (three-tiered) модель технологии клиент-сервер. Это возможно за счет поддержки XA-интерфейса, позволяющего СУБД участвовать в обработке распределенных транзакций.
6. Средства тиражирования
CA-OpenIngres/Replicator - средство тиражирования информации, позволяющее поддерживать копии данных из исходной базы в нужных вам местах. Тиражировать можно как всю базу данных, так и ее объекты, например - таблицы, подмножество строк таблиц, отдельные колонки или комбинацию подобных объектов. Полный набор копий тиражируемых данных во всех базах данных имеет название CDDS (Consistent Distributed Data Set) - согласованный распределенный набор данных; он должен удовлетворять условию, что одни и те же копии данных не могут принадлежать различным CDDS. Вторым ключевым понятием является DPP (Data Propagation Path) - путь распространения изменений, определяющий геометрическую конфигурацию тиражирования. Возможны следующие основные конфигурации или их комбинации: центр-филиалы, равноправное, каскадное. Сам процесс тиражирования при этом может проходить как по схеме "равный с равным" (peer-to-peer), когда все изменения в одном узле передаются на другой и, наоборот, с контролем коллизий, так и по схеме односторонней передачи с доступом только по чтению. Процесс незаметен для конечного пользователя, репликатор получает всю необходимую информацию от сервера. Тиражирование происходит в асинхронном режиме, что удобно при медленных или ненадежных каналах связи, поскольку можно устанавливать различные режимы передачи данных, например: после определенного числа транзакций; через равные промежутки времени; к определенному моменту времени.
Для увеличения производительности и расширения возможностей масштабирования в CA-OpenIngres 2.0 механизм тиражирования изменен. Потоки, отвечающие за тиражирование, ведут специальные списки изменений данных и передают их вовне. Доступ к данным осуществляется на уровне DMF, при этом правила, события и процедуры, требовавшиеся в предыдущих версиях, не нужны, что облегчает администрирование. Механизм тиражирования встроен в сервер DBMS, и потоки репликатора могут теперь выполняться как нити (threads) операционной системы, что увеличивает производительность и возможности масштабируемости.
Механизм тиражирования реализован также и для легкого сервера CA-OpenIngres/Desktop, работающего на персональных компьютерах, что означает более широкий охват платформ и расширение возможностей комплексного решения CA.
7. Средства администрирования
Среди средств, позволяющих наблюдать за состоянием СУБД, стоит отметить утилиту IPM (Interactive Performance Monitor), имеющую интерфейс, основанный на алфавитно-цифровых формах, и позволяющую получать полную информацию о захватах (locking system), о состоянии системы регистрации транзакций (logging system), о запущенных серверах и об открытых сессиях.
Начиная с версии CA-OpenIngres 1.1 в СУБД реализована концепция IMA (Ingres Management Architecture). IMA позволяет наблюдать за значениями внутренних параметров сервера, такими, например, как параметры кэша DMF (Data Manipulation Facility), кэша QSF (Query Storage Facility) и потоков. Для доступа к данным необходимо создать таблицы оператором REGISTER TABLE, отобразив внутренние объекты сервера на колонки. К этим таблицам можно обращаться через SQL-запросы, что позволяет строить свои приложения, для наблюдения нужных параметров, с возможностью запуска их в том числе и с удаленных станций. На самом деле таблицы IMA никогда не существуют на диске, и при ответе на запрос к ним сервер предоставляет свою внутреннюю информацию.
Начиная с версии 1.1, CA-OpenIngres включает утилиту CBF (Configuration By Forms), имеющую, как и IPM, оконный алфавитно-цифровой интерфейс, позволяющую устанавливать параметры конфигурации сервера для настройки производительности.
Одновременно с CA-OpenIngres1.2 появилось имеющее графический интерфейс средство для администрирования баз данных CA-OpenIngres/VisualDBA, позволяющее решать такие задачи, как создание баз данных; создание объектов баз данных - таблиц, процедур, правил, событий; регистрация новых пользователей и установка прав доступа к данным; определение схемы тиражирования; выполнение процедур резервного копирования и восстановления; управление структурами хранения данных; выполнение операций сбора статистики для оптимизатора запросов о значении данных в таблицах.
Кроме всего прочего, СУБД может быть интегрирована с продуктом CA-Unicenter, который расширяет возможности архивирования и восстановления, а за счет использования механизма событий может наблюдать за критическими параметрами в нескольких удаленных инсталляциях CA-OpenIngres.
Важным для администраторов является поддержка в версии 2.0 операции быстрой загрузки неструктурированных (bulk) данных, существенно превосходящую по скорости использовавшийся в предыдущих версиях механизм за счет устранения задержек при передаче данных от клиента к серверу. В последующих версиях предполагается распараллеливание этой операции для SMP.
В версии 2.0 администратор баз данных имеет возможность делать копии (backup) и восстанавливать базу данных на SMP-машинах параллельно. В последующих версиях предполагается параллельная загрузка таблиц, имеющих структуру хранения, отличную от heap, и индексов.
8. Средства интеграции с Internet
В версии 1.2 реализован компонент CA-OpenIngres/ICE (Internet Commerce Enabled), позволяющий Web-клиенту выполнять SQL-запросы к базе данных, выполнять процедуры базы данных на сервере, передавая им параметры, а также запускать отчеты, написанные на языке ReportWriter и получать их результаты на WEB странице. Данные задачи решаются программой-сценарием, использующей CGI-интерфейс. Совсем недавно компания анонсировала планы интегрировать в CA-OpenIngres технологию Web-серверов компании Spyglass, производителя известного браузера Mosaic, что обещает существенное повышение производительности.
В версии 2.0 CA-OpenIngres/ICE поддерживает API Web-серверов компаний Netscape и Microsoft. Реализованы возможности автоматически помещать графические изображения из базы данных на HTML-страницу, поддерживается стандарт JDBC (Java database connectivity), реализована возможность автоматически создавать формы HTML на основе SQL-запросов.
9. Будущие планы
Основное внимание CA предполагает уделить реализации в следующих версиях механизмов паралелльной обработки запросов, паралелльного построения индексов и параллельной быстрой загрузки данных. Уровень технологии CA-OpenIngres и тенденции ее развития как высокопроизводительной системы для решений, требующих высокой степени надежности, определяет ее место в ряду наиболее развитых реляционных СУБД на сегодняшний день.
Олег Нагаев, REDLAB тел.: 146-0174