«Мир ПК»
В октябре 2001 года IBM обнародовала концепцию автономных вычислений. В ее основе лежит идея создания адаптивной ИТ-инфраструктуры, способной автоматически приспосабливаться к изменяющимся условиям
Параллели с автономной нервной системой и живыми организмами восходят к проекту IBM по созданию цифровой иммунной системы для киберпространства Digital Immune System for Cyberspace и проекту eLiza. Гораздо менее известен факт проведения Джоном фон Нейманом подобной аналогии с миром нейронов в первом публичном источнике, задавшем архитектуру современных компьютеров — First Draft on a Report on the EDVAC (30 июня 1945 года). Спустя шесть десятилетий идеи воплощения адаптивности компьютерных систем по образу и подобию живых организмов находят благодатную почву во флагманских продуктах IBM. С провозглашением концепции автономных вычислений (autonomic computing) Голубой Гигант делает важный шаг на пути перевода разработок в области искусственного интеллекта в плоскость реального бизнеса.
О том, каким образом данная концепция нашла свое воплощение в новом продукте IBM — DB2 UDB 8.2 (Stinger), рассказывает Леон Кацнельсон, директор по конкурентным технологиям при департаменте управления информацией.
С 2003 года все чаще обсуждается тема противостояния IBM Stinger (DB2 Universal Database) и Microsoft Yukon (SQL Server 2005). Говорят о том, что IBM опередила конкурента в области баз данных для платформы .Net. Так ли это?
Конечно, в определенной мере мы конкурируем с Yukon и наши разработки для .Net достаточно глубоки. Простой пример: один из важных аспектов Yukon — хранимые CLR-процедуры. Когда два-три года назад Microsoft объявила об этом, для разработчиков это считалось одним из самых главных моментов. Мы с этим согласны. Понятно, что когда разработчик занимается программированием на Visual Basic, он не хочет переходить на T-SQL. У нас, например, есть хранимые процедуры на Java, но разработчик, использующий, скажем, C#, далеко не всегда хочет переходить ради этого на Java. Поэтому мы уже сейчас даем возможность работать с хранимыми процедурами в виртуальной машине CLR, поддерживающей множество различных языков программирования.
Yukon будет иметь такие возможности в середине 2005 года. Кроме того, мы сделали полную интеграцию с Visual Studio .Net, чтобы при помощи этого продукта можно было разрабатывать подобные хранимые процедуры. В этом смысле мы конкурируем где-то со всеми СУБД на базе SQL, включая Yukon.
Разработчики не обязаны детально разбираться в DB2. Вместо этого мы пытаемся представить СУБД, так, чтобы работа с ней была понятна для разработчика в его среде. Если разработчик использует, например, Visual Studio .Net, то мы нацеливаемся на то, чтобы все операции, которые он должен выполнять в своем ежедневном рабочем цикле, выполнялись из Visual Studio .Net.
Стоит также учесть, что DB2 — единственная СУБД, для которой можно вести разработку на .Net, а сама при этом способна работать на любой платформе, включая Linux, мэйнфреймы, Windows. Другая подобная многоплатформная СУБД — это Oracle. Но средств разработки для .Net у нее почти нет.
Появились ли в Stinger новые средства для поддержки Web-сервисов?
Несмотря на то что в области СУБД все мы молимся на язык SQL, для разработчиков это «необходимое зло»: они лишь вынуждены работать на нем. Но они смотрят и на другие технологии. Например, Java-программисты хотят работать с компонентами JavaBeans. Их не интересуют хранимые процедуры в SQL. Кроме того, сейчас все более популярной становится сервис-ориентированная архитектура (Service-Oriented Architecture, SOA). И потому в этом мире многие программисты рассматривают архитектуру как создание программ через сборку определенных модулей из Web-сервисов. В DB2 мы даем возможность пользоваться этим подходом вместо SQL. Звучит непривычно. Но это реальность.
Утверждается, что в Stinger реализована поддержка автономных вычислений. В чем это заключается?
Мы стали заниматься данным направлением гораздо раньше, чем официально это объявили. У нас была инициатива eLiza, а также проект SMART (Self-Managing And Resource Tuning. — Р.Б.). Идея простая. Квалифицированные кадры в области СУБД довольно дефицитные и дорогостоящие. Мы можем помочь нашим администраторам баз данных тратить свое время на сложные задачи, а не на рутинные. В области автономных вычислений мы выделяем четыре аспекта: Self-Configuring («самонастройка»), Self-Healing («самокоррекция»), Self-Optimizing («самооптимизация») и Self-Protecting («самозащита»). В Stinger в той или иной мере воплощены эти идеи.
Средства самонастройки баз данных, имеющиеся в Stinger, пока мало известны рядовым пользователям баз данных. О какой самонастройке идет речь? Насколько в связи с этим изменяются задачи администрирования баз данных?
Например, мы можем полностью автоматизировать ежедневную работу администратора. Все, что мы просим от него, — указать временные рамки, которые он считает оптимальными для работ по поддержке. DB2 пытается вписать соответствующие процессы в это окно. Многие думают, что это просто планировщик работ, расписание. Но это не расписание. Например, DB2 решает, нужно ли вообще это делать. Другой пример — реорганизация базы данных. DB2 Stinger сам решает, надо ли ее проводить, основываясь на заданных критериях.
Здесь проходит очень зыбкая граница между пакетным выполнением по расписанию и выполнением определенных операций без участия администратора баз данных, когда система сама принимает решение. Наверное, нужны какие-то подсказки от администратора?
Наша стратегия — управление на основе политик (Policy-Based Management). Политика означает, что надо задать только параметры, а система сама подберет выход под эти параметры. Именно эти возможности мы и развиваем. То, что вы видите сейчас в Stinger, — лишь первый шаг в данном направлении.
Прагматический аспект понятен. То, что средства автономных вычислений, встроенные в Stinger, высвобождают руки администратора баз данных, хорошо. А как это достигается? В какой мере данная идея захватывает область искусственного интеллекта?
Наша задача — построение инфраструктур, а не самих приложений. Мы занимаемся инфраструктурами, которые сами себя адаптируют под приложения.
Мы не занимаемся искусственным интеллектом в том смысле, что переписываются сами программы, хотя, например, наш оптимизатор переписывает SQL-запросы в более эффективную форму, так что они после этого быстрее выполняются.
Другими словами, вы воспринимаете программу, которую написал SQL-программист, как некую спецификацию, и по ней строите оптимальную программу?
Да, именно так. И это лишь один из примеров. Вопрос в том, как сделать так, чтобы система могла сама реагировать на изменение условий. За этим стоят огромные исследования, десятки и сотни человеко-лет, затраченных на изучение этих проблем, решения с очень сложными формулами.
Но есть и проблемы, которые математически еще не решены. Я люблю надеяться на будущее, но привык все же готовиться к настоящему. Поскольку я работаю с конкурентными технологиями, то для меня это следующий квартал, следующий год.
Нам это важно, потому что выйти на рынок надо сейчас. Но при этом у нас есть целая армия исследователей, которые думают на десять лет вперед. Мы же все-таки ориентируемся на бизнес, и наша задача — это упрощение управления очень сложными системами.
Чем сложнее система, тем выше потребность в ее упрощении.
Пол Хорн, главный вице-президент IBM Research, полагает, что сложность современных ИТ-систем — это серьезный вызов. Как это ни парадоксально, чтобы избежать сложности, утверждает Хорн, надо делать еще более сложные системы, то есть сложность преодолевается через сложность. Хорн подчеркивает, что, следуя принципам автономных вычислений, системы надо еще более усложнять, но внедрять при этом элементы адаптивности. Какова ваша точка зрения?
Сложные системы порождают сложные решения для их упрощения. Он не имел в виду, что клин клином вышибают.
Чем сложнее система, тем больше необходимость в ее упрощении. При этом процесс упрощения еще более усложняет эти системы. Не знаю, согласен ли будет Хорн с моей точкой зрения: он над этим думает намного больше, чем я.
Как я понимаю, он имел в виду сложность во внутреннем исполнении, но простоту во внешнем использовании. Как только появляется адаптивная система, возникает вопрос доверия. Если администратор баз данных не понимает, что она автоматически делает, то доверие будет минимальным. Если он начнет это понимать (т.е. если она будет ему сообщать, советовать и т. п.), тогда у него возникнет ощущение, что это помощник, которому можно доверить данный участок работы.
С этим я полностью согласен. Мы ничего не прячем и раскладываем все по полочкам — что произошло, почему произошло, какие потенциальные возможности решения этого — и даем возможность администратору баз данных исполнять пробные сценарии, чтобы достичь цели.
Как бы мы ни стремились улучшить технологию, всегда остается человеческий фактор. Какой бы ни была технология, какая бы ни стояла математика за этой технологией, человек должен знать, что может довериться системе.