микробазы данных для различных устройств и приборов, таких как кредитные карточки, сетевые компьютеры, электронные записные книжки и т.д.;

резидентные базы данных, используемые в сверхпроизводительных OLTP-системах, например в телекоммуникационных сетях и на Web-узлах с очень большим числом посетителей.

Пакеты корпоративных приложений

Еше десять-двадцать лет назад большинство корпоративных приложений разрабатывалось собственными силами информационных служб предприятий. Решение о том, какую СУБД выбрать, принималось разработчиками. Даже компании-лидеры иногда делали рискованный выбор в пользу новых, относительно непроверенных технологий, полагая, что благодаря им смогут превзойти конкурентов. Взлет компании Sybase в конце 80-х - начале 90-х годов тому подтверждение.

Сегодня большинство компаний отказались от стратегии делай сам в пользу стратегии покупай в отношении большинства корпоративных приложений, таких как системы планирования ресурсов предприятий (Enterprise Resource Planning - ERP), системы управления поставками (Supply Chain Management - SCM), системы управления человеческими ресурсами (Human Resource Management - HRM), системы автоматизации торговых операций (Sales Force Automation - SFA), системы обслуживания клиентов и др. Все эти системы в настояшее время поставляются в виде комплексных программных пакетов, обеспеченных обслуживанием, технической поддержкой и консультациями. И во всех них используются реляционные базы данных.

Появление комплексных корпоративных систем оказало существенное влияние на развитие рынка баз данных. Большинство подобных систем поддерживало СУБД лишь двух или трех ведущих поставщиков. Это привело к еще большему усилению позиций ведущих СУБД и усложнило жизнь начинающим компаниям. Другим следствием стало снижение цен на СУБД, которые теперь стали чаще рассматриваться как составная часть более крупного профаммного пакета, а не как отдельный компонент.

Повышение производительности аппаратного обеспечения

Одной из главных причин роста популярности SQL в 80-е годы было резкое увеличение производительности реляционных СУБД. Частично этот рост произошел благодаря улучшению технологии разработки баз данных и оптимизации запросов. Однако в основном увеличение производительности СУБД явилось результатом общего повышения быстродействия аппаратных средств. Например, представляя на рынке СУБД DB2/2, компания IBM объявила, что ее производительность составляет 270 транзакций в секунду (ф/с), что на 120 процентов больше, чем производительность предыдущей версии DB2 (123 ф/с). Но более тщательное изучение результатов конфольного тестирования показало, что производительность самой DB2 увеличилась только на 51 процент, со 123 ф/с до 186 ф/с. Оставшиеся 69 процентов роста производительности были достигнуты благодаря тому, что испытания новой СУБД проводились на более мощном компьютере.

Повышение производительности мэйнфреймов сопровождалось аналогичными процессами на рынке серверов Unix и Windows, где вычислительная мощность удваивается каждый год. Самые разительные перемены происходят с системами

симметричной многопроцессорной обработки (Symmetric MuJtiprocessing - SMP), в которых рабочая нагрузка распределяется между двумя, четырьмя, восемью и более процессорами, работающими параллельно. Многопроцессорная архитектура особенно подходит для OLTP-приложений, где нагрузкой является большое число маленьких, одновременно вьшолняемых транзакций в базе данных. Традиционные поставщики OLTP-систем, например компания Tandem, всегда применяли многопроцессорную архитектуру, а в крупнейших системах на базе мэйнфреймов она используется уже больше десяти лет. В начале 90-х годов SMP-системы активно вторглись на рынок серверов Unix, а чуть позднее - на рынок высокопроизводительных серверов Windows. С появлением многопроцессорных чипсетов производства компании Intel SMP-системы, состоящие из двух или четырех процессоров, практически приобрели статус базовой конфигурации в серверах ЛВС.

Поддержка новых аппаратных возможностей (в частности, многопроцессорных архитектур) со стороны операционных систем часто запаздывала - иногда она появлялась на несколько кварталов или даже лет позже. Это создавало особую проблему для поставщиков СУБД, от которых требовалось решить, следует ли в попытке улучшить производительность СУБД игнорировать услуги операционной системы. Например, СУБД Sybase первоначально функционировала как единый системный процесс, самостоятельно управляя заданиями, вводом/выводом, обработкой событий - функциями, обычно въшолняемыми операгшонной системой. На некоторое время это дало Sybase преимущества перед другими СУБД, но когда поддержка многопроцессорных систем была внедрена в операционные системы, аналогичные возможности стали автоматически доступны конкурентам, которые переложили вышеперечисленные функции на операционную систему, тогда как Sybase пришлось продолжать поддерживать собственные низкоуровневые сервисы. Оготсанный случай привел к тому, что в настоящее время большинство поставщиков СУБД оставляют за операционной системой вопросы профаммирования потоков и процессов.

Еще одной тенденцией на рынке аппаратного обеспечения в 80-х - начале 90-х годов стало появление компаний, использовавших высокопроизводительные микропроцессоры, быстрые жесткие диски и многопроцессорную архитектуру для создания специализированных систем, работавших в качестве серверов баз данных. Эти поставшики утверждали, что с помошью специально спроектированного ядра базы данных они могут обеспечить гораздо более высокую производительность, чем с помошью вычислительной системы обшего назначения. В ряде случаев такие системы содержали специализированные интефальные микросхемы (Application-Specific Integrated Circuits - ASIC), в которых для обеспечения максимального быстродействия были аппаратно реализованы некоторые функции СУБД. Специализированные СУБД таких компаний, как Teradata и Sharebase, получили определенное признание и используются в приложениях, выполняющих сложные запросы к очень большим базам данных. Однако они не стали важной частью рынка баз данных, и большинство поставщиков таких СУБД либо ушли с рынка, либо были приобретены более крупными компаниями широкого профиля.

Очевидно, что продолжающееся развитие процессорных технологий и технологий ввода/вывода будет оказывать постоянное влияние на рост производительности баз данных. Сегодня благодаря высокопроизводительным многопроцессорным серверам недостатки реляционной модели по сравнению со старыми нереляционными моделями уже не принимаются во внимание. В то же время увеличение размеров баз данных требует, чтобы СУБД могли обрабатывать все большее число транзакций в секунду.

Война за показатели производительности

Когда реляционные базы данных вышли на рынок корпоративных приложений к их производительноеги стали предъявляться повышенные требования Пользователи хотели быть уверенными в том, что выбранная СУБД не начнет задыхаться с ростом потребностей приложений. Эта обеспокоенность пользователей, дополняемая заинтересованностью поставшиков СУБД в продаже дорогих производительных систем высокого класса, привела к войне за показатели производительности между поставшиками СУБД. В нее в различные периоды времени оказались втянутыми практически все поставшики СУБД. Одних интересовала максимальная абсолютная производительность СУБД, других - соотношение цена/производительность и результирующая экономия средств, третьих - производительность СУБД в конкретных системах, например OLTP или OLAP Во всех случаях компании реютамировали контрольные тесты, которые доказывали превосходство их программных продуктов, и пытались дискредитировать контрольные тесты других поставшиков.

Первоначально тесты разрабатывались самими поставщиками, а затем появились первые два независимых теста. Тест дебет/кредит эмулировал простые бухгалтерские транзакции. Тест TPL разработанный компанией Tandem, измерял производительность простых OLTP-систем. К сожаленгао, для поставщиков СУБД не составляло особого труда манипулировать peзyльтaтaш этих простых тестов, чтобы выставить свои продукты в наилучшем свете.

Пытаясь сделать результаты контрольных тестов более стабильными и достоверными, несколько поставшиков и консульгантов по базам данных образовали организацию Transaction Processing Council (ТРС, Совет по средствам обработки транзакций) и решили создать стандартный контрольный гест для реляционных баз данных, который позволил бы реально сравнивать производительность различных СУБД. Эта организация разработала серию официальных контрольных тестов, известных как ТРС-А, ТРС-В и ТРС-С. Она взяла на себя функции сбора, хранения и публикации результатов контрольных тестов для различных СУБД и вычислительных систем, а также заботу о верификации результатов тестов, о которых сообщают поставщики СУБД. Результаты контрольных тестов ТРС выражаются в транзакциях в секунду (tps - ТРС-А и ТРС-В) и транзакциях в минуту (tpm - ТРС-С). Часто, говоря о результатах, указывают также название теста (например, 10000 tpmC ).

Последний из OLTP-тестов - ТРС-С - измеряет не просто производительность сервера баз данных, но общую производительность всей клиент-серверной системы, в которую входит данный сервер. Производительность современных многопроцессорных серверов рабочих групп достигает в данном тесте десяти тысяч транзакций в минуту. Корпоративные SMP-серверы Unix показывают в несколько раз большую производительность. Максимальный показатель кластера 64-разрядных процессоров Alpha стоимостью несколько миллионов долларов превышает 100000 tpmC.

Организация ТРС разрабатывает тесты не только для OLTP-систем Тест TPC-D измеряет производительность хранилищ данных Готовится также тест TPC-W, ориентированный на оценку производительности Internet-приложений, работающих с базами данных в Web-среде

Интересно, что по мере того как результаты тестов демонстрируют все большее число выполняемых транзакций, отмечается использование в контрольных тестах все более крупных баз данных. Это условие выполнения контрольных тестов нацелено на получение более достоверных результатов. Если для нормальной работы приложения требуется производительность 20000 tpmC, то для ее обеспечения необходимо использовать гораздо более мощную вычислительную систему, чем при производительности 5000 tpmC.