Платформы

Начиная с момента своего выхода, т.е. 1985 года, Interbase был Unix-ориентированным сервером баз данных. К моменту выхода 5.0 (1997 год) множество ранее поддерживаемых операционных систем (около 15) или прекратили свое существование, или стали экзотическими, поэтому основных портов осталось 6. К 2000 году их число уменьшилось до 3 - Windows, Solaris (SPARC), и Linux. Порты под NetWare, SCO и HP-UX были прекращены как неперспективные.

Кроме уменьшения количества поддерживаемых вариантов ОС при выпуске Interbase 6.5 было решено отказаться от старой архитектуры Classic (пользователь-процесс) в пользу более современной - SuperServer (пользователь-thread).

Firebird, как OpenSource СУБД, преследовала иные цели, а именно обеспечить работу на максимально различных платформах. Поэтому архитектура Classic была сохранена (как единственная, способная обеспечить масштабирование на многопроцессорных компьютерах под Unix), и в дополнение к основным платформам были выпущены дистрибутивы (готовые комплекты для установки) для FreeBSD, HP-UX, AIX, Solaris (Intel), и даже для Darwin (MacOS X). В настоящее время ведутся работы по портированию Firebird на WinCE (пока существует только клиентская часть Firebird для WinCE).

Yaffil, как уже упоминалось выше, выпускается только для Windows, и сейчас находится в завершающей стадии тестирование Yaffil for Windows с архитектурой Classic (для работы на SMP-машинах).

Типы приложений

Конечно, самые разнообразные. Interbase давно уже распространен в нашей стране, и завоевал популярность в первую очередь у разработчиков, использующих инструментальные среды разработки Borland - Delphi, C++Builder, Jbuilder. В последнее время все больше разработчиков, использующих Visual C, MS Access и другие средства, также приходят к использованию Interbase. Это в первую очередь обусловлено появлением ряда качественных ODBC-драйверов, а также OLE-DB-провайдеров (в настоящее время их общее число около 12-ти), позволяющих тесно интегрировать работу Interbase и офисных систем.

Благодаря тому, что Interbase требует наличия минимума файлов для установки (6 файлов, и 2 ключа в Registry), а также весьма нетребователен к ресурсам, максимальное количество приложений, его использующих - офисные системы общего назначения. Это складской учет, бухгалтерия, зарплата, автоматизация отделов продаж, и многое другое.

Такие системы как правило по объему хранимых данных не превышают 300-500 мегабайт, а также работают либо в однопользовательском, либо в многопользовательском режиме с количеством пользователей от 2 до 15-ти, и легко переносятся с компьютера на компьютер. Операционная система в данном случае чаще всего Windows 95 или 98. К сожалению, о надежности в этом случае серьезно говорить нельзя, однако такие требования обычно обусловлены финансовыми причинами, по которым пользователи приложений не могут установить Windows XP/2K из-за старых процессоров или небольшого количества оперативной памяти - 32 мегабайт RAM для подобных систем вполне достаточно даже при работе с невыделенным сервером до 15-20-ти пользователей.

Более серьезные приложения, как то внутрикорпоративные системы, системы управления предприятием, биллинговые и т.п., разумеется работают с большими объемами данных (от 500 мегабайт до 8 гигабайт) и как правило используют Unix в качестве серверной ОС, и никогда не работают в однопользовательском режиме. При количестве пользователей до 50 на сервер обычно используют Windows, а в случаях до 300-400 пользователей - обязательно Unix (RedHat Linux или FreeBSD) и как правило на двух-, реже четырех-процессорных системах. В процентном отношении для данных систем в качестве операционной системы сервера Windows используется в 30% случаев, Unix - 70%.

Classic и SuperServer

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

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

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

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

Classic или SuperServer

Следует заметить, картина складывается довольно интересная на каждый недостаток Classic у SuperServer находится достоинство. Classic расточителен - SuperServer экономен, Classic без Services API - у SuperServer он есть.

Однако, как и везде, здесь мы имеем "палку о двух концах", т. е., определенные недостатки Classic переходят в определенных ситуациях в его достоинства, а преимущества SuperServer превращаются в недостатки. Например, рассмотрим случай. когда N нас имеется, скажем, мощный двухпроцессорный компьютер- сервер с большим количеством ОЗУ, например 2 Гбайт. Если мы установим на такую систему InterBase в варианте SuperServer, то будем наблюдать не ускорение, а замедление по сравнению с однопроцессорным вариантом того же сервера! Более того, с памятью будут твориться сплошные "недоразумения"- экономный SuperServer будет "отказываться" от огромного ОЗУ. пытаясь всячески сэкономить оперативную память. Как же так, мощные процессоры, много памяти, a InterBase SuperServer не очень-то быстро работает?

Вот здесь и проявляются недостатки SuperServer. Проблему с масштабируемостью InterBase архитектуры SuperServer на многопроцессорных компьютерах давно признали в компании Borland. Дело в том, что ядро SuperServer не расчитано на использование нескольких процессоров. Сервер InterBase SuperServer не может управлять распределением потоков по процессорам. В результате ОС при нарастании нагрузки начинает перебрасывать главный серверный процесс (ibserver.exe) с одного процессора на другой. На это тратятся системные ресурсы и время, что замедляет работу InterBase. С такой ситуацией на многопроцессорных системах борются путем "привязки" (affinity) InterBase варианта SuperServer к одному определенному процессору и игнорирования остальных.

Надо также отметить, что с распределением памяти у SuperServer тоже имеются некоторые проблемы. Если мы рассмотрим, как SuperServer обслуживает множество небольших клиентских запросов, то увидим довольно привлекательную картину: высокую производительность при относительно небольшом использовании оперативной и виртуальной памяти. Многочисленные клиентские запросы совместно (без дублирования) используют кешированную информацию SuperServer. Эта особенность делает вариант InterBase с архитектурой SuperServer особенно привлекательным для Web-приложений, ориентированных именно на такой стиль работы с базами данных. Так как запросы небольшие, то они быстро отрабатывают и освобождают память для следующих за ними запросов.

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

Эти "тяжелые" запросы "проходятся" по большому количеству записей и требуют значительных ресурсов памяти и процессора для их выполнения. Мы пытаемся предусмотреть подобную ситуацию и используем мощное аппаратное обеспечение: высокопроизводительный компьютер-сервер с большим количеством ОЗУ. Однако, SuperServer "не понимает" нашей предусмотрительности и при выполнении "тяжелого" запроса пытается обращаться с ним как с небольшим, т. е. отдает ему доступную кеш-память и ресурсы, вытесняя при этом остальные запросы. Результат печален - пока выполняется запрос-тяжеловес, остальные запросы "топчутся в очереди". В связи с фактически последовательным обслуживанием потоков критическими участками кода ядра InterBase сервер просто не имеет другого выбора.

Остается сказать о достоинствах Classic, проявляющихся в этой ситуации.

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

Во-вторых, использование памяти и процессора при выполнении "тяжелых" запросов. Если мы запускаем какой-то очень интенсивно работающий с базой запрос, то он выполняется в рамках одного серверного процесса, обслуживающего данного клиента, не останавливая при этом остальные. Приоритет "тяжелого" запроса (фактически процесса) падает по мере увеличения времени использования им ресурсов процессора и он начинает "уступать дорогу" более приоритетным процессам других соединений, выполняющим короткие запросы, т. е. процессор занят на 90%, но на долю "долгожителя" приходится 80-70-60- 50-40 %... Он замедляет остальные, это заметно, но терпимо, и главное - у пользователя не возникает ощущения "подвешенности".

Вот где недостаток "избыточность" перетекает в преимущество "нагрузочная способность". Как бы то ни было, архитектура Classic значительно лучше SuperServer справляется с тяжелыми запросами при одновременном обслуживании нескольких клиентов и более корректно реализует вытесняющую многозадачность, что позволяет эффективнее справляться с запросами-"тяжеловесами".