Технология Клиент-Сервер 1999'2

Home Поиск Издания Контакты k-press.ru


Продолжается подписка на наши издания! Вы не забыли подписаться?

InterBase (IB-Database)

InterBase SQL Server разрабатывался и продавался фирмой Interbase Software Corporation (ISC). В соответствии со слухами, сотрудник DEC James Starkey, разработавший DSRI для Rdb, хотел расширить возможности Rdb, но его предложения были отвергнуты DEC. Поэтому он создал собственную компанию, разработавшую собственную RDBMS, первоначальное название которой было Groton Database System (GDS). Впоследствии ISC был приобретен Ashton-Tate, который, в свою очередь, приобрел Borland. InterBase как-то незаметен на фоне шумихи вокруг новинок Microsoft или Oracle - а напрасно.

Установка

Установка IB прошла очень быстро и не вызвала никаких проблем. На Win32-платформах инсталлятор IB имеет хороший графический интерфейс (InstallShield), а на UNIX-платформах - традиционный (для этих платформ) интерфейс командной строки. Хотя пользоваться графическим инсталлятором несомненно приятней, с точки зрения функциональности они идентичны.

Платформы и аппаратные требования

IB работает на платформах:

Естественно, что большинство пользователей использует IB-сервер на Win32-платформе.

Минимальной аппаратной конфигурацией для IB (по словам разработчиков) является 486DX2 66МГц. К сожалению, у нас не осталось такой техники, и проверить это заявление не удалось. На Pentium 120 с 64 Mb оперативной памяти сервер работал прекрасно (впрочем, это можно сказать и о других участниках обзора, попавших в этот номер).

Имеется также отдельный инсталлятор клиентской части. Он очень удобен и позволяет выбрать компоненты, необходимые для конкретной станции.

Первичное администрирование

В документации на IB то и дело упоминается простота администрирования. Главными предпосылками при этом являются маленькое количество опций настройки, отсутствие привязки к аппаратным особенностям (например – использования низкоуровневого обращения к аппаратуре (Informix, Sybase, Oracle)) и особенностям ОС (например – привязка к размеру страницы, используемой ОС (MS SQL Server)). Все это, конечно, приводит к упрощению администрирования, но в ущерб производительности и гибкости. Мне кажется, что путь, выбранный конкурентами IB:

путь более правильный.

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

Принимая во внимание то, что для нас в понятие “первичная настройка” входят и: создание БД, создание тестовых таблиц, заполнение таблиц данными, можно с уверенностью сказать – “первичная настройка потребовала от нас больше знаний и оказалась значительно сложнее, чем в случаях SQL Base и MS SQL Server”. Дело в том, что в поставку сервера входит практически единственная утилита, позволяющая производить администрирование IB. Чтобы не интриговать, скажу просто – это обыкновенный talker (утилита, позволяющая интерактивно исполнять SQL-запросы и просматривать их результат в консоли вывода). В принципе, есть еще программа InterBase Server Manager, позволяющая визуально сделать резервную копию БД и еще кое-что, но ее функциональность настолько мала, что считать ее серьезным средством администрирования нельзя.

Использование

Администрирование

Как уже было сказано со средствами администрирования у IB не густо. Если говорить прямо, это только talker (см. Рис. 1). Полное его название InterBase Windows Interactive SQL, но это уж очень длинно. Talker - короче.

talker как всё, всё, всё

Если talker является главным средством администрирования, так уж он должен являться очень удобным. К сожалению, это не так. Качество talker’а хотя и превышает командную строку, но совсем не дотягивает до его современных аналогов, не говоря уже о развитых средствах администрирования типа: Microsoft Enterprise Manager или Centura SQLConsole. talker IB даже неудобнее его конкурента от Centur’ы (хотя последний никак нельзя назвать удобным и гибким продуктом), и тем более уступает, не побоюсь этого слова, шедевру от Microsoft (редактор с подсветкой синтаксиса, графическое представление плана выполнения запроса…). В talker’е от IB невозможно даже изменить размер окна ввода SQL-выражений (в него влезает восемь SQL-строк), а стирание выполненной команды, и, как следствие, необходимость перебирать историю специальной кнопкой, довольно сильно раздражает. Шрифты, используемые в talker’е IB, изменить нельзя, причем используемые шрифты очень неудобны. Особенно неудобно в нем писать и отлаживать SQL.

Рис. 1 InterBase Windows ISQL

У InterBase Windows ISQL есть одно приятное достоинство. Он позволяет вывести метаданные для любого объекта БД или для всей БД в целом. У конкурентов тоже есть такая возможность, но запрятана она в глубины графической утилиты администрирования, а ведь нужна такая информация чаще всего при интерактивном взаимодействии с сервером.

На UNIX-платформах дела с средствами администрирования обстоят еще хуже. Здесь не нашлось даже графического talker’а, правда, в поставке имеются средства администрирования на базе Java-апплетов, но их мы так и не смогли запустить. К великому нашему удивлению, в поставке для Win32 эти апплеты попросту отсутствовали. Так что пришлось использовать ISQL (Interactive SQL – talker для командной строки). Использовать этот продукт было невыносимо неудобно, и мы (по совету представителей разработчиков) установили клиентские драйвера и утилиты на Windows-станцию. После этого проблем взаимодействия с IB-сервером не возникало.

Ну а насчет средств удаленного администрирования? talker несомненно является средством удаленного администрирования :-).

Утилиты администрирования независимых поставщиков

Но не все так мрачно. Упущения разработчиков IB с успехом исправлены некоторыми пользователями, так фирма Gimbal Software Services создала воистину замечательный продукт под названием Marathon.

Marathon 1.1 – великолепный инструмент для работы с БД IB (см. Рис. 2). Редактирует практически все объекты БД, содержит удобный редактор SQL-запросов, триггеров и процедур. Этот редактор поддерживает SQL Insight – всплывающее меню, позволяющее дополнить вводимое выражение. SQL Assist – автоматически вставляет в любой текст структуру таблиц или параметры вызова хранимых процедур по drag-drop. Встроенный анализатор запросов позволяет определить скорость выполнения запроса и выборки данных, план запроса, представляет в графическом виде статистику по выполнению запроса. Позволяет дописывать комментарий (документировать) любой объект БД (в т.ч. на русском языке). В нашем распоряжении оказалась пробная версия на 15 дней. Вы можете загрузить ее по адресу http://ib.demo.ru/Files/Marathon.zip.

Рис. 2 Marathon 1.1

Совместимость со стандартами

IB поддерживает синтаксис языка SQL, совместимый с начальным уровнем стандарта SQL-92 и некоторые возможности SQL 3. Так, IB поддерживает механизм ролей. Если говорить неформально, то можно сказать, что возможностей IB хватит для большинства применений.

Драйверы

  • ODBC – новый драйвер INTERSOLV ® DataDirect™ 3.11.01 реализует стандарт MS ODBC 3.0. Он быстрей и надежнее, чем его предшественник от Visigenic, но диалог настройки попросту приводит в растерянность. В нем нет отдельного поля для сервера (наверное, предполагается задавать его прямо в поле имени БД, но как это сделать, нигде не сказано). Новый драйвер поддерживает потоки и позволяет работать с символьными наборами IB.
  • JDBC – версия 1.5, поддержка русского языка на уровне properties в настройке драйвера
  • IB API – собственный формат. Предназначен для разработчиков на С/С++.
  • BDE – универсальный стандарт компании Inprise.

    • Расширения

    Внешние процедуры и функции

    Используя IB API можно создавать как внешние процедуры, так и внешние функции. В IB их называют UDF – User Defined Function. Напомню, что в контексте нашего обзора “внешняя процедура” - некоторая подпрограмма, написанная на любом внешнем (не встроенном в сервер) языке програмирования, оформленная в виде отдельного исполняемого модуля (например DLL или EXE для Win32), которую можно динамически подключить к серверу и вызывать отдельным вызовом из хранимых процедур или триггеров. “Внешняя функция” - то же самое, что и внешняя процедура, но может вызываться непосредственно из SQL-запроса, как встроенная функция.

    Главным ограничением UDF является то, что внешняя процедура не может возвращать набор строк (resultset).

    В поставке IB 5.5 имеется библиотека со “стандартными” (часто используемыми функциями) под названием ib_udf.dll и скрипт – ib_udf.sql, для регистрации функций в БД. В наших тестах мы использовали функции из этой библиотеки. Функции работали надежно и быстро, но в семье не без урода, так, функция RAND() (получение случайного числа) возвращала практически одинаковые результаты при вызове ее из хранимой процедуры.

    В принципе, UDF - это обыкновенные DLL-функции, и вместо того, чтобы писать свои, можно было бы воспользоваться уже готовыми (например mscrtxx.dll – стандартная библиотека от Microsoft), но при обработке строк и дат необходима специальная обработка, поэтому придется создавать собственные функции.

    Возможность использовать в запросе внешние источники данных

    Использование в запросе внешних источников данных в IB проблематично. Конечно, используя UDF, сделать можно практически все, но, согласитесь, сложность такого решения очень высока. По моему, проще воспользоваться услугами сервера приложений или попросту написать программу на одном из средств быстрой разработки (Delphi, VB).

    Пользовательские (хранимые) процедуры

    В IB создано процедурное расширение языка SQL. С его помощью можно писать триггеры и хранимые процедуры. К сожалению, элементы этого языка нельзя использовать при интерактивной работе, как это сделано в продуктах Sybase и Microsoft.

    В этом языке поддерживаются все основные операторы и лексемы, то есть операторы условного перехода, цикла и т.д. Этот язык смело можно назвать языком структурного программирования. С его помощью можно создавать процедуры, возвращающие resultset’ы. Интересной особенностью является то, что такую процедуру в дальнейшем можно использовать в SQL-запросах, как имя таблицы. В таком случае возвращаемый resultset будет интерпретироваться IB как полноценная таблица (или view).

    Есть еще некоторые накладываемые на этот язык ограничения. Так, в качестве типов параметров нельзя использовать домены (DOMAINS).

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

    Ниже приведен код процедуры, заполняющий таблицу TMR миллионом записей.

    CREATE PROCEDURE SP_Fill (StartRow INTEGER, QtyRowIns INTEGER)
/*Параметры в секции “RETURNS” возвращаются в виде строки
  resultset’а при вызове команды SUSPEND */
RETURNS (msg CHAR(50), RowProcessed INTEGER, CurRowNo INTEGER)
AS
/* Объявление переменных */
   DECLARE VARIABLE iCounter INTEGER;
   DECLARE VARIABLE iTo INTEGER;

   DECLARE VARIABLE F_INT1   INTEGER;
   DECLARE VARIABLE F_INT2   INTEGER;
   DECLARE VARIABLE F_VCHAR1 VARCHAR(250);
   DECLARE VARIABLE F_DEC1   NUMERIC(15, 3);
   DECLARE VARIABLE F_FLOAT1 FLOAT;
   DECLARE VARIABLE F_DATE1  DATE;

BEGIN
   /* Начальная инициализация */
   iCounter = StartRow;
   iTo = iCounter + QtyRowIns;
   /*Основной цикл*/
   WHILE (iCounter < iTo) DO
   BEGIN
      /* Инициализация вводимой строки */
      F_INT1 = iCounter;
      F_INT2 = 12345 + iCounter / 4;
      F_VCHAR1 = CAST(iCounter as varchar(50)) || " test";
      F_DEC1 = iCounter + iCounter / 1000;
      F_FLOAT1 = iCounter + iCounter / 2000;
      F_DATE1 = cast("NOW" as DATE) - iCounter;
      /* Непосредственно добавление строки в таблицу БД */
      INSERT INTO TMR ( F_INT1,  F_INT2,  F_VCHAR1,  F_DEC1,  F_FLOAT1,   F_DATE1)
               VALUES (:F_INT1, :F_INT2, :F_VCHAR1, :F_DEC1, :F_FLOAT1, :F_DATE1);
      /* Вывод сообщения о прогрессе (без него с успехом можно было бы обойтись)*/
      IF ( (mod(iCounter - StartRow, 1000) = 0) OR (iCounter = (iTo - 1))) THEN
      BEGIN
        msg = "Message ...";
        RowProcessed = iCounter - StartRow;
        CurRowNo = iCounter;
        SUSPEND; /*эта строка предполагала вывод информации в окно IB 
                   Windows ISQL, но до завершения всего ввода ни одна
                   строка не была выведена на экран. Скорее всего в 
                   этом виноват IB Windows ISQL. */
      END
      iCounter = iCounter + 1;
   END
END

    Введение новых типов данных и расширения SQL

    IB поддерживает механизм доменов, позволяющий создать тип с ограничениями (например - >0 и <100), но не позволяет создать совершенно новый тип (с методами, атрибутами, в общем, с нестандартной структурой и с возможностью расширенной обработки этого типа), как, например, это можно сделать в Oracle и Informix.

    В IB также невозможно расширение SQL. Хранимые процедуры и триггеры в IB можно писать только на встроенном языке.

    Подытоживая вышесказанное, можно с уверенностью сказать: IB не поддерживает никаких объектных расширений.

    Подсистемы

    Оптимизатор запросов и исполняющая подсистема

    IB имеет давнюю историю, он начинался еще на DEC’ах и его оптимизатор претерпел немало модификаций. Честно говоря, до оптимизатора Oracle 8 или MS SQL Server 7.0 он явно не дотягивает, хотя и значительно превосходит оптимизатор Centura SQLBase 7.1 и, наверное, немного превосходит оптимизатор MS SQL Server 6.5.

    Так, наш тест на соединение (JOINS) 31 таблицы по принципу “звезда” (одна главная и 30 подчиненных таблиц) он выполнил за 1 минуту 35 секунд. Поскольку ни в одной таблице не было более 2-х записей, а resultset состоял из 2-х записей, можно с уверенностью сказать, что все время было потрачено на оптимизацию запроса. SQLBase вообще не справился с 30-ю таблицами, и результаты IB можно признать удовлетворительными (для справки - MS SQL Server 7.0 выполнил этот тест за 3 секунды).

    Положительной чертой можно признать и то, что при повторном выполнении такого же запроса IB работает молниеносно. По видимому, используется план, сделанный для предыдущего запроса. К сожалению, мы не успели попробовать выполнить скомпилированный (prepared) параметризованный SQL-запрос, но, судя по всему, IB должен отлично справиться с этой задачей.

    Работа с таблицами, содержащими большое количество записей (в наших тестах мы использовали таблицу с одним миллионом записей), тоже не является коньком IB. Но тут не все так просто, как в случае с многотабличным запросом.

    Начнем по порядку.

    Отладка хранимых процедур и триггеров

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

    Средства разработки

    Хотя непосредственно с IB никаких средств разработки не поставляется, количество отдельно поставляемых средств разработки как минимум не меньше, чем у его самых удачливых конкурентов. IB API и ODBC открывают перед разработчиками возможность создавать приложения практически на любом языке программирования. Возможно даже использование IB из скриптовых языков, таких как VBScript и JScript, но, правда, не напрямую, а через ADO или RDO (OLE Automation-совместимые компоненты доступа к данным фирмы Microsoft). Скорее всего, высокой производительности от IB в этом случае получить не удастся, так как и ADO, и RDO будут работать через ODBC (совместимость всегда требует в жертву производительность). На вопрос, какие же языки и среды разработки могут претендовать на звание доминирующих при разработке для IB, можно уверенно ответить: это Delphi, C++ Builder, J Builder и другие средства разработки от Inprise. Почему? Потому, что хотя InterBase Software Corp. и является отдельным юридическим лицом, она все же очень тесно связана с Inprise (напомню, что Inprise - это всем известный Borland).

    Связь с серверами приложений и другими продуктами

    Главный козырь Inprise (о ее роли в судьбе IB уже говорилось ранее) - серверы приложений и инфраструктура, необходимая для создания распределенных приложений. Этой компанией разработаны такие продукты, как Inprise Application Server, основанный на брокере объектных запросов Inprise VisiBroker (CORBA/IIOP Object Request Broker), и MIDAS (Multi-Tier Distributed Application Services), основанный на COM . Естественно, что IB прекрасно интегрируется с ними.

    Через ODBC (напомню что новая версия ODBC поддерживает многопоточность) IB можно использовать с большинством серверов приложений (например, с Microsoft Transaction Server).

    Устойчивость к аварийным ситуациям

    Транзакции

    В отличие от большинства баз данных, IB не хранит лог отмены транзакций. Вместо этого он использует версии записей для конкурентного доступа, для неизменяемого представления данных, и для восстановления.

    Когда происходит обновление (update) записи, IB вычисляет разницу между новой и старой версиями записей и сохраняет разницу (возможно, на той же странице, где и старая версия записи, или на другой странице, если в текущей не хватает места). Затем IB заменяет оригинальную запись новой версией и создает указатель на старую версию записи (back version). Главная версия записи содержит идентификатор транзакции (например, 27). Старая версия тоже содержит идентификатор создавшей ее транзакции (например, 13).

    неизменяемое представление данных - Существующие (активные) транзакции читают старые версии записей, если эти транзакции не типа read-committed (которые должны иметь возможность читать новую версию записи после подтверждения транзакции (commit)). Транзакция 17 будет продолжать читать версию, созданную транзакцией 13. Транзакция 35 будет читать версию, созданную транзакцией 27 - если, конечно, транзакция 27 завершилась подтверждением (commit).

    Восстановление - если транзакции не удалось завершиться подтверждением (например, приложение зависло), или был выполнен Rollback, то следующая транзакция, читающая запись, вернет старую версию записи на ее прежнее место. Этот процесс называется кооперативным восстановлением. Если транзакция 27 завершится отменой (rollback), то следующая транзакция при прочтении этой записи вернет версию, созданную транзакцией 13.

    Конкурентный доступ - транзакция 17 не сможет изменить запись, если для этой записи есть новая версия, созданная транзакцией 27. Это предотвращает взаимную отмену изменений между конкурирующими транзакциями.

    Изменение индексов - при изменении значения поля, по которому есть индекс, индекс обновляется. Если поле не изменилось, то и индекс не меняется - при условии неизменности расположения записи (db-key).

    Многоверсионная технология IB с одной стороны позволяет:

    Но с другой стороны:

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

    Поддержка русского языка

    IB Database обеспечивает хранение и обработку данных в различных национальных кодировках. Поддерживаются как однобайтовые, так и многобайтовые наборы символов для всех операций со строками. Поддерживаемые наборы символов включают UNICODE, ASCII, кодовые страницы DOS (включая 866 - CYRL), кодовые страницы Windows (включая WIN1251) и EUC. Для базы данных может быть указан набор символов по умолчанию, переопределяемый для любого строкового поля таблицы. Специальные наборы сортировок позволяют учитывать особенности сортировки национального алфавита (например PXW_CYRL). Никаких дополнительных инструментов для поддержки национальных кодировок не требуется.

    Правда, вся эта красота на практике разбавляется некоторым количеством ошибок и упущений, но их можно успешно обходить, изучив материалы на ib.demo.ru/DevInfo/0109.htm. Стоит заметить, что от неурядиц с русским языком страдают многие серверы БД.

    Некоторые возможности

    поля типа "массив" - разработаны по просьбе анонимной самолетостроительной компании (район Сиэтла). По техническому заданию компании требовалось хранить данные, получаемые единовременно с большого количества датчиков, в БД, и обрабатывать эти данные по горизонтали и по вертикали. В настоящее время этой уникальной возможностью InterBase SQl Server с успехом пользуются самолетостроительные, исследовательские компании и финансовые биржи.

    каскадные триггеры - позволяют разбивать на отдельные части логику обработки вставки, изменения и удаления записей. Фактически каскадные триггеры позволяют реализовать "процедурное программирование" обработки данных, допуская изменение порядка выполнения триггеров и отключение/включение триггеров "на ходу".

    фильтры полей типа blob - пользовательские процедуры (UDF), подсоединяемые к операциям чтения и записи данных в поля blob, и позволяющие осуществлять преобразование данных "на ходу", упаковку/сжатие данных и т.д. Для каждого подтипа blob могут быть написаны свои фильтры.

    Резюме

    В заключении можно сказать, что IB Database версии 5.5 - это достойный, хотя и ничем не выделяющийся продукт. Ему необходимы графические средства администрирования и устранение мелких, но досадных недочетов. Несомненно, в будущих версиях это будет исправлено - по крайней мере, хочется на это надеяться. Относительно низкая цена при вполне приемлемой производительности позволяет использовать этот продукт как stand-alone SQL-сервер, так и в связке с другими серверами.

    В.Чистяков

    Copyright © 1994-2016 ООО "К-Пресс"