© Дмитрий Кузьменко,
директор ООО "Айбэйз" ,
Евгений Даниленко,
независимый эксперт
© Статья была опубликована в журнале «BYTE/Россия» ,
№6/2003
Наибольшее распространение сервер баз данных InterBase получил в 1995 г., когда разработчики приложений начали работать с Delphi 1. InterBase размещался на одном компакт-диске с Delphi, по объему занимал четыре дискеты и устанавливался за несколько секунд, после чего был полностью готов к работе. Отсутствие необходимости в настройке, надежность, совместимость со стандартом ANSI SQL, хорошая производительность и высокая функциональность сделали InterBase весьма популярным в нашей стране.
При разработке InterBase в код был встроен мощный функциональный и алгоритмический потенциал. Наиболее известны первые коммерческие реализации BLOB и two phase commit. Не претендуя на полноту, приведем перечень технологий InterBase, которые используются практически во всех типах прикладных задач.
В InterBase имеет место одна из наиболее удачных коммерческих реализаций безблокировочной работы с записями. В общепринятом смысле в InterBase блокировки отсутствуют целиком. Это позволяет разработчику сосредоточиться на решении прикладной части задачи, облегчая обработку конфликтов при многопользовательском доступе к данным. Например, модификация данных не мешает их чтению в конкурирующих транзакциях. Соответственно, нет простоев, которые неизбежны в блокировочных серверах при использовании аналогичных уровней изолированности транзакций.
При разработке приложений важно учитывать, каким образом разработчику предоставляется механизм транзакций и каким образом транзакции влияют на многопользовательский доступ к данным.
В InterBase существует два основных типа транзакций, Read Committed и Repeatable Read. Причем второй уровень изолированности - более "жесткий", чем аналогичный в ANSI SQL92, и не допускает "фантомных записей". Оба типа транзакций имеют ряд параметров, в том числе параметр wait, который позволяет или получать сообщения о конфликтах блокировок немедленно (no wait), или ждать разрешения конфликтов блокировок (wait).
Кроме упомянутых типов транзакций, в InterBase есть возможность блокирования таблиц целиком, и с ее помощью имитируется сериализуемая обработка данных - например, можно редактировать справочники в монопольном режиме, разрешив другим транзакциям только их чтение.
Клиентское приложение может подписаться на уведомления о событиях, которые могут возникнуть в процедуре или триггере при их выполнении. При этом допускается как синхронное, так и асинхронное ожидание событий. Приложению не требуется периодически опрашивать сервер - он сам сообщит конкретному "клиенту" о том, что интересующее событие произошло.
Триггеры срабатывают при операциях insert/update/delete немедленно (пессимистическая стратегия), причем могут выполняться как до операции, так и после нее (before/after). На одно и то же действие допустимо создавать несколько триггеров, которые могут быть включены и выключены, а также содержать отдельные части бизнес-логики (разделение кода по триггерам). При этом допускается рекурсивный вызов триггеров, т. е. триггеры могут обновлять таблицы, на которых они срабатывают.
На рис. 1 приведен пример распределения обработки операций над записями при помощи нескольких триггеров и последовательность выполнения таких триггеров.
Рис. 1. Распределение обработки операций с записями при помощи триггеров.
В клиентской части сервера содержится ряд функций, при помощи которых можно одновременно и полноценно управлять любым количеством серверов - изменять конфигурацию сервера, управлять пользователями, резервным копированием, получать статистику, проверять базы данных на целостность. Функции имеют удобный интерфейс, и их можно "обернуть" в классы любым объектно-ориентированным языком программирования, как это сделано в Delphi и C++Builder (закладка InterBase Admin в палитре компонентов, рис. 2).
Рис. 2. Закладка InterBase Admin в палитре компонентов.
Большинство инструментов третьих фирм для InterBase (см. врезку) используют этот набор компонентов, предоставляя полноценное управление любым количеством серверов с одного рабочего места.
Сейчас этим мало кого удивишь, но в InterBase UDF поддерживаются уже давно. Их можно писать на любом компилирующем языке программирования, который может создавать dll- или so-модули. В настоящий момент можно назвать пять наиболее обширных библиотек UDF, в состав которых входит от 50 до 200 функций обработки строк, дат и времени, вычисления выражений, обработки blob и т. п. Есть и отдельные наборы для перекодировки строк, работы со случайными значениями, перевода чисел в текст и т. д.
Необходимо отметить, что с выпуском Borland Kylix стало можно использовать все богатство сторонних UDF, написанных на Delphi, и под Linux.
Вопреки самому популярному мифу об InterBase (а их несколько), исходный код изначально был написан для Unix, и версия 3.3 выпускалась для 15 вариантов Unix, включая различные аппаратные платформы (DEC, IBM/RS, Solaris SPARC и т. д.). В 1994 г. была выпущена версия для Microsoft Windows, причем последующие версии для этой платформы могли работать со всеми ее вариантами, включая Windows 95, 98 и NT. К настоящему моменту список поддерживаемых платформ сократился до трех наиболее распространенных - Windows, Linux, Solaris/SPARC (сертифицировано пять самых популярных вариантов Linux, включая Red Hat и SuSE). Между версиями для различных платформ нет никаких различий, т. е. сервер работает совершенно одинаково, независимо от платформы. Это гарантирует прозрачность смены серверной операционной системы и аппаратного обеспечения для пользовательских приложений.
Поскольку InterBase поддерживает многоверсионность записей, выполнение резервного копирования при работающих пользователях - это штатная операция.
Смену платформы или просто перенос базы данных с одной платформы на другую рекомендуется выполнять при помощи backup/restore. Поскольку файл базы данных - это файл произвольного доступа, то его копирование (через copy или xcopy) в момент работы пользователей может привести к тому, что полученный файл-копия базы данных окажется испорченным.
Автоматизация резервного копирования возможна при помощи сервисов операционной системы (at или cron) и утилиты командной строки GBAK либо с использованием инструментов третьих фирм, например, GbakScheduler, IBBackupScheduler и других.
Эти обозначения указывают на различия в архитектуре сервера, выпускавшегося для разных платформ до версии 7.
Версия Classic построена по старой схеме пользователь-процесс, которая берет свое начало из времен, когда в среде Unix не было стандартной модели threads. Это вполне надежная схема, так как пользователи работают с сервером в разных процессах, но большой ее недостаток - существенное потребление памяти из-за невозможности организации разделяемого кэша данных и метаданных. Для достаточно сложных баз данных клиентскому процессу могло потребоваться 35 Мбайт памяти. Умножьте это число на количество одновременно работающих пользователей, и вы получите объем RAM, который необходимо установить на сервер.
SuperServer, напротив, имеет общий кэш данных и метаданных и требует существенно меньше ресурсов при работе с тем же количеством пользователей. Однако предыдущие версии SuperServer могли полноценно использовать только один процессор на многопроцессорных машинах. Поэтому при разработке версии 6.0 было решено избавиться от проблем с одновременным сопровождением двух архитектур и оставить SuperServer как наиболее перспективную, в дальнейшем усовершенствовав ее для работы на многопроцессорных компьютерах.
Версия 7.0 переработана для полноценного использования всех процессоров компьютера и обеспечивает корректное распределение нагрузки между приложениями OLTP и OLAP. Как и в предыдущих версиях, при помощи параметра CPU_AFFINITY (битовая маска) можно указать, какие именно процессоры InterBase 7 должен использовать для работы, но это имеет смысл делать лишь в случае размещения сервера приложений или другого ПО на той же машине, с тем чтобы InterBase гарантированно использовал только часть всех доступных процессоров компьютера.
Для управления производительностью добавлен параметр MAX_THREADS в IBCONFIG - администратор системы может заранее определить максимальное количество потоков, используемых сервером. Для конкретных задач это число определяется экспериментально, и в общем случае оно должно минимально соответствовать количеству пользователей системы.
Если работать с InterBase 7 как с однопользовательским сервером, то параметр max_threads необходимо установить равным 1. Благодаря этому использование ресурсов клиентского компьютера будет минимальным.
Во время работы сервер хранит разнообразную информацию о выполнении запросов, занимаемой памяти, количестве чтений данных и т. п. Однако для разработчика была доступна только часть такой информации, и для ее получения необходим был InterBase API.
В InterBase 7 введены временные системные таблицы, т. е. информация практически обо всех структурах сервера доступна при помощи обычных sql-запросов. Данные этих таблиц не хранятся на диске, а лишь представляются для запросов в виде взаимосвязанных таблиц.
Каждая временная таблица предоставляет список объектов определенного типа - базы данных, таблицы, процедуры, соединения пользователей, транзакции, память, но столбцов у этих таблиц много, и в результате можно получить практически любую информацию о происходящих на сервере событиях. Например, это может быть список 10 наиболее длительно выполнявшихся запросов, количество операций ввода-вывода (дисковых) для всех соединений, количество обновлений данных конкретной таблицы и т. д. (рис. 3). Объем получаемой информации и ее интерпретация зависят только от фантазии разработчика.
Рис. 3. Пример временных таблиц.
Информацию из временных системных таблиц можно не только получать, но и обновлять. Так, системный администратор может прекратить выполнение конкретного запроса, завершить транзакцию или вообще отключить пользовательское соединение.
Разумеется, разработчики сервера позаботились и о вопросах безопасности при работе с временными системными таблицами. По умолчанию получать информацию из них и изменять ее может только администратор базы данных или ее владелец. Остальные пользователи могут лишь читать информацию из этих таблиц, и то если они имеют соответствующие права (grant).
Базы данных нового формата поддерживают четырехбайтовый тип BOOLEAN в соответствии со стандартом SQL - столбец такого типа может содержать значения NULL, True (или 1) и False (или 0).
Новый драйвер JDBC Type 4 упрощает распространение клиентских приложений и администрирование сервера. Он не использует InterServer, как предыдущий драйвер Type 3, а работает с сервером InterBase напрямую. При этом клиенты, использующие драйвер Type 3, могут продолжать работать без изменений (при наличии InterServer).
В новой версии сервера внешние таблицы (external tables, предназначенные для импорта-экспорта данных) должны располагаться только в каталогах, определенных параметром external_file_directory в IBCONFIG. Это повышает безопасность сервера в целом, ограничивая количество каталогов, в которых пользователи могут создавать или использовать внешние таблицы.
Сервер баз данных вряд ли получит широкое распространение, если к нему сложно найти разнообразные и качественные средства доступа из различных языков программирования. Для InterBase такие средства доступа есть (рис. 4). Наиболее популярны из них, разумеется, BDE и dbExpress, а также компоненты прямого доступа InterBase eXpress (IBX - поставляются в Delphi и C++Builder) и FIBPlus.
Рис. 4. Компоненты прямого доступа.
Сейчас все больше разработчиков используют компоненты прямого доступа (в том числе и в отношении других серверов баз данных), поскольку они дают массу возможностей для использования особенностей сервера, о которых говорилось выше - как минимум для полноценного управления транзакциями и их характеристиками. Для Java, разумеется, на первом месте стоит драйвер InterClient.
Доступ к серверу не из сред разработки Borland возможен из шести ODBC-драйверов, лучший из которых - EasySoft ODBC, трех провайдеров OLE DB (лучший - http://www.ibprovider.com) и других компонентов прямого доступа - IBObjects, Zeos DB, SQLRoots, IBPerl, DBD:InterBase и т. д.
Кроме того, с выпуском новой среды разработки для C# (известной на момент написания статьи как проект Borland Sidewinder) Borland планирует расширить и спектр средств доступа к InterBase, добавив к нему специальный провайдер для платформы Microsoft. NET.
Для небольших приложений производительность InterBase с настройками по умолчанию вполне достаточна для любой поддерживаемой операционной системы и аппаратного обеспечения. При запуске InterBase занимает всего 3 Мбайт, что дает возможность использовать его на машине разработчика без специальных настроек.
Если производительности начинает не хватать, то следует обратиться к файлу конфигурации IBCONFIG. Здесь можно настроить минимальный и максимальный объем памяти для процесса InterBase, размер кэша базы данных, каталоги и размер временных файлов и т. п. Настройка не представляет особой сложности, однако она должна быть выполнена в соответствии с конкретной конфигурацией сервера.
Может случиться, что изменение параметров IBCONFIG не даст существенного роста производительности. В этом случае следует обратить внимание на конфигурацию аппаратного обеспечения - чаще всего проблема не в процессоре или нехватке оперативной памяти, а в недостаточной производительности жестких дисков или в том, что на одном и том же диске размещается виртуальная память, каталог временных файлов, база данных и т. п. В этом случае следует подумать о дополнительных дисках, даже IDE, и корректно разместить на них как упомянутые выше компоненты, так и саму операционную систему. Такое разделение может повысить производительность системы в несколько раз.
Если же сервер БД производит много вычислений (триггеры, хранимые процедуры, UDF…), то потребуется более быстродействующий процессор. А если обрабатывается большое количество данных (выборки, отчеты), то следует увеличить количество оперативной памяти.
Существует много как тиражируемых, так и промышленных систем, созданных с использованием InterBase. В первую очередь это системы, которые легко строятся с использованием всех преимуществ InterBase, - бухгалтерия, склад, грузоперевозки, полная автоматизация малых предприятий и т. д. Разумеется, есть кадровые системы, финансовые, биллинговые, CRM (известный SalesExpert) и даже ERP ("Тектон-Интегратор").
Вместо того, чтобы подробно перечислять все области, где может применяться InterBase, обратим внимание на объемы данных, которые обрабатываются в этих задачах. По примерным оценкам, распределение следующее:
Размер базы данных Доля систем, % От 300 Мбайт до 1 Гбайт |
Рост объемов баз данных идет достаточно быстро, и скорее всего уже через полгода многие системы перейдут из второй группы в третью (до 8 Гбайт). Это не связано с самим пакетом InterBase, а является следствием увеличения объемов данных, обрабатываемых обычными приложениями.
Физического ограничения по размеру для базы данных - 131 Тбайт пока еще никто не достиг. Пока известны два случая, когда используется максимальный объем - 180 Гбайт финансовых транзакций по множеству компаний за несколько лет и база данных в 980 Гбайт, хранящая хэши паролей в MD5.
Необходимо отметить, что для первой и второй групп тиражируемые приложения фактически не требуют никакого администрирования. Уже существует ряд банковских систем, в которых InterBase используется более чем в двухстах филиалах с количеством сотрудников от 3 до 15 человек. Разумеется, в таких условиях нет никакой возможности содержать администратора баз данных для каждого офиса. InterBase позволяет или вообще не заниматься администрированием БД, или автоматизировать все необходимые операции, такие, как создание резервных копий, зеркалирование и т. д., при помощи средств InterBase, третьих фирм или операционной системы.
InterBase относится к числу наиболее популярных серверов для решения общих задач. Высокая функциональность и надежность, нетребовательность к ресурсам и одновременно способность использовать все ресурсы вычислительных систем, наличие множества сторонних библиотек функций, компонентов доступа, инструментальных средств разработки баз данных и автоматизации административных операций - все это в совокупности существенно облегчает разработку приложений и уменьшает стоимость владения.
А если вдруг у вас возникнут вопросы, сообщество разработчиков, использующих InterBase, обязательно вам поможет.
Дополнительная информация
За дополнительной информацией обращайтесь в компанию Interface Ltd.
| INTERFACE Ltd. |
| ||||
