Нам необходимо научиться управлять данными прежде, чем они начнут управлять нами
|
| Пат Селинджер: «Компьютерные системы должны «уметь» саморегулироваться, самонастраиваться» |
Какое именно значение в IBM вкладывают в концепцию autonomic computing?
Впервые я услышала это словосочетание от Алана Ганека, который недавно возглавил в корпорации подразделение, специализирующееся на «вычислениях с самообслуживанием». По его словам, подобную организацию вычислений можно сравнить с функциями, которую выполняет в организме человека нервная система. Она заставляет мое сердце биться даже тогда, когда я об этом не думаю. Хотелось, чтобы именно таким образом работала ваша вычислительная система.
Какую роль системы управления базами данных играют в стратегии autonomic computing корпорации IBM?
СУБД, по существу, — это часть операционной системы, часть языка программирования и компилятора, часть множества различных компонентов системы. Единственная вещь, к которой СУБД не имеют непосредственного отношения, — это аппаратное обеспечение. Но у нас есть примеры реализации вычислений с самообслуживанием на аппаратном уровне, когда AS/400 звонит домой своему системному администратору и сообщает о сбоях в своей работе. Когда компьютер обнаруживает, что ему приходится выполнять слишком много повторных обращений к диску, он считает, что с диском что-то случилось, и посылает телефонное сообщение в сервисную службу IBM. В зависимости от того, какое решение принимает клиент, либо устанавливается новый диск, либо к нему в офис приезжает специалист по сервису, либо предпринимаются иные действия.
Какого рода самообслуживание присуще DB2?
Технология LEO (LEarning Optimizer, «технология изучения запросов») «равняется» на данные. Прежде всего, мы собираем статистику об элементах данных. LEO позволяет заметить некоторую корреляцию, определенные закономерности, которые связывают различные фрагменты информации. Вот пример. В США около 40 тыс. почтовых индексов и 50 штатов. Почтовый индекс нашей лаборатории — 95141. Мы знаем, что такой индекс есть только в Калифорнии. И мы знаем, что если запрос начинается с 95141, то дополнительное указание штата Калифорния ничего не дает. Когда вы замечаете такого рода детали, вы можете это поставить на заметку и использовать для того, чтобы лучше обрабатывать подобные запросы в дальнейшем. Вот пример изучения данных, на которое способна технология LEO. Конечно же, существуют значительно более сложные взаимосвязи, которые вы не в состоянии просто записать, но которые выявляются с помощью средств добычи данных (data mining). Такая информация оказывается чрезвычайно полезной, поскольку для каждого конкретного запроса существуют предпочтительные пути доступа к данным. Когда задан другой вопрос, имеющий примерно ту же самую форму, может существовать абсолютно иной путь доступа к данным, который обладает реальными преимуществами.
Компании, специализирующиеся в области СУБД, последние несколько лет активно обсуждают идею самовосстанавливающихся баз данных. В IBM речь ведут о самовосстанавливающихся серверах. Итак, все силы направлены на достижение одной фантастической цели?
Мы уже сейчас испытываем нехватку квалифицированных ИТ-специалистов, а учитывая скорость накопления данных, необходимо предпринимать срочные шаги, избавляющие людей от перегрузки. Для этого следует менять компьютерные системы, делать их самообслуживаемыми, более «ответственными» за собственное поведение и те события, которые возникают в системе. Они должны «уметь» саморегулироваться, самонастраиваться. Это позволит освободить администраторов баз данных от рутины, чтобы они выполняли работу, которая действительно требует человеческого интеллекта и человеческого таланта.
Итак, все больше людей плохо разбираются в имеющихся у них данных, все меньше людей становятся специалистами по базам данных. Но ведь объем данных увеличивается... Что же делать?
Да, здесь есть и еще один аспект. Принимая во внимание, что нам в перспективе придется иметь дело с терабайтными базами данных, а потом и с петабайтными, следует отдавать себе отчет в том, что данные, с которыми сейчас работают администраторы, и вопросы, которые сейчас задают пользователи, в будущем станут совсем другими. И в этом меняющемся мире все чаще и чаще будут появляться запросы, созданные людьми, не искушенными в области ИТ. Один из наших клиентов разрешает своим сотрудникам, занимающимся прямой рекламной рассылкой, получать доступ к базе данных и задавать любые вопросы. Они могут использовать данные, но не знают, что такое SQL, представления не имеют, как организованы данные. Они могут задавать достаточно серьезные вопросы, однако иногда делают ошибки. Они вовсе не спешат отправляться на курсы по SQL, чтобы научиться писать запросы «профессионально». Поэтому приходится постоянно работать над тем, чтобы отвечать на запросы среднего (или даже ниже среднего) уровня, делая это с помощью нашей технологии переписывания запросов, оптимизации запросов с учетом весовых коэффициентов, а теперь и с помощью LEO. Если проанализировать ситуацию в этом контексте, то становится ясно, что люди все меньше и меньше представляют себе, какие, собственно, данные у них имеются, и все меньше и меньше специалистов по базам данных хотят работать с огромными объемами информации. Именно на такие перспективы мы рассчитываем и у нас есть несколько инициатив, относящихся к вычислениям с самообслуживанием. Многие из них связаны с базами данных — но не все. Это лишь один из компонентов.
Оптимизация запросов может дать конкурентные преимущества для предприятий?
С нашей точки зрения, основное назначение LEO состоит в том, чтобы настраивать базу данных, уменьшая число операций, которые необходимо делать вручную. Так что мы преследуем цель сократить стоимость владения, время выпуска продукта на рынок, поскольку, если мне требуется дополнительный человеко-год для того, чтобы выпустить приложение и дать людям возможность реально использовать его в работе, то я не смогу так же быстро реагировать на изменение ситуации на рынке, как мои конкуренты. Поэтому компания сможет работать более эффективно, если удастся сократить объем ручного труда, связанного с внедрением приложения.
Кроме того, существует множество способов мониторинга, позволяющих анализировать уровень использования. К примеру, такие функции имеются сейчас в DB2, где можно потребовать обеспечить некоторую степень параллелизма. То есть сказать: «Мистер Optimizer, я не намерен проводить никаких экспериментов и тратить свои силы на то, чтобы выяснить, что лучше в данном случае — две или восемь степеней параллелизма. Я говорю ?некоторая? и предлагаю вам самому выбрать». Все, что мы делаем в ядре базы данных, — это смотрим на системную среду, на запрос, на данные и решаем, какова лучшая степень параллелизма.
Насколько гибко такое решение?
Абсолютно. Вы можете продекларировать эту степень параллелизма на любом уровне: указать «для этого запроса», или «для этого приложения», или «для этой базы данных». Вероятно, в большинстве ситуаций мало кто станет указывать «для этой базы данных», намного чаще будет использоваться «для этого запроса» и «для этого приложения». Классический пример — загрузка базы данных. Вы можете указать, что вам требуется «некоторая степень параллелизма» для загрузки базы данных, и выбрать приемлемое число агентов, выполняющих для вас загрузку. Это будет зависеть от конфигурации диска, числа процессоров на вашей машине и других параметров.
Когда же наконец появится LEO?
Мы считаем, что результаты, которых удалось добиться при работе с LEO в рамках исследовательского проекта, нельзя будет использовать прямо завтра. Скорее всего, это произойдет в ближайшие три года.