Среди множества современных универсальных промышленных СУБД сегодня можно выделить трех лидеров, занимающих более 90% мирового рынка СУБД. Это СУБД первого эшелона – IBM DB2, Microsoft SQL Server и Oracle. В список СУБД второго эшелона входят Adabas, Cache, Firebird, Informix, Ingress, Interbase, Progress, Postgres, Sybase, Teradata, ЛИНТЕР и ряд других. Существуют СУБД для нишевых решений, и постоянно появляются прототипы новых специализированных СУБД: объектно-ориентированные СУБД, ХML СУБД, СУБД для обработки потоковых данных, СУБД для работы с текстами и т.д.

Для формирования прогнозов развития отрасли, раз в несколько лет собираются группы ведущих специалистов в области СУБД и выпускают отчеты: Клермонтский отчет (май 2008) [1], Лоуэльский отчет 2003 [2], Ассиломарский отчет 1996 [3], отчет собрания в Лагуна-Бич 1989 [4]. Правда, большая часть этих предсказаний так и не сбывается – производители СУБД обычно руководствуются своими собственными соображениями. Более прагматичен подход к предсказанию тенденций на основе анализа текущего состояния и планов развития тройки продуктов, лидирующих на рынке СУБД, – анализ состояния и перспектив развития IBM DB2 9.5 и Cobra, MS SQL Server 2008 и Oracle 11.1 и 11.2 позволяет делать вполне реалистичные предсказания тенденций развития универсальных коммерческих СУБД.

Революции не будет

За последние несколько лет появилась серия статей Майкла Стоунбрейкера, в которых провозглашается грядущая революция в области СУБД и предсказывается скорая кончина универсальных коммерческих СУБД [5-8]. Стоунбрейкер обосновывает свою позицию тем, что современные универсальные коммерческие СУБД постоянно увеличивают свой функционал без переписывания ядра, в результате чего становятся сложными (никто сегодня не знает и не использует весь имеющийся функционал), громоздкими, медленными и дорогими. Грядет, по мнению Стоунбрейкера, эпоха специализированных СУБД, которые вытеснят универсальные. Данное утверждение иллюстрируется на примере продукции нескольких стартапов (StreamBase, Vertica, ASAP, H-Store), демонстрирующих на специализированных применениях производительность на один-два порядка выше, чем современные промышленные дисковые СУБД.

При ближайшем рассмотрении оказывается, что многие из приведенных Стоунбрейкером результатов не совсем корректны. Например, при тестировании СУБД Vertica с хранением данных по колонкам используется таблица из более чем 200 столбцов, из которой выбирают всего несколько. Понятно, что здесь традиционная СУБД работает намного медленнее, но и любая операция выборки записей с разумным числом полей из этой таблицы на Vertica будет осуществляться не быстро. Стоунбрейкер предлагает пожертвовать журналами транзакций, отказаться от одновременной работы пользователей и от случайных (ad hoc) запросов, а также работать с базами, целиком размещающимися в оперативной памяти, всю логику приложения реализовывать внутри СУБД (в виде хранимых процедур) и т.д. – все ради достижения высокой производительности за счет надежности, масштабируемости и безопасности.

Производительность СУБД, безусловно, важна, но пользователи делают свой выбор, ориентируясь на совокупность характеристик: надежность и непрерывность работы, масштабируемость, безопасность, простоту управления и разработки, возможность работы с большими базами, поддержку специальных схем, алгоритмов и типов данных (OLTP, XML, геоданные, тексты и т.д.), поддержку стандартов и национального языка. Кроме того, очень важна распространенность данной СУБД в конкретной стране, наличие и возможность обучения, количество удачных внедрений и т.п. Здесь специализированные СУБД конкурировать с универсальными не могут.

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

Не стоит забывать про надежность и известность компании-производителя СУБД – заказчики и разработчики приложений, как правило, выбирают не просто СУБД, а платформу для создания множества разнородных приложений.

Что касается сложности и избыточного функционала универсальных СУБД – это не проблема. В каждый момент времени пользователи применяют только нужный им функционал. Знать все и сразу не нужно – при необходимости можно освоить и начать применять тот функционал, который понадобится.

Требуется много времени, чтобы новые возможности начали работать быстро и без ошибок. Так, Oracle уже десять лет совершенствует архитектуру shared anything, которая предоставляет средства работы в кластере, а IBM улучшает оптимизатор запросов. Только лидеры рынка могут вкладывать огромные средства в долгосрочные проекты, а новые идеи и технологии, порожденные стартапами, они очень быстро воспринимают либо покупают новую компанию вместе с технологией. Единственное, что может повлиять на судьбу универсальных СУБД, – это революционные изменения в оборудовании, которые могут привести к кардинальному изменению внутренней архитектуры СУБД (например, отказ от дисков в пользу флэш-памяти или увеличение скорости передачи данных по сетям, превращающее множество разбросанных по всему миру компьютеров в один).

Десятка тенденций

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

Виртуализация и grid

Традиционно в большинстве организаций для каждого приложения выделяется отдельный компьютер (или группа) и свой набор дисков для базы, но поскольку в реальной жизни нагрузка на приложения постоянно изменяется, то ресурсы компьютеров оказываются загружены неравномерно. Выход – виртуализация.

Все диски объединяются в один виртуальный, на котором располагаются все данные всех приложений. Например, в Oracle GRID [9] диски объединены в Storage Grid, а компьютеры – в Database Grid (виртуальный сервер базы данных) и Application Grid (виртуальный сервер приложений). Для управления таким множеством элементов используется программа Grid Control, которая позволяет работать с множеством объектов как с единым целым.

Если для организации grid используются дешевые элементы (диски и компьютеры стандартной архитектуры), то стоимость такой вычислительной среды будет намного меньше, чем при использовании традиционных архитектур. Поскольку элементы виртуального диска или виртуального компьютера взаимозаменяемы, то система обладает повышенной надежностью и живучестью.

Виртуализация позволяет создавать вычислительный ресурс неограниченной мощности и не заботиться о том, на каких компьютерах в действительности работает приложение. Главное – запросить и получить нужный вычислительный ресурс. Система сама выполнит балансировку нагрузки для приложения, создаст, если надо, базу данных с учетом зеркалирования данных и снижения нагрузки по вводу/выводу, задействует столько элементов grid, сколько необходимо для обеспечения требуемой надежности и производительности.

Сегодня уже реализованы такие корпоративные grid первого поколения на решениях Oracle (Amazon, EDS ABNAMRO), а IBM активно проводит исследования в области grid для научных применений, продвигая инструментарий Globus Toolkit.

Основой Database GRID у Oracle является архитектура Real Application Clusters, реализующая подход shared disk (все узлы кластера одновременно работают с единой базой данных), похожую архитектуру реализует и СУБД IBM DB2 для z/OS.

Решения Enterprise Grid первого поколения имели ряд ограничений. Например, предполагалось выделение двух виртуальных компьютеров – Database Grid и Application Grid вместо единого виртуального компьютера для СУБД, серверов приложений, Web-серверов, HTTP-серверов и т.д. Ресурсы автоматически не перераспределялись в соответствии с заранее заданной политикой, система не адаптировалась к изменяющейся нагрузке, приложения не могли без остановки работы переезжать со слабых узлов на более мощные. Большинство из этих ограничений предполагается снять в архитектуре Enterprise Grid 2, примером реализации которой будет Oracle 11.2.

Самоуправление, самодиагностика, самолечение

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

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

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

Еще одной важной тенденцией является уменьшение количества «ручек», которые может подкрутить администратор, вместо этого предлагаются средства задания бизнес-критериев работы: допустимое время простоя при сбоях, максимальное время отклика, минимальная пропускная способность системы и т.п.

Тестирование изменений

ИТ-инфраструктура предприятий постоянно развивается, и в процессе работы приходится все время менять параметры СУБД и структуры данных, создавать новые объекты и т.д. Любое такое действие может привести к ухудшению или остановке работы, а уж переход на новую версию СУБД – хуже пожара. Единственная возможность решить эту проблему – позволить заранее проверить любые изменения на тестовой системе до их выполнения на промышленной системе.

Имеется много пакетов, позволяющих имитировать нагрузку на тестовой системе, однако они часто создают не реальную, а синтетическую нагрузку, и в результате многие проблемы так и остаются невыявленными. Функционал, аналогичный Oracle RAT (Real Application Testing), очевидно, будет реализован во всех СУБД – он позволяет на работающей системе захватить реальную нагрузку (с учетом времени выполнения, одновременности, зависимости операций) и воспроизвести ее на тестовой базе, не устанавливая там приложение. Захват и проигрывание нагрузки позволяют обнаружить появившиеся/пропавшие/изменившиеся после выполнения изменений ошибки, выявить проблемы снижения производительности как всей системы, так и отдельных запросов. После анализа результатов система дает рекомендации по улучшению работы SQL, позволяет попробовать различные варианты оптимизации работы. Откатывая тестовую базу назад, можно тестировать различные изменения и их совокупность. И только после того, как все проблемы выявлены и решены, можно выполнять изменения в производственной среде.

Максимальная доступность

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

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

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

Измерения времени

Для борьбы с ошибками, вызванными человеческим фактором, для аудита, а также для восстановления старых версий данных и отчетов надо иметь в СУБД штатную возможность «откатываться» в прошлое по оси времени. Для этого в СУБД встраиваются механизмы измерения времени и быстрого воссоздания старого состояния базы, объекта или запроса. В частности, у Oracle это реализуется с помощью команды Flashback, развитием которой стал механизм Flashback Data Archive, позволяющий компактно хранить след изменений данных и восстанавливать старое состояние данных таблиц. При этом можно откатиться на любой отрезок времени в прошлое, вплоть до момента создания таблицы, и восстановить старое состояние ее данных, даже если за это время изменилась структура таблицы.

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

Сегодня большинство СУБД умеет работать не только с алфавитно-цифровой информацией, а недавно началась реализация поддержки в универсальных СУБД таких специфических типов данных, как RFID, семантические сети, алгоритмы для медицины, биологии, иммунологии и генетики. Практически все универсальные СУБД сегодня совершенствуют работу с XML. В ближайшее время резко возрастет спрос на работу с семантическими сетями, поддержку стандартов OWL и RDF, так как объем данных этих сетей будет огромен и скорость извлечения и обработки таких данных будет очень важна.

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

Умные механизмы сжатия и дедупликации

Многие приложения хранят данные за большой период времени, а стоимость дискового пространства до сих пор довольно высока, в связи с чем большинство производителей реализовало механизмы сжатия данных. Однако это чревато накладными расходами, поэтому сегодня прослеживается тенденция к совершенствованию механизмов сжатия. Администратор должен иметь возможность выбора различных степеней сжатия, понимая, что за экономию места придется платить временем. Сжатие должно быть прозрачно для приложения – приложение не должно знать о том, сжаты ли данные. Иногда полезен механизм дедуплицирования, когда система сама выявляет дубли полей и хранит их только в одном экземпляре.

Традиционные алгоритмы сжатия позволяют упаковывать данные в два-три раза «плотнее», а некоторые специфические приемы позволяют увеличить этот показатель на порядок, но при этом сильно замедляется выполнение операций DML (Data Manipulation Language) с этими данными.

Совершенствование методов защиты

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

Еще одно перспективное направление – изоляция администратора от данных. Такие средства защиты, как Oracle Data Vault option, позволят выполнять все операции по администрированию, но не дают возможности видеть и менять данные.

СУБД в качестве кэша

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

Сегодня наметилась тенденция использования In memory СУБД в качестве высокоскоростных кэшей к дисковым СУБД, например, Oracle использует в таком качестве СУБД Times Ten, а IBM – СУБД SolidDB. Приложения, требующие высокого быстродействия и гарантированного времени отклика, практически работают с таким кэшем в памяти, который сам синхронизируется с дисковой СУБД. При этом размеры основной базы могут быть очень большими, но кэшируется по определенной политике только часть данных.

Облака и машины баз данных

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

Поскольку объемы данных растут, а алгоритмы традиционных СУБД уже не могут обеспечить хорошее время отклика для задач анализа и построения корпоративной отчетности, то все большую популярность получают вычислительные системы с массивно-параллельной архитектурой, например NCR/Teradata. Такие архитектуры позволяют распараллелить обработку данных и вынести часть работы с уровня СУБД на уровень ячеек хранения, которые сами имеют свои небольшие компьютеры.

Обычно при росте объемов узким местом становятся каналы передачи данных между сервером базы и устройствами хранения, поэтому для увеличения пропускной способности часть операций по просмотру и выборке данных переносится на уровень ячеек хранения. Такая связка оборудования и специального ПО называется машиной баз данных [10], реализации которых сегодня предлагают такие компании, как Netezza, Datallegro и Teradata. Однако такие машины работают со специальным ПО и требуют специальной квалификации для разработки приложений, не используют универсальные СУБД, а универсальные СУБД не поддерживали архитектуру машин. Сейчас началось движение универсальных коммерческих СУБД в сторону машин баз данных, и примером такого сближения стала совместная разработка Oracle и HP – машина баз данных с ячейками хранения Exadata. n

Литература

  2. The Lowell Database Research Self-Assessment. CoRR cs.DB/0310006, 2003. Also in CACM 48(5): 111-118, 2005.
  3. The Asilomar Report on Database Research. SIGMOD Record 27(4): 74-80, 1998.
  4. Future Directions in DBMS Research – The Laguna Beach Participants. SIGMOD Record 18(1): 17-26, 1989.
  5. A Conversation with Michael Stonebraker and Margo Seltzer, ACM Queue, Volume 5, Number 4, May/June 2007.
  6. M. Stonebraker and U. Cetintemel. One Size Fits All: An Idea Whose Time has Come and Gone. In Proceedings of the International Conference on Data Engineering (ICDE), 2005.
  7. Michael Stonebraker, Chuck Bear, etc. One Size Fits All? – Part 2: Benchmarking Results, 3rd Biennial Conference on Innovative Data Systems Research (CIDR) January 7-10, 2007, Asilomar, California.
  8. Michael Stonebraker, Samuel Madden, Daniel J. Abadi, Stavros Harizopoulos, Nabil Hachem, Pat Helland. The End of an Architectural Era (It’s Time for a Complete Rewrite). Proceedings of VLDB, 2007, Vienna, Austria.
  9. Марк Ривкин. Платформа для коммерческих сред Grid // Открытые системы. – 2003. – № 12. – С. 58-64.
  10. Александр Александров. Машины хранилищ данных // Открытые системы. – 2006. – № 2. – С. 32-38.

Марк Ривкин (Mark.Rivkin@oracle.com) – руководитель направления отдела технического консалтинга Oracle СНГ (Москва).

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

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

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

Сжатие поколоночно хранимых и заранее отсортированных данных обеспечит их «уплотнение» в десятки раз, однако все попытки изменения таких таблиц в Oracle 11.2 показали, что время обновления данных значительно увеличивается, хотя для хранилищ данных и исторических данных такой подход вполне приемлем.

HP Oracle Database Machine обеспечивает для обычных приложений хранилищ данных Oracle ускорение обработки данных до 70 раз без переписывания приложений. В том же направлении движется Microsoft, купившая DATAllegro и интегрирующая ее продукты с SQL Server.