А Ковязин - Мир InterBase. Архитектура, администрирование и разработка приложений баз данных в InterBase/FireBird/Yaffil
Yaffil существует в варианте с классической архитектурой, что позволяет эффективно использовать его в многопользовательских приложениях, а также на SMP системах
Несмотря на молодой возраст и большое число нововведений, Yaffil версии 1.0 в настоящее время является достаточно стабильным сервером и достойно представляет вклад российских разработчиков в создание семейства наследников InterBase 6.0 Open Edition.
InterBase 7
Семерка - первый шаг нового семейства
Чем InterBase 7 отличается от своих предшественников? Вот главный вопрос, на который отвечает эта глава.
Прежде всего надо отметить, что помимо непосредственно технических новшеств и улучшений в InterBase 7 был введен ряд изменений "политического" характера, направленных на разрушение совместимости с Firebird. Можно предположить, что это было сделано в связи с планами компании Borland выпускать новые версии своих продуктов, в том числе и InterBase, не реже чем раз-два в год. Таким образом, InterBase 7 лишь первый шаг в этом направлении, и можно с большой уверенностью сказать, что в 2003 году 8-я версия InterBase принесет нам много сюрпризов.
Но пока давайте сосредоточимся на технических подробностях 7-й версии InterBase.
Распараллеливание на несколько процессоров
Многие разработчики представляют себе понятие распараллеливания по разному поэтому надо внести ясность, что имеется в виду под этим термином в случае InterBase 7. Прежде всего уточним, что речь идет о выполнении SQL-запросов, посылаемых пользователем. И тут обычно начинаются разночтения.
Одни считают, что распараллеливание - это когда разные части одного и того же SQL-запроса обрабатываются на различных процессорах. Другие считают, что распараллеливание - это когда разные соединения с пользователями "рассаживаются" по разным процессорам и все запросы от пользователя внутри них независимо выполняются на том процессоре, на котором выполняется обработка данного соединения (такой подход реализован в архитектуре Classic Server).
Однако в архитектуре SuperServer, реализованной в InterBase 7, в чистом виде не используется ни тот ни другой тип распараллеливания.
Чтобы понять, как InterBase 7 использует несколько процессоров, давайте немного углубимся в его архитектуру и рассмотрим процесс обслуживания запросов пользователя.
Когда пользователь посылает запрос на соединение, то этот запрос обрабатывается глобальным менеджером соединений и в случае правильности имени пользователя и пароля регистрируется в списке обслуживаемых клиентов.
Отдельного потока (thread) для индивидуального обслуживания только что подсоединенного клиента не запускается. Это легко можно проверить, написав простенькое приложение, которое откроет несколько сотен соединений с сервером, - и если эти соединения простаивают, то информация о процессе ibserver.exe в Task Manager показывает, что открыто всего 5-8 потоков.
Далее как только подсоединенный пользователь пожелает выполнить какой- либо SQL-запрос, сервер запускает поток, который обслужит данный запрос. После обслуживания данного запроса поток через некоторое время завершает свою работу. Если этот же пользователь снова выполнит другой SQL-запрос, то совершенно не обязательно, что его будет обслуживать ют же самый поток, что и в первый раз.
На самом деле, потоки не запускаются/уничтожаются исключительно по желанию пользователя — InterBase отслеживает среднюю загрузку/частоту выполнения SQL-запросов и держит постоянно открытым пул потоков, содержащий оптимальное число потоков, готовых обработать запросы пользователей.
Такая схема работы не только чрезвычайно экономична - позволяет держать оптимальное количество потоков, но и позволяет (точнее сказать - создает предпосылки для выполнения) выполнять в одном соединении несколько параллельных запросов (например, MSSQL этого не позволяют, требуя открытия отдельного соединения для параллельного выполнения SQL-запросов с одного клиента)
Теперь читатели наверняка догадались, как работает распараллеливание в InterBase, - каждый запускающийся поток будет привязан к наименее загруженному процессору, который и обработает (целиком!) SQL-запрос пользователя Таким образом, разные запросы от одного пользователя могут быть выполнены (в том числе и параллельно) на разных процессорах.
Итак, 7-я версия InterBase - это масштабируемый сервер архитектуры SuperServer. Если вы внимательно читали главу "Classic и SuperServer", то знаете, что главным недостатком архитектуры SuperServer была невозможность эффективно использовать несколько процессоров. В 7-й версии InterBase эта проблема была разрешена, и теперь у InterBase есть возможность работать на многопроцессорных серверах.
Не имея исходных кодов семерки, можно лишь с относительно высокой долей вероятности предположить, что разработчики этой версии пошли по пути оптимизации существующего кода, т е InterBase 7 не переписывался "с нуля". Учитывая огромный объем исходного кода сервера, очевидно, что изменить InteiBase 6.x для поддержки распараллеливания, а затем отследить и протестировать эти изменения - это грандиозная работа, за которую пока не взялся никто, кроме разработчиков из Borland.
Как бы то ни было, InterBase 7 может использовать мощь нескольких процессоров одновременно, а также более эффективно обрабатывает одновременно выполняющиеся SQL-запросы даже на однопроцессорных машинах. Это значительно расширяет сферу его применения и увеличивает ту долю рынка, которую InterBase может забрать у других, гораздо более "монстровидных" СУБД.
InterBase 7 предоставляет средства распределения загрузки по нескольким процессорам. Например, вы можете выделить InterBase только 2 из 4 процессоров, а оставшиеся загрузить другими, не менее важными делами. Для управления привязкой InterBase к процессорам используется специальный параметр CPU_AFFINITY в файле конфигурации сервера ibconfig. В документации к InterBase 7 приведена таблица, показывающая, какое значение должен иметь данный параметр для привязки к желаемым процессорам, и мы здесь ее повторять не будем.
Также в ibconfig появился параметр MAX_THREADS, который устанавливает число одновременно открытых в пуле потоков, готовых к обслуживанию запросов. Изменение этого параметра позволяет управлять загрузкой процессоров - чем меньше потоков, тем меньше процессорного времени будет потреблять InterBase. Для однопользовательских приложений рекомендуется установить этот параметр в 1. Максимальное значение этого параметра - 100.
Важно отметить, что MAX_THREADS не ограничивает число возможных соединений (т. е. обслуживаемых клиентов) с сервером, а лишь устанавливает максимальное значение активных потоков. Таким образом, можно "подсказать" серверу, чтобы он не слишком "экономил" и не закрывал потоки при отсутствии загрузки, т е другими словами, был готов к резкому увеличению количества клиентов.
Мониторинг состояния сервера
Любители исследовать исходный код InterBase б часто говорят, что в нем скрыта масса интереснейших идей, которые были не доведены до конца по каким-либо причинам. Одной из таких идей, извлеченных и реализованных в InterBase 7, является мониторинг внутреннего состояния сервера.
В InterBase предыдущих версий сервер производил постоянный мониторинг своего состояния — отслеживал выполняющиеся запросы, подключенных пользователей и т. д. Но все эти данные были для внутреннего использования - пользователи не могли получить к ним доступ. Теперь ситуация изменилась - в InteiBase 7 появился удобный интерфейс для доступа к данным о мгновенном состоянии сервера.
InterBase 7 предоставляет механизм "временных системных таблиц" для доступа к данным о своем состоянии. Не надо путать эти временные таблицы с временными таблицами в других СУБД, которые используются для оптимизации выполнения SQL-запросов.
В данном случае временные системные таблицы лишь представление мгновенного снимка состояния сервера и баз данных. Чтобы избавить разработчиков приложений баз данных от необходимости использовать специальные вызовы API для получения (и даже изменения') информации о состоянии сервера, в семерке создан SQL-интерфейс для этих целей. Не правда ли, очень удобно - формируете стандартными средствами SQL-запрос и получаете нужную статистику в виде привычного набора данных.
Выполняя запросы к временным таблицам, можно получить свежие (на момент выполнения запроса) данные о том, какие запросы выполняет конкретный подключенный пользователь, какие таблицы использует Чтобы обновить полученные данные, надо подтвердить транзакцию, в рамках которой выполнялся запрос к временным системным таблицам, и выполнить запрос снова.
Можно также узнать, какие запросы в данный момент выполняются на сервере и какой из этих запросов самый длительный. Помимо этого, существует еще множество видов информации, которую можно извлечь из системных таблиц.
Вот список временных системных таблиц для мониторинга в InterBase 7 с краткими описаниями, взятый с сайта www.ibase.ru:
