Технологическое лидерство DB2

Технологическое лидерство DB2

Автор: Блэр Кеннет Адамач (Blair Kenneth Adamache), менеджер подразделения DB2 Service, DB2 VM/VSE Development  с помощью Selinger, Huras, Lohman, Lightstone, Pirahesh, O’Connell, Ang, Rizvi, Eaton, Winer, Rielau, Sheffield, Baklarz и десятков других профессионалов в области программного обеспечения. Настоящий документ описывает решения DB2 для Unix и Windows начиная с 1995 года вплоть до июня 2001 г. и рассматривает ряд не соответствующих действительности утверждений Oracle об этих решениях  IBM. Результаты тестов приведены по состоянию на 16 июня 2001 г. Если вы читаете эту статью позднее, то, возможно, результаты старых тестов на соответствующих сайтах были уже заменены новыми.

Помните 1996 год? Тогда в индустрии были отдельные базы данных для OLTP и поддержки принятия решений (DSS), а Билл Клинтон выиграл выборы с имиджем раскаявшегося грешника. Компания Oracle помнит 1996 год лучше, чем многие из нас - она до сих пор живет в этом году: тогда для OLTP использовались машины архитектуры SMP, для DSS - машины архитектуры MPP, и практически не было СУБД и топологий аппаратного обеспечения, которые были бы пригодны для обеих целей. Последние нападки Oracle на DB2 обнаружили, что представления их авторов застыли на уровне 1996 года.  На самом деле ограничены не возможности применения DB2, а представления Oracle о том, какой должна быть СУБД. В некоторых случаях заявления адептов Oracle просто не соответствуют действительности: например, составители хвалебного отзыва об Oracle 9i полностью игнорируют тот факт, что DB2 поддерживает шифрование данных и паролей при работе на серверных платформах других разработчиков, таких, как HP-UX, Linux, Solaris и Windows, а также поддерживает аудит более 30 различных типов объектов. Шифрование паролей и аудит имеются в DB2 начиная с 1998 года. Шифрование данных появилось в версии DB2 7.2. Приложениям распределенной DB2 EEE не требуется выполнять двухэтапную фиксацию при обработке операторов INSERT, UPDATE или DELETE: DB2 обеспечивает целостность транзакций, и двухэтапная фиксация в DB2 EEE и DB2 Parallel Edition стала ненужной с 1995 и 1997 года соответственно.

Возможно, что перекладывание на приложение работы, которую должна выполнять база данных, и допустимо для некоторых СУБД. Однако разработчики DB2 исходили из того, что все механизмы выборки должны быть скрыты глубоко в ядре базы данных, чтобы все пользователи, приложения и данные могли использовать для непосредственной работы с данными самые лучшие алгоритмы, написанные экспертами; благодаря этому пользователи могут сосредоточиться на бизнесе, программисты - на задачах, выполняемых приложениями, а администраторы баз данных могут с чистой совестью заниматься новыми проектами, вместо того чтобы тратить время на настройку приложений вчерашнего дня.  Это означает, что оптимизатор DB2, а не программист SQL, выбирает индекс, который должен использовать запрос; DB2 управляет блокировкой, устраняя для приложений необходимость соперничать за доступ к строке данных; DB2 самостоятельно определяет, сколько ресурсов требуется каждому оператору SQL.

Преимущества масштабирования, предоставляемые кластерами

Почему в DB2 делается такой акцент на кластеры? Потому что возможность объединять компьютеры в кластер, предоставляя тем самым дополнительную мощность для программного обеспечения, позволяет вашему бизнесу выйти за рамки самого мощного в мире одиночного SMP-сервера. В 2001 году были опубликованы результаты всего спектра тестов TPC (TPC-C, H and W) для DB2 на кластерах SMP-серверов, машинах NUMA и больших SMP-серверах: каждый тест был проведен на каждой платформе.  Sun Microsystems продает серверы с 64 процессорами, а архитектура Hewlett Packard позволяет увеличить число процессоров до 128, в то время как DB2 работает у наших клиентов на кластерах, насчитывающих в общей сложности свыше 200 CPU. Sun прекрасно понимает возможности, открываемые подобными системами (помните их рекламный слоган «Сеть - это компьютер»?). Microsoft тоже понимает это: она  публикует результаты тестов TPC-C для кластерных систем - в точности так же, как делает подразделение IBM DB2, и предоставляет для тестов TPC-C системы DB2 на кластерах под управлением Windows. Intel тоже активно действует в этом направлении: в 1998 году эта компания выбрала DB2 для демонстрации возможностей своей архитектуры виртуального интерфейса (Virtual Interface Architecture, VI). Начиная с середины 90-х годов, появилось несколько великолепных программных пакетов для поддержки кластеров: IBM HACMP (High Availability Cluster Multi-Processing), Veritas Cluster Server, Sun Cluster, Microsoft Cluster Server: разработчики этих решений прекрасно осознают, что когда база данных разрастается и ей становится мало 24-64 процессоров, не следует искусственно разделять ее, а лучше добавить новый компьютер. Эта архитектура может расти вместе с вашим бизнесом, а не ограничивает его возможности, как это было в 1996 году.

Время, назад!

       DB2 вышла в лидеры индустрии в 1995 и 1996 годах (не говоря уже обо всем промежутке времени с 1981 по 2001 год): она стала первой СУБД, поддерживающей JDBC, и первой СУБД, для которой стали публиковаться результаты тестов TPC-D. Уже в версии 1 появилась поддержка AIX, HP, Solaris и NT, а версия DB2 v2.1.2 вышла в 1996 году одновременно на всех перечисленных платформах - к тому же это была первая СУБД, которая поддерживала хранимые процедуры и пользовательские функции, написанные на Java.  Для DB2 такое положение вещей типично, оно отражает  традицию технологического лидерства компании IBM: в портфеле ее достижений - разработка концепции реляционных систем управления базами данных (СУРБД), языка SQL, первая коммерческая СУРБД (1981), первая реализация рекурсии в SQL, первый надежный оптимизатор для Unix, работающий по принципу анализа стоимости затрат запроса (1995), первая СУБД, поддерживающая SQLJ/Java, первая версия для Linux, первые тесты TPC для Linux. В то же время Oracle 9i, по сути, мало отличается от Oracle 7.3, как явствует из сравнения пресс-релизов, выпущенных соответственно в 1996 и 2001 годах: «Oracle 7 Parallel Server распространяет возможности надежной и масштабируемой работы Oracle7 на приложения для оперативной обработки транзакций и поддержки принятия решений … Oracle 7 Parallel Server эффективно осуществляет координацию оперативной обработки транзакций между узлами, образуя единый вычислительный ресурс … Технология параллельного управления кэшем, реализованная в Oracle 7 Parallel Server, обеспечивает непревзойденный уровень оптимизации производительности для ваших кластерных систем”. (Источник: информационный отчет Oracle WhitePaper on Oracle V7.3, 1996 г.)

       В Oracle 9i к этому добавляется нечто под названием «Cache Fusion»: «Архитектура кластерных баз данных Oracle Cache Fusion - это новая архитектура общего кэша, которая позволяет преодолеть ограничения, свойственные традиционным методам общего доступа к дискам … Cache Fusion предоставляет возможность гибкого и простого масштабирования для приложений электронного бизнеса». (Источник: информационный отчет Oracle WhitePaper on Oracle 9i, 2000 г.)

Рассмотрим несколько особенностей DB2, в которых проявляется технологическое лидерство IBM:

Как часто случается, чтобы разработчик, пятнадцать лет работавший над проектом, начал новый проект с нуля для того, чтобы реализовать все уроки и практические наработки, полученные в ходе предыдущей работы? Создатели оптимизатора затрат DB2 для OS/390, рабочей лошадки информационной эпохи, в конце 80-х годов начали работу в Unix с чистого листа.  Они взяли все лучшее из DB2 для OS/390 и объединили его с принципом работы оптимизатора, основанным на технологии переписывания запросов Query Rewrite, которая была разработана после того, как первое поколение программистов, работавших с реляционными СУБД, потратили десять лет, пытаясь научить разработчиков приложений писать эффективный код на SQL. Query Rewrite автоматически преобразует запросы, созданные пользователем, в более простой для оптимизации формат: «Из лягушек - в принцы». Технология Query Rewrite стала краеугольным камнем философии разделения труда между СУБД и пользователем: пользователь создает запрос, а СУБД определяет наилучший путь к данным и выполняет все математические действия с ними, которые пользователь указал в условии WHERE. Группа талантливых разработчиков оптимизатора написала компилятор и оптимизатор SQL нового поколения на языке C++, так как современные компиляторы C++ для Windows, AIX и Solaris обеспечивают более высокую производительность исполнимого кода по сравнению с обычным С. 

Оптимизаторы, основанные на правилах, имеют ряд ограничений: они априори предполагают, что распределения данных являются однородными или что применение индексов всегда повышает производительность.  Оптимизатор DB2 работает лучше, так как анализирует больше информации: в частности, он учитывает количество процессоров в системе SMP, количество систем SMP в кластере, скорость диска и процессора, а также неоднородность видов данных. Оптимизатор DB2 не использует подсказки (в DB2 оператор SELECT вообще не содержит параметр HINT). Работать с DB2 всегда просто и легко - мы объявили автоматический выбор правильной схемы обработки запросов приоритетной целью проекта в самом начале разработки первой версии DB2 UDB и с тех пор не прекращаем работу в этом направлении. Назовем еще несколько характеристик оптимизатора запросов DB2:

Современная технология DB2 не замыкается на битах и байтах.  Любой администратор СУБД может нормализовать данные, но кто знает, какие индексы следует создавать? DB2 содержит графический мастер индексов с элементами искусственного интеллекта,  который выясняет у пользователя характер рабочей нагрузки и дает рекомендации о том, какие индексы следует создать (и какие из имеющихся индексов не нужны). Мастер умеет как автоматически оценивать рабочие нагрузки системы, так и анализировать данные о рабочей нагрузке, полученные от пользователя. Разработанный на основе новейших технологий, некоторые из которых стали результатом сотрудничества с исследовательским подразделением IBM, мастер использует схемы, выбранные оптимизатором запросов, так что рекомендованные им индексы являются наилучшими с точки зрения оптимизатора.  А когда система индексов построена, возникает новая проблема - распределение памяти между приложениями DB2, процессами сортировки данных и пулом буферов. Здесь вам поможет мастер производительности DB2, который анализирует 40 главных параметров конфигурации DB2.

Полная поддержка SMP свойственна не только оптимизатору DB2. В отличие от СУБД для Unix 80-х годов, которые возникли в однопроцессорном мире и для которых поддержка SMP была во многом похожа на прививку для саженца, DB2 с самого начала разрабатывалась для сред SMP, комплексов MPP из сотен узлов, кластеров SMP и систем NUMA. Такие утилиты DB2, как Backup, Restore и Load, динамически анализируют возможности всей системы, используя все возможности параллельной архитектуры процессоров, большого объема памяти и асинхронного ввода-вывода. Утилита Load в DB2 «магическим образом» определяет доступные ресурсы памяти, параллелизм ввода-вывода и нужный уровень параллелизма SMP; она автоматически анализирует характеристики таблиц, свободный объем памяти, число контейнеров таблиц и число циклов активных CPU в системе. Load также динамически определяет способы обработки системы индексов (следует ли просто добавить новые значения индексов или же полностью воссоздать всю систему индексов при загрузке). Load использует 100% выделенных ей ресурсов, обеспечивая возможность эффективного масштабирования. Отметим, что утилиты являются важнейшими средствами поддержки базы данных - они выполняют для СУБД те же функции, что и коммунальные службы в современном мегаполисе.

Следующая проблема: как сделать так, чтобы ни один пользователь не мог монополизировать слишком много ресурсов?  Для этого служат средства DB2 Governor и DB2 Query Patroller. Они автоматически отслеживают распределение ресурсов между группами приложений и применяют политики управления ресурсами. Благодаря этому становится возможной автоматическая защита систем DB2 от выхода «аппетитов» приложений из-под контроля и автоматическое распределение ресурсов, причем администраторы БД по-прежнему могут определять собственные политики для обработки специфических рабочих нагрузок. DB2 Governor позволяет администратору БД отслеживать и контролировать поведение приложений в базе данных, а также определять частоту, с которой Governor будет проверять и применять установленные администратором правила.  Эти правила позволяют устанавливать лимиты выделения системных ресурсов (CPU, блокировки, время обработки логических единиц работы, время простоя, число выделенных или обработанных строк и т.п.) для отдельных приложений и пользователей, а также указывать, какие меры следует принять при превышении этих лимитов. В числе возможных мер - изменение приоритета для агента данного приложения и принудительное завершение работы приложения, что позволяет гарантировать справедливое распределение ресурсов между всеми классами приложений. Governor ведет журнал своих действий, из которого администратор может делать выборки по запросу. DB2 Governor представляет собой эффективный метод применения заранее продуманных администратором политик управления, обеспечивающих честное и полное распределение ресурсов и не позволяющих одному приложению монополизировать систему.

Query Patroller - это «полиция» администратора, которая позволяет перехватывать запросы SQL и определять, какие пользователи нарушают правила, а каким следует везде предоставлять «зеленую улицу». Кроме того, перехват SQL - очень полезное средство для выяснения того, как используется ваше информационное хранилище: эта информация становится ценными данными для Мастера индексов. DB2 Query Patroller принимает запросы SQL и ODBC, поступающие от клиентов, анализирует их и затем динамически устанавливает приоритеты, планирует и распределяет рабочую нагрузку по всем системным ресурсам DB2. Такой подход обеспечивает оптимальное использование ресурсов для каждого запроса без вмешательства администратора.

Некоторые поставщики СУБД полагают, что смешивание рабочих нагрузок OLTP и DSS - это то же самое, что смешивание бензина с водой.  В IBM придерживаются другого мнения. Когда в 1997 году DB2 Parallel Edition вошла в состав DB2 Universal Database, и она стала единственной СУБД в мире, для которой выполнялись одновременно тесты TPC-C и TPC-D, группа разработчиков DB2 исходила из того, что пользователи иногда выполняют транзакции, связанные с поддержкой принятия решений, а также направляют эпизодические запросы к базам данных OLTP. Поэтому мы добавили в DB2 интеллектуальные средства для поддержки подобных действий.  Как лучше всего сохранить изменения в базе данных объемом в три терабайта, если были изменены четыре строки?  Для этого следует выполнить автоматическое инкрементное резервное копирование DB2, которое создаст резервную копию только тех страниц базы данных, которые изменились с момента последнего резервного копирования всего хранилища данных.

IBM разработала архитектуру распределенных реляционных баз данных (Distributed Relational Database Architecture, DRDA - технический стандарт Open Group DRDA версии 2 для того, чтобы СУБД, работающие на различных платформах, могли направлять друг другу запросы.  В 1996 году появился продукт DB2 Datajoiner, который позволял объединять в одном операторе SQL таблицы Oracle, SQL Server и DB2, работая под управлением оптимизатора DB2. Поддерживаются также объединенные операторы INSERT, UPDATE и DELETE, а также полная репликация из гетерогенных источников данных и в такие источники в виде «как есть» - превосходная возможность для заказчиков, осознавших необходимость переноса данных из сред Sybase и Oracle в DB2. Datajoiner теперь входит в состав ядра баз данных DB2, вместе с драйверами DB2 Relational Connect для Oracle, Sybase и Microsoft SQL Server в средах Windows, AIX, Solaris и Linux. Какие преимущества дает построение схемы в DB2 Optimizer до выполнения запроса в гетерогенных источниках данных? Это может означать повышение производительности, так как DB2 Relational Connect получает возможность преобразовать неумело составленные запросы SQL к более оптимальному виду с помощью DB2 Query Rewrite. DB2 передает части плана доступа как усовершенствованный SQL, который выполняется на удаленной базе данных, вместо того чтобы неэффективно делать те же соединения локально. Разработчики называют это «передачей функций во избежание передачи данных»; такая система помогает увеличить скорость работы DB2 EEE. Передача функций (например, WHERE STATE IN (’TEXAS’)) обеспечивает минимум затрат. Передача данных же очень дорога: не стоит передавать все строки на один узел для обработки запросов типа STATE NOT IN (’TEXAS’).  В DB2 теперь появилось средство DiscoveryLink, выводящее эту технологию на новый уровень: оно позволяет DB2 обращаться к нереляционным данным - таким, как результаты объемы клинических исследований в биологии/биотехнологии.

3) Поддержка Web в DB2

DB2 использовала возможности Web с 1996 года, когда появился продукт DB2www (теперь он называется Net.Data), обеспечивавший интерфейс HTML и CGI для данных DB2. Затем последовала поддержка JDBC и хранимых процедур Java, причем поддержка SQLJ и DB2 были интегрированы в Websphere в 1998 году.  DB2 является лидером тестов TPC-W, демонстрируя уровень 100 000 элементов. Готова ли DB2 к работе в Web? Пользователи DB2 применяют XML с 1996 года, и IBM сыграла ключевую роль в разработке синтаксического анализатора XML для проекта Apache XML.  Кроме того, DB2 стала первой реляционной СУБД, у которой вышла бета-версия для работы в среде Linux, которая обеспечивает поддержку кластеров Linux для повышения масштабируемости и надежности, а также возможность работы в среде Linux для OS/390. Ценовая политика DB2 также тесно связана с динамикой Интернета и интрасетей: доступ через Web для всех предложений DB2 Enterprise неограниченный, а плата за пользователей, работающих с продуктами через интрасеть, существенно ниже платы за именованных пользователей в нашем предложении версии DB2 Workgroup.

DB2 стала первой СУБД, которая сочетает высокую скорость обработки в памяти, необходимую для поиска в Интернете, с возможностями обработки сложных вхождений текста, а также с масштабируемостью и доступностью, присущими реляционной СУБД. Сложные текстовые объекты обрабатываются с помощью типа данных CLOB, реализованного в DB2. Здесь подход DB2 к основным функциям окупается в полной мере: в то время как примитивные СУБД накладывают жесткие ограничения на объекты LOB (Large Objects - большие объекты), в DB2 они просто выделены в отдельный тип данных, и большинство правил, применимых к другим типам данных, применимы и к LOB: DB2 поддерживает несколько объектов LOB (Binary LOB и Character LOB) в каждой строке таблицы, стандартные функции умеют работать с LOB, и триггеры DB2 могут запускать обработку LOB.

5) Масштабирование и кластеризация

В настоящее время (на 14 июня 2001 г.) в десятке лучших результатов теста TPC-C продукт Oracle занимает одно, восьмое место. Может быть конкуренты Oracle победили его просто за счет более мощной аппаратной платформы? Не обязательно. Хотя шесть из семи систем, обошедших Oracle, являются кластерными, каждая из них имеет более низкую стоимость транзакции ($/tpmC) и более высокую скорость (http://www.tpc.org/tpcc/ results/tpcc_perf_results.asp). DB2 - единствен­ная СУБД, участвующая в тестах TPC-C и  TPC-W как на кластерных, так и на отдельных машинах, а также участвующая в тестах TPC-H как для SMP-платформ среднего размера, так и для крупных кластеров. В портфеле DB2 следующие достижения:

Выберите свои данные, нужный тип аппаратной платформы (NUMA, автономный сервер SMP, кластер SMP, MPP), нужный тип рабочей нагрузки (OLTP, поддержка принятия решений или электронная коммерция) - DB2 всегда выполнит свою работу  за умеренную и предсказуемую цену. Архитектура DB2 масштабируется для любых топологий SMP, SMP-кластеров, NUMA и MPP. А где результаты Oracle для кластеров? Где вообще результаты тестов TPC для Oracle?  Посетите сайт http://www.tpc.org и получите ответ сами.

6) Лидерство в развитии и использовании стандартов

Технологические новшества, реализованные в DB2, стали основой принятого в настоящее время стандарта SQL99. IBM была лидером по количеству принятых предложений за каждый год разработки SQL99, с 1993 по 1999. Стандарты исключительно важны: после того, как ваш бизнес благодаря DB2 придет к процветанию, вы сможете съесть своих конкурентов и подробно разобраться в том, как неверные решения в вопросе выбора СУБД привели их к краху. DB2 соответствует перечисленным ниже стандартам и использовалась при их разработке:

Поддержка стандартов - это не только дань законопослушанию, но и нечто большее: стандарты помогают обеспечить целостность данных. Насколько мне известно (однако лучше выясните это в Oracle самостоятельно), в модели блокировок Oracle приложения сами выполняют сериализацию (т.е. разработчик приложения должен сам включать блокировку и принимать локальные решения о блокировке - в DB2 они принимаются глобально). Администратор БД выделяет для этого место в виде СЕГМЕНТОВ ОТКАТА (rollback segment).  В Oracle 9i они уже не являются необходимыми, но похоже, в тестах 3 TB TPC-H для Oracle 9i они активно использовались. В полной распечатке теста я насчитал четырнадцать (14) страниц текста «CREATE ROLLBACK SEGMENT…». Это наводит нас на мысль о различии в принципиальном подходе к СУБД.  По мнению автора статьи на сайте Oracle, модель блокировок в Oracle может создать более интенсивную нагрузку для администратора базы данных, причем ответственность за целостность данных возлагается на администратора БД и разработчика приложения. В то же время подход DB2 (как и ANSI - Национального института стандартов США) заключается в том, что управление одновременным доступом к данным - это задача СУБД. Приложение сообщает DB2, что ему требуется, и DB2 предоставляет данные самым быстрым способом, не возлагая эту работу на разработчика приложения. Это мы считаем реалистическим механизмом блокировок. Администраторам БД Oracle придется выучить перечисленные ниже параметры конфигурации. Некоторые из них Oracle использовала в тесте 3 TB TPC-H Solaris:

       CLEANUP_ROLLBACK_ENTRIES

                                 DELAYED_LOGGING_BLOCK_CLEANOUTS

                                 DML_LOCKS

                                 LM_LOCKS

                                 MAX_ROLLBACK_SEGMENTS

                                 ROLLBACK_SEGMENTS

                                 ROW_LOCKING

                                 SERIALIZABLE

                                 TRANSACTIONS

                                 TRANSACTIONS_PER_ROLLBACK_SEGMENT

7) Высокая доступность/Непрерывная работа

Oracle 9i использует архитектуру общей расделяемой памяти. Другие популярные СУБД для сред Unix и Windows (DB2, Informix, Microsoft) вообще не используют общие ресурсы. В Oracle узлы имеют общий доступ к дискам. Платой за это является то, что в фоновом режиме непрерывно выполняется DLM (Distributed Lock Manager, распределенный менеджер блокировок). В DB2 нет дополнительного уровня, он не нужен: каждый узел является владельцем своих дисков. Диски являются общедоступными, а не общими (точно так же, как игрушки в детской песочнице общедоступны для игр, но они практически всегда чьи-то, а не общие). При отказе узла DB2 активизируется второй узел для дисков с двумя владельцами, и IP-адрес отказавшего узла присваивается резервному узлу. Приложения, поддерживающие соединения с отказавшим узлом, могут указывать тот же самый IP-адрес для своих серверов.

8) Научно-исследовательские достижения

DB2 была лидером по количеству патентов на протяжении всей истории своего развития, в том числе и в последние пять лет. IBM разрабатывала, патентовала и применяла в DB2 самые разнообразные новые технологии: от индексов, позволяющих проводить сканирование в обоих направлениях, до возможности проверять каждый сектор диска при постраничном вводе-выводе. Рассмотрим, например, операцию соединения с хэшированием в DB2: операция соединения автоматически адаптируется к динамическим ограничениям на память, причем соединение разбивается на более мелкие хэш-группы по современному алгоритму гибридного соединения с хэшированием (Hybrid Hash Join). Другой пример: мета-оптимизация DB2 автоматически адаптирует при необходимости класс оптимизации оптимизатора DB2, учитывая ресурсы системы и сложность запроса. В DB2 автоматизированы многие функции (например, создание индексов битовых карт), причем они выполняются только тогда, когда это действительно необходимо. Пользователю не нужно создавать или предоставлять оптимизатору подсказку для битовой карты до обработки запроса. Третий пример: DB2 содержит запатентованную технологию гарантированного обнаружения данных, поврежденных вследствие незавершенного ввода-вывода, при чтении диска. Все это выполняется автоматически. 

9) «Умные» СУБД облегчают жизнь администратора

IBM постоянно стремится к упрочению своего лидерства в области технологий самоуправления баз данных. Одним из проявлений этой тенденции стала инициатива SMART (Self Managing And Resource Tuning Databases - Самоуправляемые базы данных с автоматической настройкой ресурсов). SMART - это не отдельный продукт и не отдельная функция. Это набор функций, объединенных общим представлением о том, каким должно быть в идеале управление базами данных. Мы опускаем планку сложности для пользователей, в то время как другие компании поднимают ее. Представьте себе мир баз данных будущего, которые будут полностью автоматически оптимизироваться, прекрасно работать сразу же после установки, а если что-то случится - система тут же сообщит об этом администратору по электронной почте или на пейджер вместе с указанием рекомендуемых действий. Конечно, это будущее настанет не завтра и не послезавтра, но IBM является лидером в направлении этого идеала. На этом пути встретятся серьезные проблемы, которые IBM сможет эффективно разрешить, благодаря своей огромной базе интеллектуальных талантов в научно-исследовательской области и обширным связям с академической наукой. Прежде всего эти проблемы будут связаны с разработкой операций, искусственным интеллектом и проектированием сложных баз данных.

10) Эволюция СУБД - Управление всеми типами данных

Какой бы год вы ни назвали, можно перечислить инновации и признаки лидерства IBM DB2 в этом году. После разработки прототипа System R в 70-х годах и начала коммерческих поставок SQL/DS и DB2 для MVS в начале 80-х, новое поколение разработчиков DB2 реализовало следующие функции и возможности:

1989: IBM принимает DB2 в качестве основы для своих коммерческих продуктов по управлению информационным наполнением и документооборотом - изначально DB2 с ImagePlus для MVS.  Позднее появились продукты IBM Content Manager для OS/2 (1991) и Windows (1993).

1993: Выход DB2 для AIX версии 1.

1994: DB2 Parallel Edition в 1994 принята на вооружение крупнейшими табачными компаниями мира.  Кроме того, в этом же году начались массовые поставки DB2/HP v1.

 

1995: DB2 стала первой в мире СУБД, для которой стали публиковаться результаты тестов TPC-D (первой для Unix (1995) и первой для NT (1996)).

1996: DB2 стала первой в мире СУРБД с поддержкой JDBC, хранимых процедур Java и пользовательских функций Java. DB2 установила рекорд соотношения цена/ производительность для Unix в тесте TPC-C на платформе DB2/Solaris.

1997: DB2 Universal Database: успешная комбинация параллельной СУБД с объектно-реляционной системой управления базами данных. Собственная поддержка OLAP (cube и rollup) в ядре СУБД. Параллельная обработка запросов внутри раздела и в нескольких разделах.

 

1998: В DB2 добавлена поддержка SQLJ (v5.2.0: сентябрь 1998).  Благодаря DB2 Datalinks Manager в DB2 появился специальный тип данных URL. DB2 теперь осуществляет реляционное управление типизированными таблицами, типами строк и иерархиями таблиц. Переработан механизм интерактивных индексов.  Первая кластерная СУБД для Windows. Бета-версия DB2 для Linux появилась в октябре 1998 г.

 

1999:  Начало массовых поставок DB2/Linux.  Собственная поддержка многих функций OLAP в ядре СУРБД: стандартное отклонение, функции rownum, top, rank.

 

2000: Поддержка кластеров Linux в DB2, поддержка DB2 Linux/390, демонстрация работы DB2 под 64-разрядной версией Linux с SAP на платформе Intel IA_64. 2000-2001 годы ознаменовали собой дебют массового применения XML - см. выдержку из статьи Тимоти Дайка (Timothy Dyck) в еженедельнике eweek:

“Службы XML глубже проникают на территорию баз данных

Тимоти Дайк, eweek № 1, вып. 19

……IBM пропагандирует Extensible Markup Language с тем же пылом и страстью по типу «Где же это было всю мою предыдущую жизнь?!», как до того Java. … IBM и Microsoft далеко опережают все остальные компании в деле разработки продуктов на базе XML и SOAP.”

Выводы

Некоторые компании, работающие в области информационных технологий, очень любят, выпустив новую версию программного обеспечения, голословно объявить, что «битва титанов» выиграна, но давайте проверим факты.   Вероятно, не все в победных реляциях окажется правдой. Что нового появилось в Oracle 9i? Судите сами. Рассмотрим выделение памяти на основе размера запроса: в DB2 выделение памяти на основе размера запроса для пулов буферов и компилятора запросов существует начиная с 1995 года. DB2 уже несколько лет содержит инструменты автоматического управления: DB2 Governor появился в 1995 году, а Query Patroller - в 1998. Governor и Query Patroller могут назначать приоритеты различным приложениям и пользователям, а также динамически изменять правила и приоритеты во время выполнения.  В частности, Governor позволяет администратору БД устанавливать лимиты ресурсов - таких, как CPU, считываемые строки и удерживаемые блокировки, и может изменять приоритет каждой отдельной задачи или завершать ее. Разработчики DB2 исходят из того основополагающего принципа, что данные и время являются самыми важными вашими ресурсами. Именно для управления данными и служат базы данных, а время - время администратора БД и разработчика приложения - может использоваться значительно более целесообразно, если БД управляется автоматически. Пусть администратор и разработчик приложения занимаются созданием модели данных и написанием приложения - управление блокировками, распределение ресурсов, выбор индексов для запроса и выяснение целесообразности использования индекса битовой карты берет на себя DB2. Философия создателей DB2 заключается в том, что вы оплачиваете программное обеспечение для того, чтобы оно работало на вас, обеспечивая максимальную эффективность использования ваших данных.