Читать онлайн «Мир InterBase. Архитектура, администрирование и разработка приложений баз данных в InterBase/FireBird/Yaffil». Страница 88

/intl

Содержит gdsintl - библиотеку, содержащую информацию о кодировках (аналогично GDSINTL.DLL под Windows)

/lib

Каталог содержит клиентские библиотеки libgs.so и libib_util.so, которые являются аналогами gds32.dll и ib_ util.dll в Windows. Также в этом каталоге находится библиотека libgs.a, которая представляет собой библиотеку для статической сборки клиента

/misc

Каталог содержит Firebird. xinetd - файл конфигурации для менеджера сервисов xinetd, в котором описаны параметры клона InterBase 6.x Firebird

/UDF

Каталог, в котором должны находиться UDF-библиотеки пользователя. По умолчанию содержит только библиотеку ib_udf

isc4 gdb

База данных пользователей InterBase

isc_config

Файл, хранящих настройки конфигурации для InterBase; аналогичен файлу ibconfig в версии InterBase под Windows

isc_eventl .teststation

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

iscjockl. teststation

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

InterBase log

Файл протокола InterBase

InterBase msg

! Файл сообщений InterBase

services, isc

Файл, который содержит информацию о соответствии номера порта имени сервиса, который будет использоваться для InterBase (обычно постановка в соответствие выглядит как gdsdb/tcp 3050). Эту постановку в соответствие необходимо добавить в файл /etc/services (обычно автоматически добавляется установщиком InterBase)

Рассмотрев икра те состав InterBase Classic Server для Linux, рассмотрим теперь более подробно состав каталога BIN в этой версии. Он отличается в основном программными модулями, специфичными для архитектуры Classic.

Как будет ясно из главы "Classic и SuperServer", в Classic-архитектуре состав основных исполняемых файлов InterBase меняется - к нему добавляется менеджер блокировок и различные утилиты для управления InterBase. Файлы в каталоге Вт описаны в таблице 4 20.

Табл 4.20. Файлы в каталоге Bin InterBase CS для Linux

Файл

Описание файла

changeDBAPassword.sh

Полезные скрипты на языке shell для некоторых действий:

CSchangeRunUser sh

смены пользователя SYSDBA, смены пользователя,

CSrestoreRootRunUser.sh

с правами которого запускается InterBase

gbak

Утилита резервного копирования и восстановления

gdef

Утилита, позволяющая создавать и изменять метаданные

gds_drop

Утилита, которая останавливает InterBase

gds_met_server

Основной исполняемый файл InterBase в Classic-версии InterBase

gds_lock_mgr

Менеджер блокировок

gds_lock_print

Утилита, применяющаяся для анализа таблицы блокировок

gds_pipe

Утилита, предназначенная для поддержки приложений, использующих POSIX-сигналы

gfix

Утилита модификации и восстановления базы данных

gpre

Препроцессор С для разработчиков на InterBase API

gsec

Утилита управления базой данных пользователей isc4.gdb

gsplit

Утилита для разделения/слияния одного большого файла базы данных в/из нескольких

gstat

Утилита для анализа статистики по базам данных InterBase

isc4 gbak

База данных пользователей InterBase

isql

Interactive SQL - утилита для ввода команд SQL и исполнения SQL-скриптов

qli

Query Language Interpretator - интерпретатор языка GDML

В данной главе были рассмотрены две версии InterBase: Super под Windows и Classic под Linux, чтобы читатель получил представление о том, какой совокупностью файлов представлен InterBase. Состав файлов для InterBase обеих версий был рассмотрен на примере клона InterBase 6 - Firebird 1.0.

На данный момент существуют два варианта архитектуры InterBase, которые значительно отличаются друг от друга методами работы с клиентами, организацией взаимодействия собственных модулей и даже составом модулей, входящих в определению реализацию архитектуры. Условно эти две различных архитектуры назвали Classic и SuperServer. Чтобы быстро войти в курс дела, коротко рассмотрим главные особенности этих архитектур.

Архитектура Classic кратко характеризуется следующей фразой: "каждому клиенту - собственный сервер". Это означает, что на каждое клиентское соединение на компьютере-сервере запускается серверный процесс, который обслуживает одного клиента. Сколько у нас будет клиентов, установивших соединения, столько экземпляров сервера запустится для их обслуживания (имейте в виду, что одна клиентская программа может открывать сколько угодно соединений с сервером).

Архитектуру SuperServer можно по аналогии охарактеризовать как "на всех клиентов - один сервер". Это означает, что все клиентские соединения обслуживаются одним серверным процессом, где каждым конкретным клиентом занимаются отдельные потоки (threads).

Сразу следует сказать, что компания Borland уже давно, еще до опубликования исходных кодов InterBase 6, заявляла о своей решимости полностью отказаться от архитектуры Classic и перейти исключительно на SuperServer, ввиду ее многочисленных достоинств.

Тем не менее Classic жива и поныне, имеет своих многочисленных приверженцев и не собирается так просто "сдаваться". Причины этой нешуточной схватки двух подходов мы сейчас рассмотрим, и начнем, конечно же, с исторического экскурса.

Ограничим глубину погружения в историю версией InterBase 4.x. Изначально InterBase 4 имел архитектуру Classic - это были версии 4.0 и 4.1. Версия 4.2 стала первым SuperServer в ряду продуктов InterBase. Версия InterBase 5.x уже не имела реализаций архитектуры Classic под платформу Windows - только SupeiSeiver, но для Linux существует версия InterBase 5.6 с архитектурой Classic. В InterBase б сохраняется та же ситуация - под ОС семейства Unix/ Linux существуют InterBase 6 как в варианте SuperServer, так и в варианте Classic, а под Windows - только SuperServer.

Следует заметить, что деление на Classic и SuperServer не означает, что имеются два варианта исходных кодов для каждого вида архитектуры - один для Classic и другой для SuperServer (иначе со временем получились бы два разных сервера). Оба эти варианта архитектуры (и все реализации под разные ОС) производятся из общего набора исходных кодов с помощью директив Ifdef, разделяющих платформенно- и архитектурно-зависимые участки кода друг от друга. С помощью набора этих директив определяют, какой вариант и для какой платформы собирать. Естественно, для разных ОС сборка осуществляется с использованием разных библиотек ввода-вывода, управления памятью и т. д. Таким образом, начиная с версии InterBase 5.x компания Borland перестала разрабатывать вариант сервера под Windows с архитектурой Classic, в результате чего этот вариант архитектуры доступен только поклонникам Unix/Linux-систем, а версии Classic под Windows ни в вариантах реализации от Borland, ни от Firebird не существует.

В конце 2001 года появился еще один альтернативный клон InterBase 6 - СУБД Yaffil, авторами которой являются петербургские программисты Олег Иванов и Алексей Карякин. Этот вариант InterBase как раз и имеет реализацию архитектуры Classic под Windows. Подробнее о Yaffil можно узнать в приложении "Yaffil - российский клон InterBase 6.x".

Стоит ли использовать Yaffil или ставить Firebird/InterBase 6.x на Linux, чтобы ощутить прелести и оценить недостатки архитектуры Classic, - мы сейчас и попытаемся разобраться.

Рассмотрим подробнее архитектуру Classic-варианта сервера InterBase. В этой модели, как было сказано ранее, для каждого клиентского соединения запускается собственный серверный процесс, который обслуживает данного клиента. Процессом запуска управляет внешний процесс (это inetd или xinetd для Unix-систем).

Серверные процессы изолированы друг от друга. Как и любые другие процессы в ОС, они не могут свободно читать и писать друг у друга в памяти. Тем не менее работать они будут с одной базой данных, в результате чего могут возникнуть конфликты и рассогласования данных в базе данных. Представьте себе, что один серверный процесс пытается изменить страницу в базе данных, которую в данный момент изменяет другой процесс. Очевидно, что возникнет конфликт на почве распределения ресурсов. Чтобы сообщить о том, что определенные ресурсы в базе данных в данный момент используются и разрешить возникающие при "дележке" конфликты, существует специальный процесс - менеджер блокировок (gds_lock_mgr). Необходимость в менеджере блокировок возникает, когда второй клиент подсоединяется к базе. Именно в этот момент менеджер блокировок загружается в память, чтобы "следить за порядком".

Помимо разрешения конфликтов, существует дополнительная необходимость управления сервером в смысле администрирования. К сожалению, в Classic невозможно с клиента получить информацию о количестве клиентских соединений, обслуживаемых в данный момент сервером, так как для каждого клиента существует только один сервер, а информация об остальных серверных процессах, обслуживающих других клиентов, ему недоступна. Также в Classic- вариантах InterBase 6 и его клонов пока не реализовано Services API, которое позволяет управлять сервером через клиентские соединения, а не через специальные программы. Правда, надо отметить, что Yaffil Classic Server имеет реализацию Services API.