Лекция 1. Введение в клиент-серверные субд.

В конце 80-х годов все знали, что разработка клиент-серверных многопользовательских систем - это сложно. Разработка велась в основном на языках четвертого поколения, входящих в комплект соответствующих СУБД. Стоимость таких разработок была очень велика и занимались этим в основном серьезные профессионалы. Нишу настольных приложений заняли умельцы, владеющие "народными" СУБД типа Clipper, FoxPro и Paradox, и слои практически не пересекались.

Но в начале 90-х радикально подешевели средства организации локальных сетей с разделяемыми файлами (файл-серверов), и появились "сетевые" версии настольных СУБД, позволяющие как-то обеспечить многопользовательскую работу. Они заняли промежуточную ценовую и квалификационную нишу между чисто настольными и клиент-серверными системами (ближе к настольным, естественно). Клиент-серверные разработки в нашей стране оказались вытеснены в область критически важных high-end-решений типа резервирования авиабилетов, учета на очень больших предприятиях, в крупных банках и др.

Результаты прогресса привела к тому, что на рынке уверенно возобладали реляционные СУБД, и произошло сближение функциональности ряда лидирующих клиент-серверных систем (Oracle, MS SQL, Sybase, DB2, Interbase, Progress). Цены на эти системы заметно снизились (в разы).

При организации архитектуры «клиент-сервер» наиболее трудоемкие операции над базами данных выполняются на выделенном компьютере-сервере, который должен быть достаточно мощным и обладать соответствующим набором ресурсов основной и внешней памяти. До поры серверная часть СУБД обладала простой организацией (рис.1.): запросы, поступающие из клиентских частей системы, обрабатывались последовательно с небольшой оптимизацией для совмещения процессорной работы с работой устройств внешней памяти. Однако с появлением на рынке мультипроцессорных симметричных аппаратных архитектур, производители СУБД были вынуждены пересмотреть организацию своих серверов, допустив в них внутреннюю параллельность. Естественно, это требует очень основательного перепроектирования системы с ее существенным усложнением.

Рис 1. Архитектура клиент—сервер

Есть несколько причин, определяющих преимущества клиент-серверной архитектуры перед файл-серверной:

• уменьшение сетевого трафика за счет того, что выборка данных производится на сервере, и они не "прокачиваются" по сети;

• увеличение производительности за счет того, что сам сервер может эффективно кэшировать данные;

• перенос части функциональности на сервер с уменьшением трафика и увеличением производительности (хранимые процедуры, триггера);

• масштабируемость - при возрастании нагрузки достаточно заменить лишь сервер, а не все станции и сетевые платы;

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

Транзакция – это последовательность операций над базой данных, рассматриваемых СУБД как единое целое. Транзакция представляет собой набор действий, выполняемых с целью доступа или изменения содержимого базы данных.

Для всех современных реляционных СУБД основным языком доступа к базам данных является SQL. В 1989 г. появился первый международный стандарт этого языка, и большинство производителей СУБД объявляют свои системы соответствующими этому стандарту. Но стандарт 1989 г. был довольно ограниченным (например, в него не входили средства манипулирования схемой БД, динамический SQL и т.д.), а многие вошедшие в стандарт аспекты языка были специфицированы недостаточно строго. Поэтому разные реализации различаются в достаточно важных вопросах.

В 1992 г. был принят новый стандарт SQL-92. Этот язык существенно более сложен, чем SQL-89, а конструкции SQL-92 специфицированы в стандарте существенно более полно. Первой компанией, которая объявила о соответствии своего продукта новому стандарту, была компания Oracle со своей седьмой версией (это произошло прямо в 1992 г.).

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

Таким образом, создается иллюзия, что система, разработанная для одного сервера БД, может быть легко перенесена на другой или, более того, можно сделать систему, которая будет работать с различными типами серверов.

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

• у разных серверов разный синтаксис и функциональные возможности языков разработки хранимых процедур и триггеров;

• поскольку разные серверы пользуются разными алгоритмами оптимизации, то запросы, хорошо работающие на одной системе, могут оказаться неэффективными на другой. А арсенал способов управления эффективностью у них совершенно разный;

• местами не совпадает даже синтаксис SQL - в части, например, внешних соединений таблиц (outer join);

• поскольку разные серверы пользуются разными принципами блокировок и организации транзакций, то для эффективной многопользовательской работы нужны разные способы организации программы;

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