Подробно тема обработки данных уже обсуждалась в главе 6, а сейчас мы лишь кратко рассмотрим последние модификации в этой области. Сразу отмечу, что расширение возможностей по обработке данных в AS/400 — одно из приоритетных направлений нашей работы.
Я уже говорил, что огромный незадействованный ресурс для бизнеса многих фирм — их оперативные данные. И по мере того как наши заказчики начинают это понимать, они пытаются применить свои AS/400 соответствующим образом. В конце концов, данные это только товар; конкурентные преимущества же позволяют получить знания. Поэтому неудивительно, что хранилища данных и средства их анализа так быстро развиваются.
Самой распространенная ныне реализация хранилища данных для небольшой рабочей группы — использование отдельных серверов. На этом рынке IBM сталкивается с сильной конкуренцией других производителей. Но в случае, когда главный критерий выбора системы — возможности базы данных, корпорация чувствует себя вполне уверенно.
AS/400 оснащена первоклассной базой данных с очень широким диапазоном применения. На одном краю этого диапазона — системы AS/400 начального уровня, прямо конкурирующие с серверами и базами данных ПК. На другом — многопроцессорные конфигурации, объединяющие до 32 систем в кластере с помощью OptiConnect. Учитывая, что к каждой из таких систем можно подключить от одного до нескольких терабайтов дискового пространства, общий размер базы данных превосходит все, что только можно было вообразить себе несколько лет назад.
Ключевая и ближайшая задача IBM в этой области — повышение производительности базы данных (особенно SQL) на всем диапазоне систем. Вообще-то, «родной» интерфейс DB2/400 позволяет обеспечить более высокую производительность, нежели SQL, но поскольку все больше и больше приложений пишется для интерфейса SQL, то именно он — наша главная забота.
Другая проблема DB2/400 (как и любой другой базы данных) — обработка сложных типов данных, таких как объекты. При повсеместном переходе на использование распределенных объектов, база данных должна будет работать с этими абстрактными типами данных. Хотя крайне маловероятно, что кто-либо из основных производителей баз данных до конца столетия откажется от реляционной модели в пользу полностью объектно-ориентированной, все же нужно работать на опережение. Несмотря на то, что в данной области по-прежнему нет стандартов, организации типа OMG вносят предложения по методам хранения объектов или их компонентов в реляционной базе данных с возможностью выборки через систему управления объектно-ориентированной базой данных. IBM также рассматривает аналогичные предложения по базе DB2. Если эти предложения будут приняты, мы их реализуем.
DB2/400 будет оставаться опорой для приложений AS/400 в версии 4. В базы данных AS/400 будут внесены изменения, повышающие производительность и расширяющие функциональные возможности как больших, так и малых баз данных. В следующие несколько лет, в силу ожидаемого громадного увеличения мощности AS/400, возможно появление очень больших баз данных.
Уже рассмотренные нами новые программные технологии позволят обеспечить значительный рост производительности и емкости AS/400. В то же время, цена этого роста будет гораздо ниже, чем в прошлом. Давайте остановимся на двух основных аппаратных направлениях развития, которые позволят значительно расширить возможности старших моделей и сократить стоимость аппаратуры для всех систем серии AS/400е.
Развитие старших моделей стало основным направлением наших работ в начале 90-х. Тогда многие наши крупные заказчики «уперлись в потолок» возможностей своих AS/400. Их требования к производительности и объемам системы превосходили то, что мы могли предоставить. Эти требования и подтолкнули нас к переходу на PowerPC. С появлением систем AS/400 на базе RISC-процессоров мы смогли на какое-то время удовлетворить потребности заказчиков в новых системах старшего уровня. Но спрос на еще большие объемы и производительность не уменьшился. Нашим ответом на растущие требования должны стать возможности моделей серии AS/400е. В этом разделе мы рассмотрим два метода, с помощью которых IBM планирует достичь намеченных высот производительности: одиночные системы и кластеры.
Я всегда считал, что у автомобиля не может быть слишком много лошадиных сил, а у компьютера — слишком мощного процессора.
Кажется, я же упоминал, что люблю управлять гоночными автомобилями? Даже машина, на которой я езжу каждый день, заключает в своем двигателе Northstar (имя, которое мне всегда нравилось) 300 лошадиных сил. Мне не часто требуется столь мощный двигатель, чтобы добраться до своего офиса в IBM, но как приятно иногда «пощекотать своих лошадок» и убедиться, что все они проснулись! Так же преданно, как и мощные машины, я люблю мощные компьютеры. В моем домашнем ПК два процессора Pentium Pro. Разница в моей привязанности к мощным автомобилям и мощным компьютерам — это разница между спортивным интересом и деловой необходимостью.
Требования бизнеса к обслуживающим его приложениям на протяжении многих лет постоянно стимулируют рост мощности процессоров. Именно поэтому в серии AS/400е мы увеличили мощность процессоров примерно в пять раз. Эта тенденция сохранится и в будущем, и мы создадим еще более мощные системы и серверы AS/400е.
Несколько лет назад производительность процессора для System/38 и ранних моделей AS/400 не считалась крайне важной. Мы шутили, что Pacific — кодовое название для System/38 — является сокращением от «Performance Ain't Critical if Function Is Complete»[ 83 ]. Мы сознательно жертвовали мощностью в пользу функциональности, зная, что, в конце концов, технологический прогресс приведет нас и к оптимальной производительности. Как показало время, такое решение было верным: сегодня у AS/400 есть и то, и другое.
К тому же ранние системы использовались для приложений интерактивной обработки, где производительность процессора менее важна, чем производительность ввода-вывода. В главе 10 мы рассмотрели, как на протяжении многих лет велась оптимизация AS/400 для достижения выдающейся производительности ввода-вывода.
Архитектура AS/400 также уменьшала потребность в высокопроизводительном процессоре. В главах 8 и 9 говорилось, что одноуровневая память и эффективная структура задач AS/400 делают ненужным выполнение ОС многих процессорных команд, необходимых для тех же самых приложений на других компьютерах. Также было отмечено, что благодаря постоянной одноуровневой памяти AS/400 выполняет меньше команд и меньше обращений к диску при работе с объектами. Если команду не нужно выполнять, то это вполне компенсирует недостаток производительности процессора.
По сравнению с интерактивными приложениями, большинство новых приложений для AS/400 требуют большей мощности процессора. Когда в начале 90-х наметился переход к клиент-серверным вычислениям, приложения AS/400 стали работать более интенсивно. Серверные модели были одним из способов обеспечения поддержки этой интенсивности. Другим способом стала технология PowerPC.
Технология PowerPC лежит в основе повышения производительности для версии 4. (Этот процессор, а
