Клиент-сервер входит в моду. Ничего хорошего. Потому что клиент-сервер - инструмент. Как утюг, например. Им пользоваться надо. А делать из утюга кумира - это уже фетишизм. Здесь доктор нужен.
Дебаты на темы клиент-сервер, построение корпоративных систем и т. д. в России приобрели в достаточной мере схоластический характер. Поводом для спора в большинстве случаев становится не случай из жизни, а запавшая в душу публикация или посещение семинара, в чем, конечно, мало кто сознается. (Может быть, я неправ и это просто дает о себе знать фундаментальный принцип "20 на 80", в самом общем виде формулируемый так: "20 процентов от всего сообщества любителей пива потребляют 80 процентов продукта". Одним из частных проявлений его является то, что 20 работают, а 80 ведут разговоры. И общий фон создается, конечно, теми, кто говорит.)
Отсутствие реальной возможности на практике проверить свои догадки приводит к тому, что, как снежный ком, растет число легенд и псевдохарактеристик реально существующих программных и аппаратных продуктов.
Миф номер один: "архитектура клиент-сервер обеспечивает производительность большую, чем у мэйнфреймов". Сама. "Возьмем немного Windows NT (NetWare, SCO, ...), добавим SYBASE (MS SQL Server, Oracle, Informix, Btrieve, ...), взболтаем и перемешаем с PowerBuilder (Delphi, Visual Basic, Developer/2000, ...) и дешевый РС’шный сервер чудесным образом побьет IBM ES/9000". Вариации - "мониторы транзакций повышают производительность (надежность, переносимость,...) клиент-серверных приложений". Сами.
Даже не мечтайте. На благодатной почве такого рода заблуждений пышным цветом расцветают продукты, спекулирующие на чужой славе. Методика "зачем платить больше" реализуется чаще всего формированием разреженной матрицы. Специальным образом подбирая параметры для сравнения, можно добиться того, что все "галочки" будут стоять в нужной колонке, а ненужные останутся почти пустыми.
Профанация может при минимуме затрат принести максимум дохода. И клиент объективно готов быть обманутым - он купит дешевый, гм, пардон... доступный продукт, будучи искренне уверенным, что ему сказочно повезло и за меньшие деньги досталось все то же самое, что предлагают лидеры отрасли. Беда в том, что "галочка" отражает наличие той или иной возможности, но не говорит о том, как эти возможности реализованы.
Опыт, он, знаете ли, птичками не описывается, а просто так дешевле ничего не бывает. Выясняйте не только то, насколько широко распространен предлагаемый вам продукт, но и то, в какой области. Может быть, он действительно "занимает на Западе 80% рынка". Только установлен в основном в организациях вдесятеро меньших, чем ваша.
Клиент-серверная технология оптимизирует распределение нагрузки между компьютерами |
Еще один миф: "клиент-сервер - это Unix" или "весь мир работает на Unix". Отнюдь. Весь мир работает на машинах DEC, HP, IBM RS/6000, Sun, SGI. И не абстрактное "соответствие открытым стандартам", а наличие совершенно конкретных продуктов, таких, как HP OpenView, IBM NetView (у IBM и на "закрытых" OS/2 или AS/400 есть на что посмотреть) или Sun Net Manager, является в этих случаях фундаментом корпоративных решений. Памятен исторический анекдот, когда Microsoft реализовала в Windows NT, тогда еще 3.1, вызов удаленных процедур в стандарте RPC OSF/ DCE. И оказалась первой, кто это сделал. Историческая роль Unix заключалась в том, что он продемонстрировал необходимость поддержки открытых стандартов, не более и не менее. И необходимость эта уже осознана даже самыми неповоротливыми. В то же время среди крупных производителей СУБД немного найдется таких, которые не поддерживают "закрытую" ОС VAX/VMS. А среди сетевиков - тех, кто не знает, что такое SNA. Так что вопрос - в распространенности той или иной платформы. И в нашу эпоху открытости и микроядер, тихонько и незаметненько ширится круг пользователей AS/400 - "антиархитектуры", закрытой и с большим-большим ядром.
A Unix... Как вам может нравиться система, ставящая во главу угла похожесть? Которая при этом достаточно похожа, чтобы сделать процесс переучивания при переходе с одной платформы на другую достаточно скучным, а с другой стороны - она недостаточно похожа, чтобы быть, как, скажем, NT, всегда одной и той же системой и не требовать упомянутого переучивания.
А в это время Windows NT преодолевает очередной рубеж, и при содействии Digital и AT&T создается кластерный вариант Windows NT. Клиент-сервер - это Unix? Скажите об этом Borland, Oracle или Sybase, которые впустую затратили силы и средства на поддержку UnixWare. Хорошая была система, а мы - ай-яй-яй - чуть было не поверили окончательно в серьезность намерений Novell в отношении Unix. Теперь и в Novell распрощались с заблуждением, что слово "Unix" отпирает сердце любого корпоративного пользователя.
Открытые стандарты, конечно, нужны. Но будьте уверены - если сам производитель "железа" или программного обеспечения не озаботится поддержкой того или иного протокола, той или иной операционной системы, никакие комитеты OSF или Х/Ореп вам не помогут.
Миф номер три: "никогда серверы не догонят мэйнфреймы". Об этом же, устало улыбаясь со страниц PC Week, говорит нам и симпатичная дама Кристина Комафорд. Доказательства, конечно, не нужны - "что вы право, как дети малые, неужели непонятно..." Если речь идет о превосходстве в весе, то я поднимаю руки. По поводу всего остального рекомендую заглянуть на
http://www.tpc.org или http://www.ideas.com.au. Там в разделе ТРС-А все еще лежат результаты для ES/9121 511 TPF, ES/9121 742 Fast Path и 4-узлового кластера DEC 7000 650, того самого сервера, который "ни за что и никогда..." При сравнимой цене кластер оказывается более чем в два раза производительнее, а при сравнимом (и даже более высоком) результате стоит на треть меньше. Это - редчайший случай, когда мэйнфрейм оказался рядом с сервером (новых данных по мэйнфреймам, ТРС-С результатов, пока нет на хосте ТРС). Второй известный мне случай такого рода - это SYBASE вместе с Expressway (теперь это SYBASE IQAccelerator) на AT&T NCR 3500 против DB2 на IBM 3090-600J. Тест проводился на данных реальной задачи класса поддержки принятия решений и состоял из 12 сложных аналитических запросов. Операции агрегирования были выполнены Expressway в II - 853 раза быстрее, чем DB2. Усредненное же ускорение - 10 раз, то есть на порядок. Милости прошу на ftp://ftp.sybase.com. Конечно, 3090 не самая мощная машина среди мэйнфреймов, но и NCR 3500 не кластер и не МРР.
Если бы IQAccelerator работал на мэйнфрейме, то побил бы он Unix-сервер? Конечно. Но мы живем не в мире гипотез, а в нашем, реально существующем, в котором IQAccelerator - член команды, называемой "клиент-сервер". Мэйнфрейм мощнее? Да ради Бога! Технология клиент-сервер изначально знаменовала собой поиск технологических решений, которые из более слабого оборудования (но и менее дорогого!) выжимали бы больше пользы.
Российская любовь к большим ЭВМ больше отдает снобизмом, чем реальными потребностями. Подавляющее число задач из тех, что решались на ЕС еще 10 лет назад, и тех, которым действительно нужна была мощная машина, - задачи САПР/ЧПУ. То есть задачи, которым из всех ресурсов нужен в основном процессор, и те, которые в наше время дружат с Alpha АХР. А программы, обрабатывающие хотя бы по 100 Гб данных, которым, собственно, и нужен быстрый ввод-вывод, - это такая экзотика, что пальцев одной руки хватит, чтобы перечислить те закрытые учреждения, в которых оные программы работают. Подтверждением тому - популярность в России машины IBM S/390, "мэйнфрейма", выполненного на базе PC сервера и умещающегося под столом. Это и есть то, что буржуи называют rightsizing (оптимальная платформа). Не downsizing (уменьшение масштаба), а именно rightsizing, поскольку это яркий пример использования того объема ресурсов, который нужен на самом деле.
S/390 - машина для разработки, и по вводу-выводу она - не более чем PC-сервер. Если бухгалтерия предприятия безболезненно переносится с ЕС "под стол", то это говорит о том, что объемы данных не столь уж велики и всякого рода высокомерие по отношению к "клиент-сервер" совершенно неуместно.
Итак, вы хотите перейти с ЕС на ES? Сделайте это, если вы просто любите большие машины. Сделайте это, если у вас есть очень ценные наработки (хотя, не дешевле ли будет их перенести?). Но, Бога ради, не делайте этого только потому, что "мэйнфреймы быстрее". Они быстрее не всегда и, возможно, не для ваших задач. В конце концов если речь идет о больших машинах IBM, то у этой фирмы есть и другие интересные изделия.
Попутно помянем еще одну легенду - "реляционные СУБД уступают иерархическим СУБД и СУБД с сетевой архитектурой". На упомянутом выше кластере DEC работала вполне реляционная Rdb, на ES/9121 742 Fast Path - иерархическая IMS/DB 4.1, а на ES/9121-511 - TPF 3.1, вещь, которая даже в очень сильном приближении не может быть отнесена к реляционным СУБД. Задержитесь немного на www.tpc.org и перейдите к ТРС-В. Здесь вы сможете увидеть, сколь скромно себя ведет Adabas 2.1 на НР9000 15 по отношению к MS SQL Server 6.0, работающему на впятеро менее дорогом HP NetServer. Десять лет назад, в эпоху Кодасил, Adabas был сетевым, а сейчас сменил окрас и внезапно стал "реляционным, только лучше, чем просто реляционный", в частности "более быстрым за счет использования инвертированных списков" (которые за двадцать пять лет так и не продемонстрировали реального превосходства).
Я уже устал читать, что ограничением реляционных СУБД является то, что они описывают только двумерные данные, а вот СУБД, которые обходят ограничения первой нормальной формы, дают третье измерение и гибкость невероятную. Может быть, заглянем наконец в какую-нибудь хрестоматию? В которой весьма понятно объясняется, что (1, 2, 3, 4, 5) - вектор в пятимерном пространстве. А если (1, 2, 3, 4, 5) не вектор, а строка таблицы?
Еще один анекдот: "ограничением MS SQL Server при использовании его в корпоративных задачах является то, что он блокирует данные на уровне строки, а не страницы" (Computer Week). Яркий пример весьма неосторожной экстраполяции опыта работы на мэйнфрейме в новую среду. Если у MS SQL Server и есть проблемы на корпоративном уровне, то упомянутая выше характеристика не входит в список оных проблем. Клиент-сервер для интерактивного режима предлагает оптимистическую блокировку, зато при пакетной загрузке данных или высокой интенсивности онлайновой обработки транзакций блокировка страницы оказывается более эффективной, что уже продемонстрировано и самой MS SQL Server, и SYBASE System II, прародительницей MS SQL Server. Модификация данных в системах с большим числом пользователей должна производиться как запрос на модификацию, а позволить пользователю сколь-нибудь продолжительное время захватывать ресурс - это использование сервера как мэйнфрейма, т. е. в наиболее невыгодном для сервера режиме. Все это уже прошло проверку временем, дискредитировало себя, а заодно и послужило основой для слухов об отвратительной масштабируемости архитектуры клиент-сервер. Open Server или CICS и Tuxedo и не предполагают иного способа, поскольку клиент вообще изолирован от сервера данных. Здесь же задают и второй вопрос: "Если оператор пошел покурить, как снять наложенную им блокировку?" Да никак! Не блокировать вообще.
В общем, то, о чем мы спорим, в очередной раз демонстрирует наше стабильное отставание на 5 - 10 лет - это единственное, в чем нам уже удалось достичь стабильности. И мифы, доставшиеся в наследство со старой техникой, и новые мифы, невольно или злонамеренно порождаемые красочными буклетами, свидетельствуют об одном: мы еще не достигли должного уровня.
Клиент-сервер не магическое заклинание. Если произнести его, автоматизированные системы не становятся удобнее, быстрее, надежнее и дешевле. Технология сложная. Как "классические", многотерминальные комплексы, так и СУБД, работающие с файл-серверами, являют собой два проявления одной и той же крайности. Роднит их то, что и прикладная логика, и логика визуализации и обработки данных перемешаны в едином приложении. Разница только в том, что в первом случае оно выполняется на одной машине, а во втором - на разных, но тоже целиком! Клиент-сервер дает возможность найти золотую середину между двумя этими точками и оптимально распределить нагрузку между компьютерами общего пользования и персональными рабочими станциями, будь то PC или Sun. Проблема в том, что географическое местоположение упомянутой золотой середины оказывается в высшей степени неопределенным. Если двухуровневая модель клиент-сервер (сервер данных & программа, написанная на 4GL) заставляет задумываться над тем, как разнести функции между двумя агентами в сети, то использование трехуровневой модели - мониторов транзакций IBM CICS или Novell Tuxedo, а также других интерфейсов серверов приложений, например SYBASE Open Server или MS Open Data Service, - подбрасывает вам третьего агента. Последние версии CICS подразумевают уже наличие четырех уровней. Таким образом, приемы, технологии и инструменты, разработанные для архитектуры клиент-сервер, позволяют добиться высокой производительности за счет более равномерного "размазывания" нагрузки между компьютерами, организуя их в "единую распределенную вычислительную среду".
Эта фраза у многих уже набила оскомину. Но только потому, что лишь проектирование и использование определенной техники программирования дает возможность добиться желаемого эффекта. В любом случае чуда не случится, и корпоративная система не сможет быть построена на дешевеньких компьютерах. "Мы хотим дать одновременный доступ пятистам пользователям к базе в сотни гигабайтов. Какой сервер баз данных - MS SQL Server, SYBASE или Oracle - вы можете посоветовать?" Причем тут сервер данных, если на всю сеть - два PC-сервера! Что я могу посоветовать, кроме машины с широкой-преширокой внутренней магистралью, большим-большим числом процессоров и системой ввода-вывода, которая называется не SCSI, а, например, ISS. И стоить будет эта радость не один десяток, а пару сотен тысяч долларов, уж не взыщите. А если не хочется думать - купите мэйнфрейм IBM, ICL или Unisys, они, правда, подороже встанут. Таким образом, при переходе на архитектуру клиент-сервер роль проектировщиков и программистов возрастает стократно. Те упущения, которые сглаживались мощностью большой машины, здесь могут заявить о себе.
Никакие спекуляции и подтасовки вам не страшны, если вы четко понимаете свои потребности на прикладном уровне. Вы не сползете в технические мелочи, которые на деле окажутся совершенно несущественны для вашей задачи. К сожалению, в большом числе случаев проектирование отступает на второй план по отношению к собственно рисованию формочек и занимает второе место не только по степени важности, но и в календарном плане работ. Сначала ("скорей-скорей") ваяется версия номер один. После того как выясняется, что полученный продукт делает непонятно что, да и эту малость делает плохо, высказывается смелая мысль: "Не лепо ли нам, братия, подумати?". Только тогда наступает второй этап - проектирование. Никто не строит дома или самолеты без чертежа. Программы - сплошь и рядом.
Меня абсолютно не радует, если клиент превозносит технологию. Даже если это технология клиент-сервер. Он не наш клиент. Он - ничей. Он надеется, что, заплатив ту или иную сумму, он заполучит нечто, которое решит все его проблемы. А "оно" только может помочь. Сегодня он ругает Clipper или Btrieve и интересуется MS/SYBASE SQL Server. Завтра он будет все то же самое говорить и об SQL Server.
Хотите снизить стоимость оборудования и его эксплуатации? Хотите быть независимы от единственного поставщика, иметь широкий выбор в инструментах? Хотите, чтобы решение, которое вы примете сегодня, не стало препятствием в завтрашнем выборе? Переходите на клиент-сервер. Только не надейтесь на спокойную жизнь. И учиться тоже придется, даже если вы убеленный сединами муж. Клиент-сервер - архитектура сложная. Так давайте работать, а детские споры типа "даст ли самбист каратисту" или же "сборет ли Microsoft IBM, a SYBASE - Oracle" оставим для ФИДО.
С Вадимом Индриковым, компания "Весть", можно связаться по телефону: (095) II 5-9713 или по адресу: bartman@vestjsc.msk.su
Вадим Индриков
