В современном мире используется большое количество универсальных промышленных СУБД, предлагаемых компаниями первого и второго эшелона, а также нишевиками. Для первых двух групп вполне можно предсказать тенденции развития на ближайшие годы, если исходить из теоретических исследований, отчетов аналитиков и специалистов в области СУБД, а также проанализировав текущее состояние и планы ведущих игроков рынка СУБД.
Среди множества современных универсальных промышленных СУБД сегодня можно выделить трех лидеров, занимающих более 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.
История развития СУБД учит, что выживают не те производители, которые первыми реализовали новые идеи, а те, кто обладает мощным и агрессивным маркетингом, часто побеждают не лучшие технологии, а деньги и правильная стратегия развития.
Поскольку виртуализация позволяет повысить гибкость и обеспечивает экономию ресурсов, очевидно, что вскоре производители СУБД реализуют возможность работы с единым виртуальным диском и возможность работы СУБД и других элементов ИТ-инфраструктуры на едином виртуальном компьютере с возможностью динамического перераспределения ресурсов между приложениями СУБД.
При анализе работы применяются лучшие практики и знания, накопленные администраторами СУБД, системы учатся реагировать проактивно, выявляют причины, а не следствия возникновения проблем.
Сжатие поколоночно хранимых и заранее отсортированных данных обеспечит их "уплотнение" в десятки раз, однако все попытки изменения таких таблиц в Oracle 11.2 показали, что время обновления данных значительно увеличивается, хотя для хранилищ данных и исторических данных такой подход вполне приемлем.
HP Oracle Database Machine обеспечивает для обычных приложений хранилищ данных Oracle ускорение обработки данных до 70 раз без переписывания приложений. В том же направлении движется Microsoft, купившая DATAllegro и интегрирующая ее продукты с SQL Server.